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

[Uwe Bonnes]

>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
...
    Ole> To be honest, I never noticed dev/usart_cb.c. I just read the
    Ole> commit message, but I have not yet completely understood, what
    Ole> fundamental difference to dev/usart.c is.

The functions called by dev/usart.c do not get an argument indicating the
calling instance. So the hardware driver doesn't get transmitted what UART
it should serve. The uart used is hard-coded in the driver instead. This
leads to multiple driver loaded for multiple uarts.  Any driver usable for
multiple uarts must get some indication of which uart to use. usart_cb.c
calls driver functions with DCB in the argument, allowing one hardware
driver for multiple uarts, with the used UART indicated somehow in the DCB.

usart_cb however is not well suited for a uart hardware using DMA, as it
requires the send/receive buffers to be always up-to-date. IRQ driven, the
this can be done. But with DMA an extra call to the hardware driver is
needed to get the buffer updated. So using usart_cb for (STM32) DMA driven
driver would require some API change, touching hardware drivers in other
archs. As there are already implemented usart_cb hardware drivers for archs
I don't have, changing the old drivers is not testable for me.  So I vote
for another driver to not break existing drivers.

    >> 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.

    Ole> Is your new driver approach fundamentional different to those two
    Ole> existing versions?

As explained above, there are diffences. And I also want to get rid of what
I think is "legacy", see below. If this legacy is needed, the old drivers
can be used.

    Ole> And is this a new driver framework, usable for
    Ole> different platforms as well? Or is this a special implementation
    Ole> for STM32?

My proposal is usable for any platform, polling, irq and dma driven, but not
tested on other platforms

    Ole> I would like to not create a new, hardware dependend driver stub,
    Ole> but something more universal. Something usable in polling mode,
    Ole> with irq support and also with DMA, which only controls local IRQs
    Ole> as you suggested.

    Ole> What about dev/usart_common.c ?

Thats a good idea, but the name implies some general implementation where I
can only provide a STM32 hardware driver implementation :-(

    Ole> Ideally this perhaps could even be usable with
    Ole> the old hardware driver implementations as well?

There are API and structure changes that make keeping interoperability
hard. usart_cb did not do it neither. And I wanted to keep the driver "small
and "simple".
Some changes:
- I do not keep count of the bytes available in the buffer as seperate
variable. Instead it is calculated on the fly when needed, making use of the
atomiv access also for 32-bit variables on cortex. I didn't manage
to keep rbf_cnt in sync without stopping (DMA/IRQ) transfers again and again.
- A lot of the usart.h DCB functions are now IOCTLs. This brings down DCB RAM
usage.
- I don't see the point of the watermarks in a general driver, so I left
them out. If needed, the old drivers can be used.
- I don't care for synchronous mode. I.m.h.o. this is better handled by an
spibus driver.

How to best publish a preview?
- separate SVN branch
- introduce dev/stagging for drivers where the API is not yet fixed?
- a tar.gz file in private mail?

Thanks for the feedback
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------