drivers/periph/uart: remodeled UART interface

[haukepetersen]

supersedes #3265

After many iterations #3265 became un-managable, so I decided for a clean approach using the latest consensus. The UART interface is now significantly simplified, only one write function remains. The concepts summarized:

• receiving is done purely ISR based
• transmitting is handled internally by the low-level driver implementation, e.g. blocking, isr-based, DMA-based

All existing CPUs are adapted to the interface changes -> dropping ~1500 lines of code :-)

I did however just adapt the UART drivers for the introduced interface changes, I did not optimize any of the drivers -> this can/has to be done CPU by CPU in follow up PRs, as this is also easier to review...

Tested for:

• airfy-beacon
• arduino-due
• arduino-mega2560
• avsextreme
• cc2538dk
• f4vi1
• fox
• frdm-k64f, only checked UART_0
• iot-lab_M3, only checked UART_0
• msb430
• mbed_lpc1768, only checked UART_0
• msba2
• msbiot
• mulle UART_0 and UART_1
• nucleo-f091
• nucleo-f303
• nucleo-f334
• nucleo-l1
• nrf51dongle
• openmote
• pba-d-01-kw2x, only checked UART_0
• pca10000
• pca10005
• pttu
• saml21-xpro
• samr21-xpro
• spark-core
• stm32f0discovery
• stm32f3discovery
• stm32f4discovery
• telosb
• udoo
• wsn430
• yunjia-nrf51822
• z1

[haukepetersen]

#4115 gives an example, how the changed interface can be utilized for improved UART driver implementations...

[haukepetersen]

@gebart, @jfischer-phytec-iot, @kaspar030: are you guys ok with these changes in the UART interface?

[haukepetersen]

rebased

[thomaseichinger]

After discussions in #3265, do we consent on this approach? Or are their any objections? @daniel-k @gebart @kaspar030 @jfischer-phytec-iot @OlegHahm @sgso @PeterKietzmann

[jnohlgard]

I like the simplified API. You have my approval.

[PeterKietzmann]

I also like the approach on the first sight. I just started to look at it again and try it with some boards

[thomaseichinger]

@PeterKietzmann Great, could you note down the boards you tested here?

[PeterKietzmann]

Of course...

[PeterKietzmann]

I placed a list of boards in the PR description above and checked some boards that I currently have available (marked them there). Until now I didn't face any problems

[haukepetersen]

damn, I actually thought we could go around testing every board, as this takes forever again... I mean this PR doesn't change anything logical in the uart drivers, so a good code review and testing of some selected boards should suffice I was hoping...

[jnohlgard]

Since this does not change the logic (much), it should be enough to do a quick manual code review, and some spot checks by running tests/periph_uart on various boards along with testing the users on any platform (stdio, gnrc_slip, drivers/xbee).
I'll try out slip on mulle/k60 some time during the weekend.

[PeterKietzmann]

I don't want to be responsible for this PR, so I leave the decision up to you ;-) ! I agree with your arguments, even if testing seems to be the "safer" way in general. With my above stated list I did STDIO checks for different hardware. @gebart wants to test slip. So the last thing to test will be drivers/xbee. Any volunteers? I don't have the hardware available. Is there anything else you want me to do @haukepetersen, @gebart ?

[haukepetersen]

@PeterKietzmann: yes, give an ack :-)

[PeterKietzmann]

ACK for the part that I tested (described above).

[haukepetersen]

thx!

@gebart: did you get to test this on the mulle board?

[PeterKietzmann]

Travis disagrees in some points :-(

[haukepetersen]

I see, will fix tomorrow.

[haukepetersen]

fixed those Travis issues: by added FEATURES_PROVIDED += periph_uart to some msp430 boards, some tests/examples were now build for these boards while not fitting memory wise...

[PeterKietzmann]

My ACK holds for the parts that I tested. But I don't dare to hit the button as this doesn't cover the whole PR. Anyone else?

[haukepetersen]

yes, with pleasure :-)

[kaspar030]

Nice one!