[En-Nut-Discussion] Help with naming another USART driver

[Ole Reinhardt]

Hi Uwe,

Am 10.12.2015 12:13, schrieb Uwe Bonnes:
> as base for device specific usart drivers we have dev/usart.c and
> dev/usart_cb.c.
> 
> usart.c can handle only one U(S)ART device per invokation, and usart_cb.c
> only handles power of two buffer sizes and stops the USART device multiple
> times during write and read. If using DMA, these stops require a lot of
> work to stop DMA and set it up anew.

To be honest, I never noticed dev/usart_cb.c. I just read the commit
message, but I have not yet completely understood, what fundamental
difference to dev/usart.c is.

> I have some WIP code in my codebase, modelled after usart.c , that
> can handle multiple devices. It reads critical values inside the
> driver code and so only needs to stop selected interrupts versus only
> versus the general stop of interrupts by the critical section in usart.c
> 
> The STM32 backend probably won't handle XON/XOFF. Software CTS/RTS is also
> not high on my focus.
> 
> The working name I use is "usart_dma", as it should cope better with DMA.

Is your new driver approach fundamentional different to those two
existing versions? And is this a new driver framework, usable for
different platforms as well? Or is this a special implementation for STM32?

I would like to not create a new, hardware dependend driver stub, but
something more universal. Something usable in polling mode, with irq
support and also with DMA, which only controls local IRQs as you
suggested. Ideally this perhaps could even be usable with the old
hardware driver implementations as well?

What about dev/usart_common.c ?

Bye,

Ole


-- 
Embedded-IT
Alter Weg 3
57223 Kreuztal
http://www.embedded-it.de

Tel.: +49-177-7420433