0
\$\begingroup\$

Using my own program in PC side, I am polling data from a device in half duplex way(like in old walkie-talkie style) through USB port. This is serial communication (Baud rate is 9600 bits/s, 8 data bits, 1 stop bit, no parity). So one cannot simultaneously send and receive messages. The PC side is master, the device side is slave. When the device(using and embedded system) receives certain byte array, it processes it in a few ms of time and then sends back a byte array in response to PC(my program then processes it).

The manufacturer told me to add delay between sending and receiving such telegrams. And the protocol is fixed at 9600 baud rate meaning that one byte takes around 1ms to send or receive. So if I send 10 bytes as command and receive between 10 and 50 bytes I would need to introduce minimum 60ms of delay. But to be on the safe side I want to use 300ms delay or even more.

My question is, how long the received data can wait at the received buffer. I mean is there an upper limit for the delay time I can use in my case? And is that something to do with timeout?

\$\endgroup\$
7
  • \$\begingroup\$ It sounds like you are wanting to add a delay that is proportional to the message length. I think what the manufacturer is suggesting is a fixed delay imposed by the slave before sending its reply to the master. \$\endgroup\$
    – Andy aka
    Mar 24 at 9:36
  • \$\begingroup\$ He just means the min delay needed can be calculated by baudrate and total amount of data sent and received plus some ms processing time. But there will be some delay inside PC as well. What I was wondering if I add safety margin delay is it fine or not. I check even I need 50ms some cases I still get response when I use 1000ms delay. But wanted to be sure about the logic behind. Meaning that how long the received telegram can live in the received buffer. This is more about PC's serial COM inners rather than MCU's. \$\endgroup\$
    – user1245
    Mar 24 at 9:41
  • \$\begingroup\$ Depending on USB UART chipset and settings, it could really be anything. Even the transmit delay, not just the receive delay. Perhaps the approach of sending command, waiting with a delay, and then expecting to have received all response bytes is not right. Is there an established protocol being used, so you can e.g. expect a response to a certain command being always the same length etc? Which device it is? Link to protocol manual please? \$\endgroup\$
    – Justme
    Mar 24 at 10:19
  • \$\begingroup\$ Yes I can predict the number of bytes received so it is in protocol. So I send the command bytes and after some time passes the input buffer should be ready. I count the number of bytes at the port but after a delay before reading it to form an array in my program. So I introduce large enough delay. The polling stucks if I dont do that. One thing I dint try to monitor number of received bytes and then read the buffer instead of delay. \$\endgroup\$
    – user1245
    Mar 24 at 10:38
  • \$\begingroup\$ Usually there isn't any maximum delay. \$\endgroup\$
    – user253751
    Mar 24 at 12:46
0
\$\begingroup\$

If I were you I would try it out. It looks to me like a case where it is hard to determine afront what will actually happen. Let it run and try different delays for testing.

I think the hardware wouldn't discard the buffer that fast. What software are you using and what hardware/software is your slave would help a lot answering more precise I'd say. :-)

In a SPI-Interface it can f.e. happen that if you do not pull up csn after sending your data, the buffer will not be emptied at all (until you shut down the device since the memory is volatile). I'd assume a similiar behaviour for UART.

\$\endgroup\$
1
  • \$\begingroup\$ So it can stay there hours infinite therotically? At master side I use C# .Net WriteAsync and then Task.Delay(100) and the ReadAsync. Slave is ARM based embedded system device a black box for me, I cannnot update it. Do you know what is meant by timeout of the port in this context? \$\endgroup\$
    – user1245
    Mar 24 at 9:34
0
\$\begingroup\$

It really depends on how your USB to serial bridge works. A USB peripheral can be polled at maximum each millisecond, with 8ms and 32ms popular service times. For this reason every USB-serial bridge has an internal buffer to match the communication port with the USB transfer.

As an example the FTDI FT232R (a quite popular part) has 128 bytes in one direction and 256 bytes in the other. For optimizing the transfer usually it waits a bit before signalling received data: in this way it can send more bytes in an USB transfer and this is efficient.

This also mean that you actually get the bytes a bit later in respect to when they actually arrived: some millisecond to about 10ms is typical. There are also configuration options for the chip (using its special software) to tune the USB transfer interval or how much to wait before sending or receiving the data; it's actually quite complex and depend on your chip.

In short: usually you can't control serial transmission timing at the millisecond level. It's a serious issues for some protocols like MODBUS which relies on intrabyte timing for packet framing. As for your 300ms wait you could assume that about 10ms after your write request your data should at least have started transmitting (if you have some control on your USB bridge, like a flush command, even better). So just do a sleep after writing and let the OS do the rest.

In fact, unless you are using an RTOS your 300ms sleep would be probably a bit longer

\$\endgroup\$
1
  • \$\begingroup\$ The thing is for 10byte transmit and 10byte receive at 9600 it takes minimum 20ms and lets say processing time is 5ms and now you mention a delay due to bridge and lets say that is 20ms worst case. That makes 50ms more or less. So is there anything wrong to use 300ms or 500ms instead to be safe here? Because I want to be sure about these if other computer uses this with another USB bridge. It is okay for me to put a delay up to even 1000ms. But cannot estimate any maximum delay(sleep or wait) for the delay between sending and receiving. \$\endgroup\$
    – user1245
    Mar 24 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.