Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi Kees, Am 15.06.2016 um 22:07 schrieb Kees Bakker: On 15-06-16 09:32, Peter Kietzmann wrote: Hi Kees, if you volunteer you could start with moving code to samd21_common and open PR(s) for that :-). Well, OK. I'll give it a try. Seems like a step in the right direction. I personally won't find time for that unfortunately. On our side we could test your PR(s) with the samr21-xpro board and AFAIK Kaspar has a saml21-xpro board. Do you have a "build farm" of some sorts? Or do you run tests manually? We have static build tests (tool named "Murdock") which can be enabled by maintainers in a PR. The rest is done manually with review and local testing. Regarding the UART issue, could you give some more insights about the pad you want to add to uart_conf_t? I just gave it a quick look into the reference manual http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf but on the first sight I didn't see a difference to http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf My UART changes have nothing to do with samd21 versus samr21. It's about selecting a pin for RX, TX. For example, on Autonomo use pin PA10 for TX. PA10 is PAD2 of SERCOM0, with MUX C. The samr21_xpro has PA4 as TX, PA4 is PAD0 of SERCOM0 (ALT) with MUX D. Ok I got it. Agree that it makes sense to expand the configuration type. But as I'm probably biased, do others feel that the folder scheme should more reflect a vendor's scheme? I'd like to have the most generic abstraction (e.g. samd21, saml21 and probably samr21) and better no separate folders for each CPU variant. However, I can't estimate the feasibility of that in order to allow support for all these variants. Let's move this discussion to your PR. Best Peter -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
On 15-06-16 09:32, Peter Kietzmann wrote: Hi Kees, if you volunteer you could start with moving code to samd21_common and open PR(s) for that :-). Well, OK. I'll give it a try. Seems like a step in the right direction. I personally won't find time for that unfortunately. On our side we could test your PR(s) with the samr21-xpro board and AFAIK Kaspar has a saml21-xpro board. Do you have a "build farm" of some sorts? Or do you run tests manually? Regarding the UART issue, could you give some more insights about the pad you want to add to uart_conf_t? I just gave it a quick look into the reference manual http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf but on the first sight I didn't see a difference to http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf My UART changes have nothing to do with samd21 versus samr21. It's about selecting a pin for RX, TX. For example, on Autonomo use pin PA10 for TX. PA10 is PAD2 of SERCOM0, with MUX C. The samr21_xpro has PA4 as TX, PA4 is PAD0 of SERCOM0 (ALT) with MUX D. -- Kees ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hey, On 06/15/2016 09:32 AM, Peter Kietzmann wrote: > AFAIK Kaspar has a > saml21-xpro board. Unfortunately not anymore. I think Hauke has one, or at there should be one at FU Berlin. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hey, On 06/14/2016 08:59 PM, Kees Bakker wrote: > Notice the TXPO and RXPO. These indicate which "pads" the pin can use on > a certain SERCOM. > So, what we can learn from this is that we need to expand uart_conf_t. > We need PAD configuration > too. yep, that makes sense. +1! Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi Kees, if you volunteer you could start with moving code to samd21_common and open PR(s) for that :-). Seems like a step in the right direction. I personally won't find time for that unfortunately. On our side we could test your PR(s) with the samr21-xpro board and AFAIK Kaspar has a saml21-xpro board. Regarding the UART issue, could you give some more insights about the pad you want to add to uart_conf_t? I just gave it a quick look into the reference manual http://www.atmel.com/images/atmel-42181-sam-d21_datasheet.pdf but on the first sight I didn't see a difference to http://www.atmel.com/Images/Atmel-42223%E2%80%93SAM-R21_Datasheet.pdf Best Peter Am 14.06.2016 um 20:30 schrieb Kees Bakker: On 13-06-16 22:39, Peter Kietzmann wrote: Hi Kees, 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 https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/Makefile.include 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? Correct. 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". Yes, that is certainly possible. All these SAM devices can be handled with a common code base. Someone already started such a common place: cpu/sam21_common. We should continue with that. If you ask me, I'd say that already a lot of files from cpu/samd21/periph can be moved to cpu/sam21_common. 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? Yes, that is the right thing to do. For Atmel there is one more thing: CFLAGS must have a define like -D__SAMD21J18A__, otherwise the correct include files aren't selected. https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f3/include/cpu_conf.h#L27 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? I don't care too much how the CPU is called. But maybe it is useful to know which CPU variant it is, like SAMD21J18A. 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. I'd be interested to know what Kaspar thinks about it. ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi,
Following this thread, I better understand the problems I had when I tried to
port RIOT on Arduino/Genuino Zero in [1]. I'll test your changes in
cpu/samd21/periph/uart.c to see if they fix them. Note that it uses an Atmel
ATSAMD21G18 MCU which is again another variant of samd21.
Alex
[1] https://github.com/RIOT-OS/RIOT/pull/5475
- Mail original -
> As promissed ...
>
> The final change to make it work was selecting the correct "mux". There
> were a few hardcoded things in
> * boards/samr21-xpro/include/periph_conf.h
> * cpu/samd21/periph/uart.c
>
> SAMR21_XPRO has the first serial connected to:
>RX - PA5
>TX - PA4
> static const uart_conf_t uart_config[] = {
> /* device, RX pin, TX pin, mux */
> {>USART, GPIO_PIN(PA,5), GPIO_PIN(PA,4), GPIO_MUX_D},
>
>
> My SODAQ Autonomo board has the first serial connected to:
>RX - PA9
>TX - PA10
> static const uart_conf_t uart_config[] = {
> /* device, RX pin, TX pin, mux */
> {>USART, GPIO_PIN(PA,9), GPIO_PIN(PA,10), GPIO_MUX_C},
>
> Is that all? No, welcome to the SERCOM world of ARM Cortex M0.
> In cpu/sam???/periph/uart.c some changes are needed too. In the next
> diff, the samr21
> is the "old" samd21.
>
> --- cpu/samd21/periph/uart.c2016-06-13 22:41:15.358773522 +0200
> +++ cpu/samr21/periph/uart.c2016-05-31 19:57:02.788554067 +0200
> @@ -86,10 +86,9 @@
> /* reset the UART device */
> dev->CTRLA.reg = SERCOM_USART_CTRLA_SWRST;
> while (dev->SYNCBUSY.reg & SERCOM_USART_SYNCBUSY_SWRST) {}
> -/* set asynchronous mode w/o parity, LSB first, PAD2 to TX, PAD1 to
> RX, sample rate 16x and
> +/* set asynchronous mode w/o parity, LSB first, PAD0 to TX, PAD1 to
> RX and
>* use internal clock */
> dev->CTRLA.reg = (SERCOM_USART_CTRLA_DORD |
> - SERCOM_USART_CTRLA_TXPO(0x1) |
> SERCOM_USART_CTRLA_RXPO(0x1) |
> SERCOM_USART_CTRLA_SAMPR(0x1) |
> SERCOM_USART_CTRLA_MODE_USART_INT_CLK);
>
>
> Notice the TXPO and RXPO. These indicate which "pads" the pin can use on
> a certain SERCOM.
> So, what we can learn from this is that we need to expand uart_conf_t.
> We need PAD configuration
> too. (BTW, Arduino Core is doing similar things.)
>
> Was this a TL;DR? Sorry about it then.
> -- Kees
>
>
> On 13-06-16 23:28, Peter Kietzmann wrote:
> > Congrats! Looking forward to hear the trick that did it :-).
> >
> > Good night
> > Peter
> >
> > Am 13.06.2016 um 23:21 schrieb Kees Bakker:
> >> On 13-06-16 20:55, Kees Bakker wrote:
> >>>
> >>> 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.
> >>
> >> I almost gave up ..., but then ...
> >>
> >> �main(): This is RIOT! (Version:
> >> 2016.07-devel-191-g42127-rapper-sodaq-autonomo)
> >> Hello World!
> >> You are running RIOT on a(n) sodaq-autonomo board.
> >> This board features a(n) samd21 MCU.
> >>
> >> Yeah, it's working. Well, hello world is.
> >> (( It's getting too late now. I'll explain later this week what was
> >> needed to make it work. ))
> >>
> >
>
>
> --
> Kees Bakker
> Founder
> SODAQ
> M. 0031617737165
> www.sodaq.com
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
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: Hi, 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 happened when cpu/samd21 was added. Where did the files come from? I'm guessing they're 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 samr21-xpro. What was wrong with current CMSIS headers? https://github.com/RIOT-OS/RIOT/tree/master/cpu/samd21/include 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.: https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L108 The driver used should be common for samX21 MCUs but is currently not. https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/uart.c For Kinetis there already is a great code reusability: https://github.com/RIOT-OS/RIOT/tree/master/cpu/kinetis_common/periph 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 g...@github.com:keestux/RIOT-OS Branch sodaq-autonomo. Best Peter -- Kees Bakker Founder SODAQ M. 0031617737165 www.sodaq.com ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi! On 13 Jun 2016, at 9:56 CEST(+0200), Peter Kietzmann wrote: 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. This is a question to all: How comes the Atmel samr21-xplained pro board has "samd21" CPU in RIOT? I added the samd21 CMSIS files from Arduino and the board files for the SODAQ Autonomo. For that, I copied several files from samr21-xpro. What was wrong with current CMSIS headers? The problem is, the Atmel data sheet calls the samr21-xpro board CPU samd21 but then again Atmel maintains separate header file trees. Best, Thomas ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Working on port to SODAQ Autonomo (SAMD21)
Hi Kees, nice to see your interest in RIOT! Find some comments inline. Am 12.06.2016 um 21:14 schrieb Kees Bakker: Hi, 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. This is a question to all: How comes the Atmel samr21-xplained pro board has "samd21" CPU in RIOT? I added the samd21 CMSIS files from Arduino and the board files for the SODAQ Autonomo. For that, I copied several files from samr21-xpro. What was wrong with current CMSIS headers? https://github.com/RIOT-OS/RIOT/tree/master/cpu/samd21/include 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.: https://github.com/RIOT-OS/RIOT/blob/master/boards/samr21-xpro/include/periph_conf.h#L108 The driver used should be common for samX21 MCUs but is currently not. https://github.com/RIOT-OS/RIOT/blob/master/cpu/samd21/periph/uart.c For Kinetis there already is a great code reusability: https://github.com/RIOT-OS/RIOT/tree/master/cpu/kinetis_common/periph 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. Meanwhile the changes and additions are available in my fork at g...@github.com:keestux/RIOT-OS Branch sodaq-autonomo. Best Peter -- Peter Kietzmann Hamburg University of Applied Sciences Dept. Informatik, Internet Technologies Group Berliner Tor 7, 20099 Hamburg, Germany Fon: +49-40-42875-8426 Web: http://www.haw-hamburg.de/inet ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
