We are having issues in turning line around in sending a response to a RS485 message. We see our device responding too slowing and dropping off a mast/slave network. Time is on the order of >30mS. Need to be able to respond in < 2 mS. When there is a network of ‘just us’, it is okay. When installed with other vendor equipment it has a problem. Our observation is the timing on the out going messages.
Is there a FIFO buffer enabled on the VF50 for UART2? What we see could be explained by that. I refer to VFXXXRM.pdf, page 2669 or about. Is there some other FIFO mechanism in place? UART2 is used for the RS485 comm link.
Thanks,
Paul
The LPUART has FIFO buffers on all instances. The size depends on the instance, see also UART (Linux).
As you can see the FIFO on UART2 is rather shallow with just 8 bytes. What baud rate are you using?
Its settable upto 112500, and the timing requirement to turn around the line get exceeded. We are looking / testing how to get it down. Is there a way to set the uart to not use the buffer and go character by character?
Thanks,
Paul
FYI - Min time from receive of a token to start sending is 15 ms, which we are exceeding. After that the device can be bumped by others on the RS485 bus.
FIFO cannot be disabled as far as I understand.
At a baudrate of 115200 (I guess this was a typo) the character time is 100us. So with a FIFO of 8 characters we are at 800us, which is well below 30mS, and even below 2mS. So I don’t think that the FIFO is the problem.
How is receiving/sending implemented? Is user space involved?
Is this with the PREEMPT RT kernel or without? CONFIG_HZ_1000 and CONFIG_PREEMPT?
Hello Stefan,
We are using the CONFIG_HZ_1000. We haven’t used the CONFIG_PREEMPT config. The uart is handled in a ko module. Messages that to be sent are queued up and handled there with the protocol. The ko has the state machine for the protocol and handles all uart functions.
I would expect that stack running every mil-second would generate a response under 2 ms, and the vendor has a lot of installed devices doing that. We see >30ms reply times and that is causing other device to think we timed out.
RE Baudrate: yes a typo…
For reference, it is BACnet MS/TP. (bacnet.org)
Is CPU load high? VF50 is really rather slow, since it has only L1 cache and 16-bit memory bus. It is hard to say what exactly causes the delay. Maybe ftrace is helpful to understand what is exactly causing the delay.
We are running around 85% CPU load max, when I change screens a lot (not counting startup where is is maxed for a while). The testing we are doing is usually around 60-65%. (Reported by top).
