[riot-devel] Working on port to SODAQ Autonomo (SAMD21)
peter.kietzmann at haw-hamburg.de
Mon Jun 13 22:39:31 CEST 2016
honestly just now I got your actual problem and I remember what I
stumbled upon this morning:
# define the cpu used by SAMR21 Xplained Pro board
export CPU = samd21
export CPU_MODEL = samr21x18a
However, I won't say "for RIOT that's good enough". To summarize: The
main questions are (i) how to split different CPUs/MCUs with rather
small differences and (ii) how to reuse most of the code. Right? For
(ii) it would obviously be the best way to have drivers and stuff in the
common folder. Personally I have no idea if this is possible or not, it
depends on the differences. If these are too big, one needs to stay with
a separate CPU folder for each "family". For (i) won't it be enough to
export the CPU_MODEL by the board and adjust the include paths properly,
as done e.g. here?
One other question is the need for changing the CPU name of the Atmel
samr21-xpro board from "samd21" to "samr21". In your regards I think it
could make sense but with a solution as described in (i) above, there
won't be a need for that. Do I see that correctly?
Generally I'm not too much into Atmels product series and I would like
to hear Kaspar's opinion as he knows RIOTs architecture much better than me.
Am 13.06.2016 um 20:55 schrieb Kees Bakker:
> On 13-06-16 09:56, Peter Kietzmann wrote:
>> Hi Kees,
> Hi Peter,
>> nice to see your interest in RIOT! Find some comments inline.
>> Am 12.06.2016 um 21:14 schrieb Kees Bakker:
>>> This is a heads up to let you know I'm working on a port of
>>> RIOT to SODAQ Autonomo, which has an Atmel samd21 (like
>>> Arduino Zero).
>>> First I moved the existing cpu/samd21 tree to cpu/samr21. Then
>> Why? Well *if* there is a need to change the current RIOT code base,
>> you should open a separate PR for that.
> That seems like a good aproach, but I asked a related question before
> and I was
> stuck with the answer. The answer was something like: the samr21
> processor is the same
> as the samd21, so for RIOT that's good enough.
>> This is a question to all: How comes the Atmel samr21-xplained pro
>> board has "samd21" CPU in RIOT?
> I don't know the history of how it was added. I like to understand what
> when cpu/samd21 was added. Where did the files come from? I'm guessing
> from ASF 3.18 or 3.19. ASF => Atmel Software Framework
>>> I added the samd21 CMSIS files from Arduino and the board files
>>> for the SODAQ Autonomo. For that, I copied several files from
>> What was wrong with current CMSIS headers?
> Well, these files are from the samr21 tree in ASF, yes samr21, not samd21
> SAMR21 and SAMD21 have the same cpu. But there are tens of derivatives. The
> differences are in memory size (RAM, ROM), peripherals, etc. So if you
> select a
> board, you also want to select the particular flavor of the SAMx21.
> Another issue here is maintenance. How do we want to follow upgrades
> from Atmel?
> New cpu variants, bug fixes, etc. The best would be to have the files in
> RIOT as close as
> possible to the original. And a description somewhere how to do an upgrade.
> To answer the question why I wanted to move cpu/samd21 to cpu/samr21, it is
> basically driven by the need for SAMD21J18A.
>>> In the process I learned how to use the Atmel-ICE and how to
>>> debug via openocd. Nice :-)
>> Yepp :-)
>>> At the moment I can step through the hello world example. But
>>> I have no idea where the output is going. That's my next challenge.
>> By default the STDIO is mapped to UART_DEV(0) which will generally be
>> the first device defined in the periph_conf.h file of the board. E.g.:
>> The driver used should be common for samX21 MCUs but is currently not.
>> For Kinetis there already is a great code reusability:
>> However, you could try to set up a different STDIO UART device and
>> connect an external UART/USB converter to see if it's about
>> conflicting pins.
> That is more or less already what I did. I filled in uart_config with
> two devices
> and I have a serial line connect to my PC. This configuration works with
> the Arduino
> setup. But not yet with RIOT.
>>> Meanwhile the changes and additions are available in my fork at
>>> git at github.com:keestux/RIOT-OS
>>> Branch sodaq-autonomo.
Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
More information about the devel