UART1 with LPC2138

Hello,

I need a few clarifications with using RTS / CTS with LPC2138 to communicate with a modem.

1)Is it sufficient to use RTS/CTS for flow control ? I have shorted the DSR/DTR/CD pins at the modem.The LPC pins are being used as GPIO.

2)The problem I am facing is , when I transmit about hundred bytes,the LPC stops transmitting after about 80bytes.If I transmit 70 bytes and give a delay of 100msec and then send the remaining 30bytes,it works just fine.

3)Receiving is also quite erratic.Sometimes it does not receive or sometimes it receives all characters after a random intermediate position.

Does anyone have some sample code I could look at ?I am using WinARM with some UART code I modified to do the RTS/CTS.

Cheers

sounds like a more basic problem rather than flow control with RTS/CTS.

What UART driver are you using?

Hi Stevech,

I am using a MAX3232 if that’s what you mean. There is an identical setup for UART0 which I use for programming,which works without any problems.

Thanks.

Hi,

The transmit problem has been sorted out i think.I am sending 150bytes of data.The UART buffer is sized at 128bytes.After using UART1Puts to send about 100 bytes,I am checking to see how many bytes remain to be sent in the ring buffer.When I have a free space in the buffer of >50bytes,then I send the remaining bytes with UART1Puts.This works fine.

What perplexes me though, even if I increase the ring buffer size to 256 bytes,I still face the same problem if I don’t use the above method.

The erratic Rx problem is still pending.

In the prior question, “driver” meant the software, not the RS232 line driver. I could have said UART handler.

your UART driver software should not care what the buffer size is. It should “block” until interrupts cause one or more bytes to be free in the ring buffer so that more bytes can be added. While the ring buffer is full, the calling application should block, i.e., the driver will loop or otherwise not return until the requested data is added. A properly written UART driver will cope with this and with a caller trying to send far more, in one call, than the buffer can hold, no matter the buffer size. The larger the buffer, the less chance of blocking.

Most UART drivers also have a call to learn how many bytes are free in the buffer, if the application needs to know if it would block for a call to send n bytes.

Thanks for replying.

In the prior question, “driver” meant the software, not the RS232 line driver. I could have said UART handler.

Actually I thought you might have meant that,but then I did not understand the "what UART driver" part. I downloaded some sample code from the WinARM site I think,but it was quite sometime back.I have since modified it for the RTS/CTS.I hope thats what you meant.

your UART driver software should not care what the buffer size is. It should “block” until interrupts cause one or more bytes to be free in the ring buffer so that more bytes can be added.

Yes I understand that.I am just a bit confused because increasing the buffer size to 256 bytes,did not help.I am sending only about 150bytes in a single transmission.But let me look at the code again.

Most UART drivers also have a call to learn how many bytes are free in the buffer, if the application needs to know if it would block for a call to send n bytes.

Thats what I am doing in my part of the code now ,I think.

After using UART1Puts to send about 100 bytes,I am checking to see how many bytes remain to be sent in the ring buffer.When I have a free space in the buffer of >50bytes,then I send the remaining bytes with UART1Puts.This works fine.

Regarding the AUTO RTS/CTS part,the user manual says its supported only by LPC2138/01,Iwas using some old chips,so probably I will need to get the newer ones or emulate it in the

code.

Cheers

you should not need RTS/CTS flow control if your UART code is properly implemented in the ring buffer management with blocking of the application upon buffer-full. That, instead of CTS.

RTS/CTS is used if the receiving device (PC, microprocessor, modem) cannot accept data for certain periods of time.