[OT] RS232 Software flow control

[newpicer_]

Hi all,

I need to implement some kind of flow control on a binary packet communication between pic and PC. The pcb has only tx/rx pins conected, so I'll need software flow control.

The question is: Can I make the comms 9-bit and choose the xon/xoff character so that both has the parity set and normal packet data has parity bit clear? The only problem I see is clearing the parity bit at the PC side. Is there a better idea?

Thank you.

[RLScott]

Well, you have posed a difficult problem. If your primary protocol were ASCII, then you could have used the standard X-ON/X-OFF characters to implement flow control. But you say your protocol is binary.

Now there are various ways of implementing a binary protocol. One is to send blocks with a header that specifies the count of binary characters in that block. This method has synchronization problems. Another way is to establish an "escape" character. If that escape character happens to be part of the binary data, then the escape character can be repeated in the transmission, and then removed on the receiving end. The disadvantage of using an escape character is that the length of the transmission is variable, depending on content.

If you use blocks, then the flow control has to wait until the end of the block, which is probably not responsive enough for you. If you use an escape character, then the flow control could in principle kick in on a character-by-character basis (but see the caveat about Windows below!).

Your idea of using the 9th bit as an "escape bit" could work, if you can generate it on the sending end and detect it on the receiving end. The trouble is I don't know if you are going to be able to implement 9-bit comm at the PC end.

Regardless of which method you use, you have to allow for software response to flow control requests. For example, if the PC is sending and the PIC is receiving, then if the PIC wants to pause the transmission from the PC, it will send some flow control character to the PC. But that will not immediately pause the flow. You are depending on the software in the PC detecting that flow control (like X-OFF) character and suspending its transmission. But if the PC application needs to do this, then the latency on the PC might mean tens of milliseconds before it responds. And if the PC application is using Windows Comm buffering, then there might be hundreds of characters already delivered to the operating system and buffered there. The application would have no way at that point to "recall" the characters it has already released to the operating system. So your PIC will have to be able to continue to receive data for quite a while after it requests a flow control pause of the PC.

If you were to use standard ASCII and X-ON/X-OFF flow control, then it is possible to configure the Windows Comm to handle flow control at the device driver level (instead of the application level). This will improve the flow control responsiveness to maybe a couple of characters. But you would have to use standard ASCII, not binary with escape characters nor your custom 9-bit flow control.

Now, if the PC end is not Windows, but is DOS or something where your application gets to handle the UART on the PC directly, then you could guarantee 1-character response to flow control, and you could use your custom 9-bit idea or escape characters.
_________________
Robert Scott
Real-Time Specialties
Embedded Systems Consulting

[newpicer_]

Hello Robert,

Yes, the PC side runs windows... I didn't tell everything in my first post, the pc's serial port is actually a ft232. If I had spare pins on the pic I would just solder wires there and have the hardware flow control.

The ascii packet would work for lower speed tranfers. I don't think that the pic would stand decoding hex strings at 500kbps along with the other firmware tasks.

As it is now the comm works up to 115.2k, failing at 230.4kbps. I am almost sure that the ft232 buffer is overflowing, because changing its reading delay also changes the max transfer speed without buffer overflows.

[treitmey]

I use the FT232 and FT245. You may be able to get at the 9th bit. Ive never tried. but the d2xx drivers are powerful. Are you using the direct drivers and C#? Perhaps I could share a little code to get you started.

btw. If you can beg borrow a pic pin(osc2) from anywhere I'd say your better off with hardware flow control.

[FvM]

Other than supposed, FTDI chips don't support 9-Bit transmission, neither in VCOM mode (not supported by Windows COM-port driver) nor in d2xx mode. I would use one of the many existing binary package protocols instead, e.g. 3964R. As an advantage, you can use any UART link and aren't restricted to special drivers.

[Guest]