cpu: saml21 initial commit#2849
Conversation
Spammer! 😝 |
|
have to top your codestyle commits somehow! ;) |
|
By importing hundreds of vendor headers? j/k |
|
Is that an ACK? ;) |
|
GitHub does not even allow me to review:
(Best excuse ever...) |
|
If I'm the only one with that board, who's gonna review this? |
|
Maybe at the Hack'n'ACK someone can review? |
boards/saml21-xpro/Makefile.include
Outdated
There was a problem hiding this comment.
s/arduino due/saml21-xpro/
|
ok, this PR is a bitch to review (too many large header files). Let's do the following: you fix the few comments I had and show me that the board is working and we merge this PR. Then we can fix any stuff that we find afterwards. |
Somehow I can't get the PLL to clock the board with 48MHz. But I've set the speed to 16MHz, can we keep that for now? |
|
Fine for now I guess. I have it on my list to look at the PLL stuff, maybe in the end of this week... |
|
@haukepetersen ping You've seen this working, right? |
|
@haukepetersen has probably still >800 GItHub notifications. No chance to trigger him this way. ;) |
|
Yes, I have seen this working. And there are still open comments above :-) |
|
@haukepetersen The leds are fine now. Anything else? |
|
Hm, follow-up PR's are coming. @OlegHahm, if I give you remote access, would you take a look? |
|
Sure - will be difficult to test the leds though. ;) |
|
|
Then lets wait for Travis and merge! |
|
actually there's a problem with SPI at 16mhz, works fine with 4mhz. Its weird, because the formula for calculating the baudrate is so simple. I only tested initialization of ng_at86rf212b, maybe something is going too fast at 16mhz... Still I'd like to merge and find a solution an another PR. |
|
The at86rf212b is picky with the timings between the bytes as well, not
|
|
C++ header guards are missing in |
I solved this by putting the #include of the first atmel header within |
|
Maybe you can modify the script, to exclude certain directories from the check? I just want to make sure, that the other Travis scripts are ran and show no errors. |
|
I'll take a look... |
|
|
Doesn't seem very scalable 😉, but will work for now and is out of scope for thie PR. |
|
@gebart Found it, it was spi_transfer_byte not waiting for receive to finish when Will commit in a follow up, I'm tired of rebasing & squashing & waiting again for travis. :) |
|
Somehow your last commit keeps on causing Travis to hang. I have no clue why. |
|
Runs without problems on my laptop though, apart from Merge at will. |
seems like cppcheck takes too long on the atmel headers... I'll add an exclude mechanism to cppcheck. |
basic port, uart, one timer, gpio, spi working.
|
|
|
And most applications faill to build. |
|
@OlegHahm: adaption to the new THREAD_defines was missing. Compile-test works flawlessly now. |
|
We could save travis the work... |
|
@OlegHahm The syscalls will be dropped in a follow-up PR. |
|
Compile tests work here as well. ACK and go. |
cpu: saml21 initial commit
basic port, uart, one timer, gpio, spi working.
Needs MCU support patch for openocd. [1]
My work on this port was mostly paid by FreshTemp, LLC. Thanks, guys!
[1] https://www.mail-archive.com/[email protected]/msg07241.html