Forums

LPC2136/01 UART1 serial driver

Started by m_jamet August 14, 2007
Hi buddies,

I'm need to develop a full serial driver for the enhanced UART1
(LPC2136/01 device). This includes flow control, which can be
softtware (XON/XOFF), hardware (RTS/CTS or DTR/DSR) or none.
I have found many examples of simple uart drivers not using flow
control but NONE using flow control.
Can anyone may help me with this issue, since I have no idea how to
write a serial driver supporting flow control.

Michael Jamet

NB: I've heard that a complete serial driver have been developed for
eCOs. If anyone has the source files, please send them.

An Engineer's Guide to the LPC2100 Series

--- In l..., "m_jamet" wrote:
>
> Hi buddies,
>
> I'm need to develop a full serial driver for the enhanced UART1
> (LPC2136/01 device). This includes flow control, which can be
> softtware (XON/XOFF), hardware (RTS/CTS or DTR/DSR) or none.
> I have found many examples of simple uart drivers not using flow
> control but NONE using flow control.
> Can anyone may help me with this issue, since I have no idea how to
> write a serial driver supporting flow control.
>
> Michael Jamet
>
> NB: I've heard that a complete serial driver have been developed for
> eCOs. If anyone has the source files, please send them.
>

AFAIK, the majority of the physical flow-control is handled by
hardware: if there is no CTS, the UART will not interrupt for
characters, if the receive buffer gets too full, the hardware sends an
XOF, that sort of stuff.

Driver? I think that developers would like a better spec than that
before suggesting an existing driver or a design for a new one

It's not like a 'white Intel box' where, essentially, you already have
two only driver outline specs,(Windows or Linux), and they are already
completely specified, complete with how they interface with the
kernel etc.

What OS, if any?
Assembler, C, C++?
Is the driver interrupt driven? If not, where does the execution come
from? If so, how does the interrupt handler communicate with the
application?
Does the driver have to implement timeouts?
What does the driver get as input from the application? Byte stream?
Buffer pointers? Buffer class instances?
What is the driver supposed to do with received characters? Just
assemble them in some circular buffer? Notify them to the application
by setting a flag? Notify by sending a semaphore unit? Notify by
calling an app-supplied event function/method, (if so, in interrupt
state or task-state)? Pass them through a protocol-parser until a
message is complete before notifying?
How is the driver configured and controlled? Directly by disabling
interrupts and modifying hardware registers? Indirectly by submitting
a configuration message to the driver input queue?

I'm not trying to be awkward, it's just that software is awkward by
definition

Rgds,
Martin