extend support for SAM D and L family

[dylad]

I would like to add support for the SAMD20-Xplained board from Atmel.

Recently, sam21_common has been renamed to sam0_common and I think it was a good point. But if we take a look into RIOT structure, there is cpu/samd21 and cpu/saml21 but what about the others MCU from atmel ?

So my question is : Should we rename cpu/saml21 and cpu/samd21 to cpu/samdxx and cpu/samlxx (or something else) to ease support for the whole atmel portfolio ?

[keestux]

Your suggestion might not be a bad one.

TL;DR
The way I saw this (when I started with my SAMD21 board), was to try and follow what Atmel gives us through their CMSIS files in ASF (Atmet Software Framework). Notice that cpu/sam0_common/include/cmsis/ comes straight from some ASF version. (Albeit that we don't know the exact history how it was added in RIOT.)

At one point I had the illusion that all the sam0 could share the same code base. But since then I found out that ASF has several places where they split the code for variants or variant groups. Unfortunately, the groups are not consistent for all peripherals. See below. To summarize (dropping "xx" from the directory name):

cpu/samd - for all SAMDxx, SAMRxx (and SAMHxx?)
cpu/saml - for all SAMLxx
cpu/samc - for all SAMCxx
...

Looking at ASF I see these variants groups in the drivers. (Besides this, there are lots of drivers that are common for all sam0 variants.)

./drivers/pac/pac_sam_d_r_h
./drivers/pac/pac_sam_l_c
./drivers/system/power/power_sam_d_r_h
./drivers/system/power/power_sam_c
./drivers/system/power/power_sam_l
./drivers/system/reset/reset_sam_c
./drivers/system/reset/reset_sam_d_r_h
./drivers/system/reset/reset_sam_l
./drivers/adc/adc_sam_d_r_h
./drivers/adc/adc_sam_l_c
./drivers/adc/adc_sam_b
./drivers/bod/bod_sam_c
./drivers/bod/bod_sam_d_r_h
./drivers/bod/bod_sam_l
./drivers/tc/tc_sam_d_r_h
./drivers/tc/tc_sam_l_c
./drivers/extint/extint_sam_d_r_h
./drivers/extint/extint_sam_l_c
./drivers/dac/dac_sam_l
./drivers/dac/dac_sam_d_c_h
./drivers/ac/ac_sam_l_c
./drivers/ac/ac_sam_d_r_h
./drivers/rtc/rtc_sam_l_c
./drivers/rtc/rtc_sam_d_r_h
./drivers/events/events_sam_l_c
./drivers/events/events_sam_d_r_h
./drivers/usb/usb_sam_l
./drivers/usb/usb_sam_d_r

[dylad]

Thanks for your reply @keestux

I leave to RIOT members the choice of the new directories name (It was just a suggestion)I'm afraid such modification will impact some pending PRs but it has to be done...Do you think we can come up with a PR for the April release ?

[keestux]

What have you done so far?

[dylad]

Nothing ! Only think.
I can propose a PR and notify you if you want.

[kaspar030]

Do you think we can come up with a PR for the April release ?

2.5 weeks left util feature freeze. If the PR is stable until then, it'll be in.

[keestux]

Well, it may be more work than you think. What has to be done is:

1. look at the code in cpu/samd21 and determine what is compatible with SAMD20 and what is not
2. add the include files in cpu/sam0_common/cmsis (we need to decide from which ASF version)
3. add the board files for SAMD20 Xplained
4. testing ...

About 1)
A quick scan already gave me the impression that we cannot use cpu/samd21 for SAMD20. Perhaps only uart.c, but that is not enough to qualify for a common tree for SAMD21 and SAMD20.
To perform this task you must be very familiar with the various SAMDs. I'm not perse the first one qualified.

About 2)
This is the easiest task, albeit that it needs a bit of tuning. There is a readme in cpu/sam0_common/include/vendor/samd21 with details. I could do this, but I will have nothing to verify the correctness.

About 3)
That's up to someone with that board at hand.

Can we do this before the April release. I think not.

[dylad]

@keestux you're right, I took a quick look into D20 & D21 datasheets.
What I thought was to submit two PRs :

• create a common tree like cpu/samd & cpu/saml (for April release)
• Then, start to work on my port for SAMD20 with a second PR

But I didn't expect so much difference between registers... It may be even worse with D9, D10 & D11...
I will give a try with one PR SAMD20 (and keep an eye on compatibility with D9,D10,D11 even if I don't have the hardware for them) and come back to you with a WIP PR.

edit: fix typos

[PeterKietzmann]

@dylad is this issue still up to date? I did't go into details, just found it related to #10653 which was merged recently.

[dylad]

Well I never had time to go deeper and I don't have much time to work on it but there is still a lot of unsupported SAM variants in the wild. So I think this issue can remain open for now. Would be interesting to see if there are people who want to run RIOT on these remaining MCUs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.