[En-Nut-Discussion] Uart Driver

[Harald Kipp]

Hi Ralph,

At 14:58 09.12.2003 -0800, you wrote:
>It's a bit late but my take on what I would like (based on how I use the 
>uart).  I also haven't caught the whole conversation, so please excuse 
>anything already covered.

So it turns to good account, that I'm late with the
code. :-)



>Partitionable - uart logic should be able to be easily separated from 
>hardware control so that other uarts can use the bulk of the driver. rts & 
>cts handling should be separable also so that it doesn't bulk it up if 
>it's unused and so that hardware that supports rts & cts in hardware can 
>use the same control

Yes, separating the hardware part is one of the major
changes I did. Hardware handshaking and half duplex
control is included only, if the required port bits
are defined.



>Adjustable input stream size (at compile time), I run 4 fast uarts and 255 
>bytes just wasn't enough.

Input and output buffer sizes are adjustable now.



>Allocation of Uart structures on the heap (during init of the uart)

Do you think that this makes sense? I/O buffers are
allocated from heap, but most of the remaining
structures fixed routine addresses and the device
name. Filling them during init instead of making
use of the .data segment would create a lot of
code and some .data segment usage too.

Please have a look at
http://www.ethernut.de/arc/usart_preview.zip


>9 bit should be a separate driver so the complication doesn't affect the 
>standard driver. Maybe allowing you to register the device with the 
>underlying device at runtime causing the right driver to be linked ( 
>perhaps NutRegisterDevice(&uart9Bit,&uart0); )

Looks like an interesting idea...I have to think
about it.



>ioctrl should be passed the file handle not the device handle.

This is what ioctl() expects. May be you mixed up the
CRT interface with the native driver interface?

Thanks for your comments,

Harald