Hi all.
I’m using the devc-ser8250 driver under QNX 6.3 SP3 to send raw data message through a RS-232 line.
What I have seen is that the amount of bytes that can be sent in a go (with a call to the “write” function) is 2048. Could I make it bigger?
The settings are the current one with the maximum speed: 115200 bps.
By the way, do you know if there are known bugs/problems about that driver? In other system with an RS-485 line the sending delays vary from time to time.
Thanks.
Regards
Jose
Check documentation on devc-ser8250, it explains how to increase buffer size.
As for the 485 issue, the driver doesn’t know about 485 all it know is about a serial port. 485 capability must be support somehow, in some cases this can be done through hardware and it’s possible that this hardware introduces some delay.
Can you be more specific about what these delays are?
I’ve read the docs and I suppose you’r referring to -C option. If so, why does it say that the default value is 256 but it is really 2048? Sorry, I don’t understand the subject in this case. Anyway, I’ll try it.
To be more precise, I’m using a Diamond Emmerald-MM-8 RS-485 serial card which, as you stated, is in charge of dealing with the RS-485 protocol. My task under QNX 6.2.1 (sorry, I forgot to tell you that Im’ experienced the strange behaviours under QNX 6.2.1) sends a message (about 100 bytes) each 25 ms to the serial driver and I assume the serial driver (devc-ser8250) sends it with a minor delay. However, I’ve seen that the reception times goes from 10 ms to 40 ms, which amaze me (I could understand a delay introduced by the hardware, the line, and the other system that is reading the data)
Thanks
Regards
Jose
-C is canonical buffer, it uses in EDITED MODE.
-I number
The size of the interrupt input buffer in bytes (default 2048).
-O number
The size of the interrupt output buffer in bytes (default 2048).
Thanks again.
I supposed that was something concerning the interrupt matter and I’m not using interruptions.
I have tried, enarlging it to 10000 in the following way:
devc-ser8250 -u1 3f8,4 -O 10000 -I 10000 -b 115200
and it does not work. It always says that only 2048 bytes could be sent.
In order to send raw data my program is under C, and basically does:
n_bytes = write ( port_id, (void *)mess , mess_len);
regards
Interrupts handling driver for you. For each intr interrupt handler of driver read/write fifo buffer a nd place data to I/O buffer, that you read()/write(). Inerrupt fires when fifo full(when port receive data) and when fifo empty(when port send data). The size of fifo(number of not curently reading bytes when intr will ocur) set by driver option -T-t . Try set it to 8 for example, by default fifo is off.
This about 485:
openqnx.com/PNphpBB2+viewtop … t-485.html
I knew the driver interrupts for me, but I thought it was each time there were available data to be sent.
That’s why I haven’t touched the FIFO settings, leaving the default value (0).
I’ll try to play with that setting and see if it works better or not.
Anyway, I’m still amazed since the -I and -O flags do not work as expected, 
(or I’m so useless that I don’t know how to set them…)
thanks again.
I will echo qnxloaders comment:
Try enabling the hardware FIFO buffers, these are disabled by default.
add -t14 -T14 for rx and tx buffers respecitvly.
I have had problems in the past when using this driver at high data rates.
Enabling the hardware fifo solved the problem for me.
I’m not sure but I think instead of
devc-ser8250 -u1 3f8,4 -O 10000 -I 10000 -b 115200
You need to do:
devc-ser8250 3f8,4 -u1 -O 10000 -I 10000 -b 115200
The doc says: “The options are position-dependent and affect the SUBSEQUENT port”
I’d like to alert you to one unexpected feature of turning on the FIFO buffer. While throughput will increase,
latency may decrease. Why is this? When the FIFO buffer is set to 0, almost as soon as the last bit of a byte is captured, the UART can fire the receive interrupt. If the FIFO buffer is set > 0, then the UART will wait until either on of two events occurs. Either the number of bytes set is received, or no bits are received for a period of one byte. At least this is what I recall from the documentation of the 16550. This of course can have big consequences if you are waiting on one byte of data. It could take twice as long for your application to receive it.
Even so, when receiving streams of data at 115200 baud, I think you have no choice but to set the rx FIFO on.
But If I have a pulse to trigger a sending thorugh RS-232 each 25 ms, how is it possible that the sending happens between 10 and 40 ms?
I have set the rx/tx FIFO buffers and now It works better, but that behaviour remains. Is it possible that, at 115200 baud, the driver cannot deal with the UART so fast as needed and the message is cut and sent only the remaining bytes?
On the other hand, does anyone know which could be the delay introduced by the UART ST16C654 and which delay could introduce the serial driver with the FIFO buffers set>0?
1 How tell mario, try this:
devc-ser8250 -b115200 -O 10000 -I 10000 -T8 -t8 -u1 0x3F8,4
2 What is your ClockPeriod() (default 1ms), and what speed of processor?
3 What is your process priority(that receive pulses to trigger sending), and what priority of sending pulses?
4 Is driver(devc-ser8250) run only one port?