Implementing a flow control (RTS/CTS) for SCI

[zonte]

Hi!!

I am trying to implement a flow control (RTS/CTS) so I can be able to download a textfile using the serial port and the hyperterminal. After I have sucessfully recevied the text file I will transmit it using the SMAC protocol.

I am using 2 SARD boards, SMAC 4.1a .

The problem that I am having is that I cannot receive all bytes and program them to the Flash at the same time. I have to tell the PC (hyperterminal) to stop sending me more bytes (so I need a flow control).

I have checked the board schematic and the RTS and CTS pins are connected to the DB9 terminal, so I don't need any other connections. I was planning to declare the CTS pin as a KBi or just an input pin and RTS as an output

How is the logic from the RTS/CTS flow control? If I receive a logic 1 in the CTS that means the PC ir ready to transmit and if I put the RTS high that means I am ready to receive??

Any suggestions on how to implement this?

Thanks

[tonyp]

For text-only (ASCII 32 or above) sequences, software (X-On/X-Off) flow control is also a good option as it uses no extra pins.  HyperTerm as well as most other terminal emulators support it.

X-On is CTRL-Q [think of "queue some more"] and X-Off is CTRL-S [think of "stop"].

[peg]

Hi,

The OP said he is using SARD boards here so the pins are already dedicated to HW handshaking so why not use them.

This is the OP's first post so I was just covering all bases, thinking maybe his original concept is perhaps flawed.

Buffering the data will assist to burst programme the flash as well!

The problem with HW handshaking on a PC is it is implemented by the programme and not the OS or even any standard drivers so you don't know what to expect if you are not in control of the PC end. Some PC programmers idea of HW handshaking is very strange indeed!

Mac, now you have got me checking out the tx buffer thing for sure.

Regards David

Later....

From National Semiconductors page for the PC16550D:

The PC16550D is an improved version of the original 16450 Universal Asynchronous Receiver/Transmitter (UART). Functionally identical to the 16450 on powerup (CHARACTER mode)* the PC16550D can be put into an alternate mode (FIFO mode) to relieve the CPU of excessive software overhead.

In this mode internal FIFOs are activated allowing 16 bytes (plus 3 bits of error data per byte in the RCVR FIFO) to be stored in both receive and transmit modes. All the logic is on chip to minimize system overhead and maximize system efficiency. Two pin functions have been changed to allow signalling of DMA transfers.

And there are devices with bigger buffers as well!

Message Edited by peg on 2006-06-24 10:51 PM

[bigmac]

Hello,

---

peg wrote:

From National Semiconductors page for the PC16550D:

The PC16550D is an improved version of the original 16450 Universal Asynchronous Receiver/Transmitter (UART). Functionally identical to the 16450 on powerup (CHARACTER mode)* the PC16550D can be put into an alternate mode (FIFO mode) to relieve the CPU of excessive software overhead.

In this mode internal FIFOs are activated allowing 16 bytes (plus 3 bits of error data per byte in the RCVR FIFO) to be stored in both receive and transmit modes. All the logic is on chip to minimize system overhead and maximize system efficiency. Two pin functions have been changed to allow signalling of DMA transfers.

And there are devices with bigger buffers as well!

---

Yes, I believe FIFOsize up to 64.  I am not sure of the situation when USB-to-serial converters are used.

However, this is important when using handshaking to prevent receive buffer over-run in the MCU.

In zonte's case, assuming a buffer of adequate size is used, handshaking would be likely to occur after data has been received (and the FIFO at the other end is empty), and the received data is about to be processed.  This situation can probably be ensured by checking for Idle line condition immediately before de-activating CTS.

For other cases where receive buffer over-run must be prevented, the required handshake threshold that needs to be allowed would probably depend on whether the CTS signal  has any direct control over FIFO output.  I am not familiar enough with the UART devices.

For Xon/Xoff handshaking, we could probably assume that the FIFO would need to become empty for transmission to cease.

I guess I will need to conduct some actual tests using various terminal emulation programs to see what the typical situation is likely to be.  We seem to be opening a Pandora's box.

Regards,
Mac

[peg]

Hi Mac,

AFAIK...

CTS does not actually do anything in a UART other than set/reset a bit in the modem status register and potentially generate an interrupt on state changes.

RTS is also not directly set/reset by any conditions generated inside the UART.

This is what I was saying before about it all being up to the programmer of the communications programme that you are using.

FIFO's only add further to the problem at the DCE end. They are only there to make up for the fact that Windows (etc) is always doing 87 things at once.

Regards David

[bigmac]

Hello zonte,

It would appear that you need flow control in only one direction, so you would utilise the CTS output signal to temporarily inhibit the PC from sending further data.  I will assume that the signal directions are for the MCU operating as DCE, so the PC serial port (DTE) will directly connect to the MCU serial port (without requiring a null modem cable).  So CTS is actually an output signal at the MCU.

Assuming you are using an inverting output buffer for CTS (such as MAX232, or similar), it should simply be a matter of setting the port pin when you require to disable PC transmissions, and clearing the port pin to re-enable transmissions.  However, transmissions must be disabled at least one character transmission period prior to your inability to receive further data, to allow for any character already in progress.

Regards,
Mac

[rocco]

---

bigmac wrote:
. . . However, transmissions must be disabled at least one character transmission period prior to your inability to receive further data, to allow for any character already in progress.

---

I don't know if this is still true, but you may have to allow for up to 16 characters.

I had problems with PC serial ports where the uart's buffer had to empty before the data would stop, once I de-asserted CTS. The PC serial driver would stop, but the uart hardware kept going until it was empty.

Message Edited by rocco on 2006-06-23 12:25 AM

[peg]

Hi,

Firstly, Why are you programming the downloaded data to FLASH?

You will need to flow control it to get it into flash so why don't you flow control it until it is sent out over the air?

Still you need the the flow control so...

You have several options:

1. Make a RAM buffer big enough to hold the entire file. Easy if you can.

2. Have a RAM buffer with a high level sufficiently far from the full point to allow for those pesky bytes in the FIFO. Then assert CTS and wait until the buffer is empty and de-assert it.

3. Have a RAM ring buffer, with a getting full point to assert CTS and a getting empty point to de-assert CTS. If you use a 256 byte buffer you can utilise rollovers to make the code easier

HTH

Regards David

[bigmac]

Hello,

My interpretation of this issue was that it was not really a question of adequate receive buffer size, but the fact that interrupts would need to be disabled during flash routines, including the SCI receive interrupt.  So handshaking would be required to prevent potential loss of incoming data during this period.

I take Rocco's point that there might need to be significantly more delay between deactivating the CTS signal and the disabling of interrupts preparatory to flash procedures.  I had previously considered that hardware handshaking would be more responsive than software (Xon/Xoff) handshaking, but perhaps this is not always the case.

I might need to review the situation for my own projects that utilise hardware handshaking to control buffer over-run.  I certainly did not allow a threshold level of as many as 16 characters before the buffer full condition, but I have not had reports of missing characters over many years of operation of the equipment.  Does the 16 character FIFO size also apply to the UART transmit path, as well as UART receive path?

Regards,
Mac