How to turn of 16Bit FIFO of Serial Ports

Hi guys

there are several Threads on this topic all of them with no answer so im taking a further try.
Ive got a display with Rs232 providing Hardware Handshake RTS / CTS which is enabled and working.

So far so good now the tricky part. The Serial Port on the PC has got a FIFO of 16 Byte but the input Buffer of the display is only able to read further 4 Bytes after RTS is set to -10V indicating that no more bytes can be received. Now as the Display sets RTS to -10V the data stored in FIFO is still sent to the display causing unwanted behaviour if more than 4 bytes are sent.

The Question therefore is. Is there a way reduce the size of the FIFO used by the USART like it can be done in Device Manager (Win XP) or to completely turn the FIFO off.

Settings made in Device Manager do have effect but as they cannot be distributed a C++ solution would be prefered

Any help will be appreciated.

Regards nobo

Maybe this link will help.

What you want to do isn't really a complete solution. Your code still needs to detect overflow conditions and react appropriately.

How are you setting up your DCB? What is fAbortOnError?

gg

Thanks jeron for the link I'll have a look at it

DCB is set in function Open see below

Which overflow conditions do you refer to? the Display sets RTS 4 bits before it is full and as I understood the device driver is featuring a buffer of 1k for Tx and Rx.

Code:

---

void Serial::Open(LPCTSTR commPortName, int bitRate){
        commHandle = CreateFile(commPortName, GENERIC_READ|GENERIC_WRITE, 0,NULL, OPEN_EXISTING,
                0, NULL);

        if(commHandle == INVALID_HANDLE_VALUE)
        {
                throw("ERROR: Could not open com port");
        }
        else
        {
                // set timeouts
                COMMTIMEOUTS cto = { MAXDWORD, 0, 0, 0, 0};
                DCB dcb;
                if(!SetCommTimeouts(commHandle,&cto))
                {
                        Serial::~Serial();
                        throw("ERROR: Could not set com port time-outs");
                }

                // set DCB
                memset(&dcb,0,sizeof(dcb));
                dcb.DCBlength = sizeof(dcb);
                dcb.BaudRate = bitRate;
                dcb.fBinary = 1;
                dcb.fOutxCtsFlow = TRUE;
                dcb.fOutxDsrFlow = FALSE;
                dcb.fRtsControl = RTS_CONTROL_HANDSHAKE;
                dcb.fOutX = FALSE;
                dcb.fInX = FALSE;       
                dcb.Parity = NOPARITY;
                dcb.StopBits = ONESTOPBIT;
                dcb.ByteSize = 8;

                if(!SetCommState(commHandle,&dcb))
                {
                        Serial::~Serial();
                        throw("ERROR: Could not set com port parameters");
                }
        }
}

---

>> Which overflow conditions do you refer to?
I was referring to what you described in post #1 - "Display" drops RTS but PC empties 16 byte FIFO anyway.
If you set DCB::fAbortOnError to TRUE, then *if* the driver can detect this scenario (not sure that it can) then WriteFile should fail and I would expect ClearCommError to return CE_OVERRUN.

>> COMMTIMEOUTS cto = { MAXDWORD, 0, 0, 0, 0};
Avoid this type of initialization. The code isn't as readable, or maintainable in the face of future structure changes (in general).

Your DCB looks good.

Since you know you're working with a 4 byte FIFO device, why not just call WriteFile with 4 bytes at a time? This should achieve the same results as setting the local Tx FIFO to 4. You could also try reducing the baud rate.

In the end, a good communications protocol can detect transmission/reception errors without help from the physical layer ("help" in this case would be detecting Tx overruns).

gg

>> Which overflow conditions do you refer to?
I see your point. If the driver realy is able to detect the RTS while sending that would be a good soultion thank you. Then the question for the drivers developer would be why not just delay the further sending and continue when RTS is high again :-).

In general the hardware handshake works as it is supposed to do speaking once the FIFO is empty a new write is delayed until RTS is high again.
Having the FIFO turned of by device manager the communication works perfect.

The code I am writing is going to be a .dll beeing a driver for Matlab. So the point of just sending only 4 bytes would be a solution at the cost of convenience

>> COMMTIMEOUTS cto = { MAXDWORD, 0, 0, 0, 0};
good point that was a copy paste section I'll redo it

I tried to reduce Baud rate but to realy fix the problem i had to lower it so much that the performance of the application as a whole suffered.