Lpc2000

Hi,

I'm implementing a comms protocol which requires RS485 half duplex comms with a 9 bit data word for the first byte. I'm new to the LPC214x chips so was wondering if anyone could give me some pointers. My thoughts are described below.

Half Duplex Comms
It looks like UART0 and UART1 have both FIFO empty and ShiftRegister empty Flags, IF you enable the THRE interupt enable bit in UxIER, you will recieve an interupt if the FIFO is empty, but the shiftRegister could still contain data being transmitted. You have to wait for the TEMT bit in UxLSR to be set. It looks like you have to poll this bit, it is not associated with an interupt, is this right? What is the point of having this bit if it doesn't cause an interupt?

9 Bit Comms TX
This is a bit more tricky and to transmit a character with the 9th bit set I guess you need to do the following.
1. Set Parity bit to "Forced 1 stick parity"
2. Enable Parity
3. Transmit first character
4. Wait for first character to be transmitted by monitoring the TEMT bit (Same problem as above as you need to poll this bit)
5. Disable Parity
6. Transmit the rest of the message.

9 Bit Comms RX
This is even more of a bodge, I'm guessing you could disable parity then use the PE (Parity error) bit to wake up a reciever to the fact that it is recieving the first byte of a message, with the 9th bit (parity bit) set. Reading the data sheet it looks like the the recieved data is still in the FIFO. You would just use this PE to indicate the start of a message.

Does the above tie in with other peoples experience of using these LPC chips in this mode. Philips do seem to make it overly complex to implement these sort of comms protocols, which embedded systems do seem to use.

All ideas and comments greatfully recieved.

Martin 



[Non-text portions of this message have been removed]

mhoneywill wrote:

>Hi,
>
>I'm implementing a comms protocol which requires RS485 half duplex comms with a 9 bit data word for the first byte. I'm new to the LPC214x chips so was wondering if anyone could give me some pointers. My thoughts are described below.
>
>Half Duplex Comms
>It looks like UART0 and UART1 have both FIFO empty and ShiftRegister empty Flags, IF you enable the THRE interupt enable bit in UxIER, you will recieve an interupt if the FIFO is empty, but the shiftRegister could still contain data being transmitted. You have to wait for the TEMT bit in UxLSR to be set. It looks like you have to poll this bit, it is not associated with an interupt, is this right? What is the point of having this bit if it doesn't cause an interupt?
>
>9 Bit Comms TX
>This is a bit more tricky and to transmit a character with the 9th bit set I guess you need to do the following.
>1. Set Parity bit to "Forced 1 stick parity"
>2. Enable Parity
>3. Transmit first character
>4. Wait for first character to be transmitted by monitoring the TEMT bit (Same problem as above as you need to poll this bit)
>5. Disable Parity
>6. Transmit the rest of the message.
>
>  
>

I've a 9bit comm running now using an LPC2138 and LPC2106, both 
processors are using the internal uarts to do 9bit communications.  You 
are correct, you must turn off the fifo for this to work, if you don't 
disable the fifo then the wrong bytes get the wrong stick parity.

This will work primarily with half duplex operation as you are going to 
have to flip the parity bit from mark / space on the transmitter.  If 
you attempt full duplex operation, then bytes coming the receive side 
may have the wrong parity detection as the parity has been changed due 
to a need of the transmit.

To receive the 9th bit, simply look at the UxLSR register to see if 
there was a parity error.  if you set SPACE parity and got a recieve 
parity error, then you know the 9th bit was "set".

BTW,  I am running under full interrupt I/O on those fake 9bit ports...  
You don't need to poll.


TomW


>9 Bit Comms RX
>This is even more of a bodge, I'm guessing you could disable parity then use the PE (Parity error) bit to wake up a reciever to the fact that it is recieving the first byte of a message, with the 9th bit (parity bit) set. Reading the data sheet it looks like the the recieved data is still in the FIFO. You would just use this PE to indicate the start of a message.
>
>Does the above tie in with other peoples experience of using these LPC chips in this mode. Philips do seem to make it overly complex to implement these sort of comms protocols, which embedded systems do seem to use.
>
>All ideas and comments greatfully recieved.
>
>Martin 
>
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Thanks Tom, for the quick reply.

> I've a 9bit comm running now using an LPC2138 and LPC2106, both 
> processors are using the internal uarts to do 9bit communications.  You 
> are correct, you must turn off the fifo for this to work, if you don't 
> disable the fifo then the wrong bytes get the wrong stick parity.
> 

I will try what you suggest to transmit the 9th bit. Do you turn the
FIFO off permanently, or only when you are transmitting the start byte?

> BTW,  I am running under full interrupt I/O on those fake 9bit
ports...  
> You don't need to poll.
> 

Are you using RS485 comms for half duplex. Do you have any thoughts on
how to control the RS485 transmitter. It looks to me that you are only
safe to turn the RS485 transmitter of when the TEMT bit in UxLSR is
set. If my reading of the data sheet is correct this bit does not
cause any interupts. It can only be polled. :-(

Cheers

Martin

mhoneywill wrote:

>Thanks Tom, for the quick reply.
>
>  
>
>>I've a 9bit comm running now using an LPC2138 and LPC2106, both 
>>processors are using the internal uarts to do 9bit communications.  You 
>>are correct, you must turn off the fifo for this to work, if you don't 
>>disable the fifo then the wrong bytes get the wrong stick parity.
>>
>>    
>>
>
>I will try what you suggest to transmit the 9th bit. Do you turn the
>FIFO off permanently, or only when you are transmitting the start byte?
>
>  
>
Absolutely, it would be impossible to use the fifo when changing the 
stick parity state.  If the fifo is used, you would be, potentially, 
changing the parity state for the entire stack of chars, not just the 
one you want.

>>BTW,  I am running under full interrupt I/O on those fake 9bit
>>    
>>
>ports...  
>  
>
>>You don't need to poll.
>>
>>    
>>
>
>Are you using RS485 comms for half duplex. Do you have any thoughts on
>how to control the RS485 transmitter. It looks to me that you are only
>safe to turn the RS485 transmitter of when the TEMT bit in UxLSR is
>set. If my reading of the data sheet is correct this bit does not
>cause any interupts. It can only be polled. :-(
>
>  
>
Timers are good... I use ushort buffers, not uchar buffers, to  store 
9bit bytes for TX & RX.    Two special char patterns are fed to the 
serial port software layer.  I use these two chars to modify the 
behavior of the RS485 transciever: RS485_TX_MODE & RS485_RX_MODE.  So, 
using  the serial port becomes:

serial0send(RS485_TX_MODE);
serial0send(Address);
serial0send(data);
serial0send(data);
serial0send(data);
serial0send(RS485_RX_MODE);

As each special char is seen by the serial driver, various responsive 
actions are performed.  e.g.  RS485_TX_MODE switches the transceiver 
into TX mode, delays for a fixed period (line precharge time) and then 
starts putting data out the UART into the RS485 circuit..

TomW




-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Martin Honeywill wrote:
> I'm implementing a comms protocol which requires RS485 half
> duplex comms with a 9 bit data word for the first byte. I'm new
> to the LPC214x chips so was wondering if anyone could give me
> some pointers.

Depends on the baud rate. For a vending machine app (9600 baud) 
we just bit-banged the 9 bit ports using a timer interrupt and a 
state machine. This left the UARTs for high speed use. Oh, the 
joys of 60MHz single chip CPUs.

Stephen

--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 23 80 631441, fax: +44 23 80 339691
web: http://www.mpeforth.com - free VFX Forth downloads