In most examples (from Arduino/STM32/whatever) I see timeouts of 10 to 100 ms for different kind of communication.

However, I am wondering how much 'overhead' there is. Assuming I want to send 8 bytes (including stop bits + overhead, via RS485, 2.5 mbps), and getting a response back (let's say also 8 bytes). This would take: 64 bits / 2500000 bits/s = 32 us.

Now there needs to be some processing (interrupt handling) from both sides (sending + receiving). I'm using HAL which has some more overhead maybe, so let's take a huge 10,000 instructions. On a 72 MHz CPU this would take 10,000/72,000,000 = 138 us.

This totals less than 200 us together... Do I miss something?

(note that I intend to use interrupts, and probably later DMA since it will even have less overhead high likely).


  • Communication from an STM32F103C8T6 to another STM32F103C8T6
  • Both running at 72 MHz
  • RS-485 via UART, 2.5 mbps
  • There are no other higher priority interrupts (that can block UART)
  • Requirement: not hard, but preferably multiple messages within 1 ms.
  • 1
    \$\begingroup\$ Who are you communicating with, what are the specifications? There should be ICS (inter char spacing) specifications to which you have to abide. If you're communicating with yourself, you can specify your own to be less than 0,2ms and then you good to go.. \$\endgroup\$
    – Andrés
    Commented Jul 30, 2018 at 12:50
  • 1
    \$\begingroup\$ I guess those examples really don't care about timing and are randomly thrown. But there are some devices/IC that takes their time to process the data that you sent , so you need to see what processing time the other IC is taking in consideration when communicating. \$\endgroup\$
    – MaNyYaCk
    Commented Jul 30, 2018 at 12:53
  • 3
    \$\begingroup\$ You need to consider the other interrupts that might occur. Are there higher priority interrupts that can block the UART? You haven't told us anything about that. \$\endgroup\$ Commented Jul 30, 2018 at 12:58
  • 1
    \$\begingroup\$ Not that it adds much, but serial comms is usually 10 bits per byte on the wire. (N,8,1 setup). The HAL is a bit opaque for a lot of stuff, and some examples I have seen take quite a while to actually get to the interrupt handler although they were edge cases. \$\endgroup\$ Commented Jul 30, 2018 at 12:59
  • 1
    \$\begingroup\$ Why would you want to use a UART timeout feature? Not all comms systems do? Have you a specific reason? \$\endgroup\$
    – Andy aka
    Commented Jul 30, 2018 at 12:59

2 Answers 2


The answer is, unfortunately, "it depends".

What are you talking to? What kind of processing do the nodes have to do before they can respond? How long does it actually take for the signal to travel along the cable and be received (this only really matters for REALLY long RS485 links)? What are the limits (driver enable and turnaround) on your RS485 drivers?

Timeouts are always a good idea -- they ensure that no matter what happens on the wire, your device will respond in a predictable and controlled manner. It means your protocol will be more robust and a comm glitch won't kill the link. However, 200us seems really tight and I have to ask why you would want to enforce such a fast timeout? 2.5mpbs is pretty fast, but you are talking about RS485 and need to manage the DE and inter-frame timing as well: have you given these items any thought because they have a direct impact on the link capabilities and ultimately your timeout value.

If you're using UARTs with hardware driver enable assist this is a bonus, especially at such high data rates; otherwise you're going to be either spinning waiting for the transmit shift register to be empty (NOT the holding register!) or incurring extra interrupt processing to turn the driver off when the last bit has been put on the wire. Some drivers also require an additional bit of time before being disabled which can add some more time to the equation.

What provisions does the protocol you're using have for data integrity? Do you have to calculate CRCs or enforce actual parameter integrity? These will eat up reception and packet processing time as well, especially if you don't have hardware assistance. Does the protocol allow for packet fragmentation or out of order transmission and reception? What happens in the case of a collision? You've not given nearly enough information and I suspect from the style of your question that you've not given these important things the thought they require for us to be able to answer your question properly.

Take some time and think through the problem. 2.5mbps on a system with a 72MHz clock doesn't have a lot of time to spend on these things, particularly if you're doing other data processing in addition to running the comm link. The processing power involved isn't a lot, but you seem to be intentionally tying one hand behind your own back and giving yourself a much more difficult problem without a good reason.

And finally -- if at the end of the day you want to wing it... why not just pick a number for timeout and experiment? Load the systems down, give yourself the longest physical link, make it kind of shitty, add some noise and uncertainty, elevate the temperature and see where the system starts to break. In reality you'd be ideally doing this anyway.

  • \$\begingroup\$ Thanks for this elaborate answer (I used my votes so I will upvote tomorrow). You gave me a lot of things to think about. Some where I know the answer from (like I have very short cable, actually I'm planning to connect them connector to connector, so only internal AWG wire), I would have to check the limits for the RS485 drivers. I want a 200 us timeout because I want to do like 5 of such messages (between different devices) within 1 ms. I'm using STM32F1's UARTs, so I assume these have hardware acceleration. \$\endgroup\$ Commented Jul 30, 2018 at 14:51
  • \$\begingroup\$ I am using HAL so I guess it will take care of the inter-frame, the DE I can set (GPIO pin toggle). I am assume I can use the UART interrupts generated by HAL. Data processing is light, but indeed, CRC checks I had in mind, and possibly retries in case of a comm/CRC problem. However, maybe even more important is just try. Maybe I want to think ahead too much. Or solving problems which are not existing yet. \$\endgroup\$ Commented Jul 30, 2018 at 14:53
  • 1
    \$\begingroup\$ HAL has nothing to do with the inter-frame timing comes; this comes from the protocol you implement. Basically "when am I allowed to send data". I do believe that the HAL enables hardware driver control for UARTs which support it. \$\endgroup\$
    – akohlsmith
    Commented Jul 30, 2018 at 14:55
  • \$\begingroup\$ I don't need inter-frame timing, as soon as as a messge is received, a response can be sent (within the timeout I specify). There is always only one device talking (to keep it simple). \$\endgroup\$ Commented Jul 30, 2018 at 14:58
  • 1
    \$\begingroup\$ Actually you do need interframe timing; this is probably the critical spec for this whole design. Basically once you signal to turn off your transmitter the driver needs to "release" the bus to let other devices talk. If you don't do this and just jam your messages one after the other then you can end up with the first bit of the message missing. If the network is long or variable-length this will also have an impact. When you're switching direction on the bus this minimum delay is also called turnaround time. \$\endgroup\$
    – akohlsmith
    Commented Jul 30, 2018 at 18:32

This totals less than 200 us together... Do I miss something?

In case the other party is a PC: USB timing. This is usually scheduled in full USB frames (for full speed), and can add up to about 1.5ms of latency. Even more latency is possible when the PC is "loaded".

In case the other party is another µC, your 200µs seem to be a usable timeout.

  • 1
    \$\begingroup\$ It's not a PC, but good to know USB has some latency too. (I used my votes today so I will upvote tomorrow). \$\endgroup\$ Commented Jul 30, 2018 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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