cpu/stm32x: unified UART driver implementations#6187
cpu/stm32x: unified UART driver implementations#6187haukepetersen merged 3 commits intoRIOT-OS:masterfrom
Conversation
4d45b8c to
f3f232a
Compare
|
restarted Murdock (as he was confused by the 'waiting for other PR' label) |
|
|
||
| /** | ||
| * @name UART configuration | ||
| * @brief UART configuration |
There was a problem hiding this comment.
I noticed this also in other PRs. What is the deal with this extra space?
There was a problem hiding this comment.
Also, check if this parses still correctly. Without the name the sectioning in the doc often isn't correct anymore (and the brief of the group is added to the first element)
There was a problem hiding this comment.
Actually, I have never spend much thought on this -> I have been using brief for everything for the last 2 years I think...
About the spaces: they are there to have a unified indention in a doc comment, so if you use e.g. return, note, and brief in one block, their texts all start at the same col.
f3f232a to
12838c5
Compare
|
rebased |
12838c5 to
a8ae260
Compare
|
rebased again |
a8ae260 to
0f16c01
Compare
|
fixed some issue with the c++ compiler and rebased. |
|
needs rebase |
0f16c01 to
55c6c45
Compare
|
rebased |
|
Successfully tested on 3 nucleo boards : nucleo-f030, nucleo-f070 and nucleo-f401 |
|
@kYc0o: could you be so nice and test on the |
|
@kYc0o, @haukepetersen, just tested iotlab-m3 : the shell works. Also tested all nucleo boards except f091, f207 and f334 => OK I tend to give an ACK. |
|
Me too :-) |
aabadie
left a comment
There was a problem hiding this comment.
Let's give an ACK on this one. I tested on all the board I have here and all worked well.
Now finally also a shared UART implementation for all the
stm32xCPUs.This PR shares two commits with #6186 (centralizing of periph_apb_clk).NOTE: Currently I dropped the DMA support (offered previously by
stm32f2andstm32f4). Especially when used with STDIO and then using printf/puts from ISR context, this was not the best idea to enable by default anyway... I plan to re-add this functionality again in a separate PR (together with a stm32x wide concept for DMA handling).