Subsystem for different uart implementations (e.g. peripheral UART and one over USB)

[jfischer-no]

This PR allows the use of different uart implementations (e.g. peripheral UART and one over USB).
Depends on #4114 and serves as an example for #4155 . WIP

[kaspar030]

Shouldn't we generalize this? chardevops_t?

[jfischer-no]

Ne rather not. uart (uartdev_ops_t) fits better.

I would like to use something like (sys/Makefile):

ifneq (,$(filter periph_uart_extended,$(FEATURES_PROVIDED)))
    DIRS += uart
endif

to make it less ugly :-) Any idea?

[kaspar030]

Ne rather not. uart (uartdev_ops_t) fits better.

I'm thinking, you're introducing a generic interface for read(), write(), poweron/off, and init.
The only thing uart-specific is "init", the rest would also work for, e.g., a tcp connection.

[jfischer-no]

@kaspar030 Ok, now I have understood you.

[OlegHahm]

Still WIP, I guess it won't make it for this release. @jfischer-phytec-iot retag if you disagree.

[kYc0o]

WIP -> postponed.

[miri64]

Postponed due to feature freeze

[OlegHahm]

I remove the milestone because it seems quite unpredictable when @jfischer-phytec-iot will have time to finish this work.

[OlegHahm]

Why?

[jfischer-no]

Ups, sorry, excessive cleansing. But.. there was a discussion about this during summit, and it was rejected because it caused more latencies and code.

[OlegHahm]

Thanks for the explanation.