For clarity, can I confirm the points where the UART measures the timed difference between received bytes. Is it between the end of the stop bit of the preceding byte and the beginning of the start bit of the next? Or is it between start bits? I couldn’t find anything in the docs that confirmed it.
From what I can see (@peter can confirm this), it’s between RXNE interrupt handler invocations, which essentially means between stop bits - ie it’s not the line idle time, you’d have to subtract that yourself, but it’s a known quantity.
That’s right, it’s the interval between the instant a byte is received, and the instant the next byte is received. So it’s between the stop bits of valid frames – invalid frames, glitches etc. don’t count.
Peter
This addition of this and UART.settxactive() is a major step forward. Still a couple of questions:
- i understand a frame can as such only get detected when there is effectively a next frame arriving (ie by compaing the measured inter-frame time to what you would minimally see as a required gap length). So,with very infrequent frames on the bus (I have such an application), parsing of the last frame received can potentially be delayed significantly. Correct ?
- any particular reason why the Modbus libraries do not make use of this capability ?(at least,I didn’t find it inthe code).
No, parsing isn’t affected - no bytes are delayed. If you want to look for a gap bigger than a certain amount before you parse the already-received data, then use an imp.wakeup timer.
The MODBUS libs were written before these features shipped. Yes, they should be updated at some point.
not sure I understand. You only know how much the gap was when receiving the first byte of the next frame. As such, I would assume parsing can only start when such next frame is arriving. If that is ‘long’ after the just received frame, parsing would also be delayed equally long. At least that’s what Iunderstand out of the docs…
No, because you can set a timeout timer (when the last byte - of the last packet - was received) and process the packet there as you know that the delay between packets was at least the timeout time.
This timeout timer can be very short. The inter-packet delay of MODBUS is pretty short, for example. Here, TIMING_ENABLED is more about separating fast-arriving packets on the wire without needing to run code in this gap.
you can read my mind. This is exactly what I just did with a combination of imp.wakeup and imp.cancelwakeup.
Works well. Fast arriving packets are processed with minimal delay and the wakeup timer is processing them after a max period of silence (25msecs in my case)
I’ve used imps as MODBUS masters and slaves extensively. If you are operating only as a master, you don’t need the TIMING_ENABLED feature, but it is useful for slave mode, particularly if your imp is busy juggling another responsibilities as well.