Losing data in serial communication (in QNX 4.25);

QNX USERS QNX2 and QNX4
1

I’ve got two computers ( one with QNX 4.25 and one with QNX 6.3.2 )
connected with each other by RS-232
(3 wire: rx, tx, gnd; 2m long; no handshaking; 115200-8-N-1).

Serial communication ( /dev/ser/1 read() / write() )
works fine on QNX 6.3.2,
but QNX 4.25 is losing received data (tx is ok).

I try to set higher priority ( setprio() )
increase stop bits to 2,
but data is still losing, event at 38400-8-N-2 :frowning:.

What is wrong ?

/the program works fine @115200,8,N,1
between QNX 6.3.2 - QNX 6.3.2
and beetween QNX 6.3.2 - Windows XP
and

2

Oink,

Without seeing the code under 4.25 it’s hard to know if there is any coding errors there.

That aside, do you know for sure if the hardware Uart on the 4.25 machine is capable of handling sustained speeds at those baud rates?

The first thing you need to determine is if this is a hardware or software issue.

Tim

3

there are no errors in code :slight_smile:.
“receive data” is made up on thread with Receive() loop that catches proxy triggering;
/ basicaly it is: dev_arm() → wait_for_Trigger() → dev_state() → read() → dev_arm() → …

program is doing 6-bytes frames ping-pong;
/tx 6 bytes, than waits for rx 6 bytes, and than tx 6 bytes, …

its not the rx buffer size (which is 2048 default ( Dev.ser -I ) ),
casue main program do just 6-bytes frame ping-pong;

4

the code is good because its simple :slight_smile: and it works better with decreasing uart speed:

  • it works fine @ 9600-8-N-1 and also works fine @ 19200-8-N-2;

and the hardware is fast enough - Celerons above 500 MHz with no other tasks in background.

5

You are transfering data very quickly over a serial link without the benifit of a handshake.
You insist that the code is correct and that the cpu is fast enough. I think you should be a little more skeptical. You did not mention which UART, but I think all UARTs capable of 115200 baud have a 16 byte buffer at least. If your protocol is to send 6 bytes, then wait for six bytes, the cpu speed should not matter, as the UART buffer cannot be overrun. This is true even if the driver is dumb and doesn’t understand buffered UARTs. That would leave only one possibility, which is noise on the line. But noise would not likely be uni-directional. If your protocol is not as described, and you are getting a buffer overrun of some kind, then you might have competition for the cpu as a problem. If you are only running this application on QNX4 and it still happens, then I would review your presumptions. I would definitely test with Photon turned off, as we found a similar problem with a desktop utility hogging cpu a few weeks ago. In that case it was QNX 6 Photon that had the problem, but I would still try without Photon.

If none of this works, you should definitely reconsider posting code.

6

Dev.ser -t 14 &

solve my problem :slight_smile:
/by default fifo is set to 0 :frowning:.

ps
“Dev.ser -t 14 &” set fifo to 14, but what fifo? rx? tx? both?

7

Sets for both

8

Means something different for each. For the receive buffer, it indicates when the buffer is filled up to that level, so you might want it on the low side. At 14 you only have the time it takes to receive two more bytes before you overflow. The transmit buffer is much less of concern. It tells you when there are only N bytes left. Underflowing the buffer causes no problem other than loss of throughput.

I’m really surprised that setting this fixed the problem. The 16550’s I worked with were supposed to use the receive buffer even when in 16450 compatibility mode. That means that if a second byte came in before the first was read, it would be stored. A really old driver that only read a single byte when the interrupt occured might lost the second byte, but I’m sure that the QNX 4 driver does not have this probelm.