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,
al
LPC2136 UART1 Hardware Flow Control
Started by ●September 6, 2005
Reply by ●September 8, 20052005-09-08
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@lpc2..., "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,
> al
section, it has a pretty well worked out ISR driven UART I/O. You can
build your handshake over that if needed.
--- In lpc2000@lpc2..., "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,
> al
Reply by ●September 12, 20052005-09-12
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,
al
--- In lpc2000@lpc2..., "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@lpc2..., "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,
> > al
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,
al
--- In lpc2000@lpc2..., "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@lpc2..., "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,
> > al
