This is needed because of a limited timeframe of dev time... Therefore spending time on fixing a port to that particular board, if one already exists, would be like "reinventing the deep plate"
Best regards
Troels D. Hoffmeyer
Jesper Nissen
Rane Balslev
The bad news, there doesn't exist a port of RIOT to the SAM R21, yet.
The good news, we received a couple of these boards today from
Atmel and I started out with a port today.
That said, it will certainly will take some time to "fully" support
this board. I'd say basic support (UART, timers, GPIO, SPI) by end
of this week, probably another week for bug fixing and basic radio
functionality. There is already support (basic operating modes) for
the at86rf231 radio device in RIOT which is very similar to the
at86rf233 on the SAM R21. I'm working to support extended operating
modes in parallel to this porting efforts.
What do you plan to use RIOT and SAM R21 for and/or which features
are of special interest to you?
I pushed the basic file tree to my github fork [1].
Maybe we could use this as synchronisation point for
our porting efforts. I'm currently working on the
UART driver to get output working.
I also created a issue in gh [2] to track our all
porting efforts so we don't do (too much) double work.
Hi Rane,
an example for the use of sixlowpan you can found in examples/rpl_udp/. Be aware though, that we are in the process of heavily rewriting and refactoring our network stack (including 6LoWPAN and IPv6) to a more unified and modular approach.
I’m also very interesting about the adc, uart, spi and transceiver that you have developped.
When will you add your contributions to the main RIOT repo?
How should we decide on which SERCOM to assign for SPI and which for I2C for the SAMD21 cpu.
Currently SERCOM0 is assigned for UART but others are free and I’d take SERCOM1 for SPI for now and hence sending out this mail to stay consistent if there is any other approach to the driver.