cpu/sam0_common: derive ROM_LEN & RAM_LEN from part number

[benpicco]

Contribution description

The ROM size is encoded in the part number of the Atmel SAM chips.
RAM size is not encoded directly, but it's always a fixed fraction of the ROM size.

• On SAM D2x/SAML2x it's ⅛ of the ROM.
• On SAM L1x it's ¼ of the ROM.
• On SAM D5x RAM is at least 128k and increments by 64k with every ROM increment.

Testing procedure

I manually confirmed that the resulting ROM_LEN and RAM_LENs are still the same for the chips that were listed here before.

Issues/PRs references

This is the last missing piece missing to do away with having to do changes in RIOT for using a different part number of a supported chip.

[dylad]

@benpicco:
Isn't easier to derive these values from vendor files ? using HSRAM_SIZE and FLASH_SIZE ?
No more maths, no more headache.

[benpicco]

I'm afraid those are not available to make.
And then those variables are passed on to the linker which also doesn't understand header files.

[dylad]

I'm afraid those are not available to make.
And then those variables are passed on to the linker which also doesn't understand header files.

Yeah but I was thinking of using sed to parse the right file from the Makefile. CPU model should be known so It might be doable ? This way, we just have to add vendor files for new MCUs and Makefile will adapt automatically.

[benpicco]

Yeah but I was thinking of using sed to parse the right file from the Makefile. CPU model should be known so It might be doable ? This way, we just have to add vendor files for new MCUs and Makefile will adapt automatically.

Good idea!
Unfortunately the sub-folder structure is not uniform, so I have to resort to find, but knowing the family folder already, this should not be too bad.

[dylad]

Good idea!
Unfortunately the sub-folder structure is not uniform, so I have to resort to find, but knowing the family folder already, this should not be too bad.

Nice, this looks cleaner this way and even more generic ! Let's wait for Murdock.

[fjmolinas]

Good idea!
Unfortunately the sub-folder structure is not uniform, so I have to resort to find, but knowing the family folder already, this should not be too bad.

This could be very bad performance wise, it could lead to very big build times. In general anything that uses non make builtins is slow, so any shell call is slow. Parsing files can be very slow and IMO should be avoided, see #13174 for an example.

It is in general better to have a big file declaring everything (in make) than using magic parsing to retrieve that.

[benpicco]

I reverted the last change, it was broken anyway according to Murdock.

[dylad]

see #13174 for an example.

I understand it may be faster for make but this is hell to maintain.

[benpicco]

Not sure why ?= breaks riotboot, but there is no need to overwrite those constants, so we might just as well use :=.

Parsing the part number with sed should be uncontroversial. (Unless there is a way to do that with built-in commands)
I agree that using find to search for the right vendor file (because some of these have multiple include_[a|b|c|d]/ directories) and then parsing the huge vendor file might be sub-optimal.

# get vendor file to extract RAM size
VENDOR_FILE := $(shell find $(RIOTCPU)/sam0_common/include/vendor/sam$(FAMILY) -name $(CPU_MODEL).h | grep include*/sam)
RAM_LEN := $(shell sed -E -n 's/\#define (HMCRAMC0_SIZE|HSRAM_SIZE).*\((.*)\).*/\2/p' $(VENDOR_FILE))

But then again the compiler will do just the same thing and the file will be in the cache.

[benpicco]

Why speculate when we can measure it?
I've run hyperfine on the different versions:

master

Benchmark #1: make BOARD=samr21-xpro -j
  Time (mean ± σ):     527.9 ms ±   4.9 ms    [User: 503.1 ms, System: 69.6 ms]
  Range (min … max):   519.7 ms … 537.2 ms    10 runs

semi-generic version with per-family formula

Benchmark #1: make BOARD=samr21-xpro -j
  Time (mean ± σ):     531.7 ms ±   2.1 ms    [User: 502.1 ms, System: 75.7 ms]
  Range (min … max):   528.6 ms … 536.2 ms    10 runs

generic version parsing vendor files

Benchmark #1: make BOARD=samr21-xpro -j
  Time (mean ± σ):     535.6 ms ±   4.0 ms    [User: 507.6 ms, System: 75.1 ms]
  Range (min … max):   530.6 ms … 542.0 ms    10 runs

(This was on a Crucial CT250MX2 SDD with a i5-2500k and 16 GiB RAM)

[benpicco]

So I'd say the impact of the fully generic version is negligible.
Parsing the part number adds 8ms on average, so that's a very small sacrifice for much improved ease of use when adding new boards.

[dylad]

I am happy with this.
I tested benpicco PR by modifying tests/leds/Makefile as follows:

include ../Makefile.tests_common


# Some boards do not initialize LED0 by default
CFLAGS=-DAUTO_INIT_LED0

..msg:
	@echo "print CPU ROM/RAM"
	@echo CPU: $(CPU_MODEL)
	@echo ROM LENGTH: $$(($(ROM_LEN)/1024))K
	@echo RAM LENGTH: $$(($(RAM_LEN)/1024))K

print-info: ..msg

include $(RIOTBASE)/Makefile.include

then run make BOARD=samr34-xpro -C tests/leds print-info

print CPU ROM/RAM
CPU: samr34j18b
ROM LENGTH: 256K
RAM LENGTH: 32K

I tested a bunch of SAM0-based board, I also modified CPU_MODEL in some cases to check if output was changed accordingly.

@fjmolinas Are you happy with this too ?

[fjmolinas]

@dylad you can also test with make -C info-debug-variable<VARIABLE_NAME>.

@fjmolinas Are you happy with this too ?

Performance was evaluated by @benpicco so I'm fine with this.

[dylad]

info-debug-variable

That's the command I wanted to use but I was unable to remember it so it was faster to rewrite something !
Thanks I guess it is time to write it down.

[benpicco]

Should I squash?

[dylad]

Should I squash?

Please, go ahead.

[dylad]

I checked manually Makefile output, this looks good and buildsystem isn't impact that much so let's go.