Lpc2000

First let me say - thanks a lot, this is a very good code example for 
beginners because it shows a lot about hardware initialisation.

Unfortunately it uses access to the UART ISR, LSR and MSR registers. 
As i already wrote, the actual errate sheet states that this might 
clear certain bits which should generate interrupts. This might clear 
these bits when reading these registers at the same time when the 
hardware wants to set them. The result is a missing interrupt. 
For that reason the errate sheet proposes to not use e.g. the 
deltaCTS bit. As far as i understand that simply means not to use an 
interrupt for the state change of CTS. But in my opinion that would 
be the only way to handle the hardware handshake WITHOUT polling 
these line especially when using baudrates of 115K and more.

I'm not familiar enough with the ARM core and the Philips parts to 
verify if the proposed workarounds are integrated in this code.
Also i can not find a simple answer to my question regarding the 
hardware handshake. Do i have to handle that completely in software 
(with the errata in the mind)?

Maybe the simplest solution would be to use the transmit FIFO with 
the lowest interrupt level. This would result in many transmit 
interrupts but within each interrupt i can check if the line is free 
for the next character. If not - wait a little time....

Does anyone have experience with that "missing interrupt problems" 
regarding the UART (also with the hardware handshake in the mind)?

Best regards,
Ünal


 
--- In lpc2000@yahoogroups.com, "lpcarmed" <lpcarmed@g...> wrote:
> Please take a look at UT050418A.zip (thanks Bill!) in the files
> section, it has a pretty well worked out ISR driven UART I/O. You 
can
> build your handshake over that if needed.
> 
> --- In lpc2000@yahoogroups.com, "uedogan" <uedogan@g...> wrote:
> > Hi Experts,
> > 
> > i'm currently designing a new project based on the LPC2136. Its 
my 
> > first ARM project (and someone gives me not much time...). I am 
> > coming from AVR and 8051 types. In such projects i always 
implemented 
> > RTS/CTS hardware flow control simply by checking the CTS state 
before 
> > sending the next characters (there where no FIFOs). 
> > 
> > Now, at first, i thought - nice, use UART1 and everything works 
> > automatically! But the more i read through the manual the more i 
come 
> > to a point where i believe that this still has to be done by 
software 
> > (e.g. evaluating an interrupt for the modem status lines, i 
believe 
> > it is DELAT-CTS). At the same time the errata sheet states that 
this 
> > would not be a good idea when also another interrupt is needed 
(e.g. 
> > for the sending).
> > 
> > Another problem is that i never used so called '550 industry 
> > standard' devices. That means that this UART1 is completely new 
for 
> > me.
> > 
> > I must tell that my protocoll does NOT allow simultanously 
sending 
> > and receiving of data. Maybe this is helpfull! So i need 
interrupts 
> > when sending is ready. I mean, data was completely shifted out, 
not 
> > only that the FIFO is empty. But again, the errata sheet states 
that 
> > there might also be problems when using the THRE interrupt (by 
the 
> > way, is that the right ones for me??). For performance reasons i 
want 
> > to use the FIFOs if possible. If not i have to do everything the 
same 
> > way as all the years before....
> > 
> > Can anyone help me????
> > 
> > Thanks,
> > Ünal