On 04/11/2022 15:37, pozz wrote:
> Il 04/11/2022 10:49, David Brown ha scritto:
>> On 04/11/2022 08:45, pozz wrote:
>>> Il 03/11/2022 16:26, David Brown ha scritto:
>>>> On 03/11/2022 14:00, pozz wrote:
>>>>> Il 03/11/2022 12:42, David Brown ha scritto:
>>>>>> On 03/11/2022 00:27, Rick C wrote:
>>>>>>> On Wednesday, November 2, 2022 at 4:49:16 PM UTC-4, David Brown
>>>>>>> wrote:
>>>>>>>> On 02/11/2022 20:20, Rick C wrote:
>>>>>>>>> On Wednesday, November 2, 2022 at 5:28:21 AM UTC-4, David Brown
>>>>>>>>> wrote:
>>>>>>>>>> On 02/11/2022 06:28, Rick C wrote:
>>>>>
>>>>>
>>>>>> You are correct that reception is in the middle of the stop bit
>>>>>> (typically sub-slot 9 of 16).  The first transmitter will be
>>>>>> disabled at the end of the stop bit, and the next transmitter must
>>>>>> not enable its driver until after that point - it must wait at
>>>>>> least half a bit time after reception before starting
>>>>>> transmission.  (It can wait longer without trouble, which is why
>>>>>> faster baud rates are less likely to involve any complications here.)
>>>>>
>>>>> Do you mean that RX interrupt triggers in the middle of the stop
>>>>> bit and not at the end? Interesting, but are you sure this is the
>>>>> case for every UART implemented in MCUs?
>>>>
>>>> Of course I'm not sure - there are a /lot/ of MCU manufacturers!
>>>>
>>>> UART receivers usually work in the same way, however.  They have a
>>>> sample clock running at 16 times the baud clock.  The start bit is
>>>> edge triggered to give the start of the character frame.  Then each
>>>> bit is sampled in the middle of its time slot - usually at subbit
>>>> slots 7, 8, and 9 with majority voting.  So the stop bit is
>>>> recognized by subbit slot 9 of the tenth bit (assuming 8-bit, no
>>>> parity) - the voltage on the line after that is irrelevant.  (Even
>>>> when you have two stop bits, receivers never check the second stop
>>>> bit - it affects transmit timing only.)  What purpose would there be
>>>> in waiting another 7 subbits before triggering the interrupt, DMA,
>>>> or whatever?
>>>
>>> There's no real purpose, but it's important to know exactly when the
>>> RX interrupt is fired from the UART.
>>>
>>
>> I think it is extremely rare that this is important.  I can't think of
>> a single occasion when I have thought it remotely relevant where in
>> the stop bit the interrupt comes.
>>
>>> Usually the next transmitter starts transmitting after receiving the
>>> last byte of the previous transmitter (for example, the slave starts
>>> replying to the master after receiving the complete message from it).
>>>
>>
>> No.  Usually the next transmitter starts after receiving the last
>> byte, and /then a pause/.  There will always be some handling time in
>> software, and may also include an explicit pause.  Almost always you
>> will want to do at least a minimum of checking of the incoming data
>> before deciding on the next telegram to be sent out.  But if you have
>> very fast handling in relation to the baud rate, you will want an
>> explicit pause too - protocols regularly specify a minimum pause (such
>> as 3.5 character times for Modbus RTU), and you definitely want it to
>> be at least one full character time to ensure no listener gets
>> hopelessly out of sync.
>
> In theory, if all the nodes on the bus were able to change direction in
> hardware (exactly at the end of the stop bit), you will not be forced to
> introduce any delay in the transmission.

Communication is about /reliably/ transferring data between devices.
Asynchronous serial communication is about doing that despite slight
differences in clock rates, differences in synchronisation, differences
in startup times, etc. If you don't have idle pauses, you have almost
zero chance of staying in sync across the nodes - and no chance at all
of recovery when that happens. /Every/ successful serial protocol has
pauses between frames - long enough pauses that the idle time could not
possibly be part of a normal full speed frame. That does not just apply
to UART protocols, or even just to asynchronous protocols. The pause
does not have to be as long as 3.5 characters, but you need a pause -
just as you need other error recovery handling.

>
> Many times I'm the author of a custom protocol because some nodes on a
> shared bus, so I'm not forced to follow any specifications. When I
> didn't introduce any delay in the transmission, I sometimes faced this
> issue. In my experience, the bus is heterogeneous enough to have a fast
> replying slave to a slow master.
>
>
>>> Now I think of the issue related to a transmitter that delays a
>>> little to turn around the direction of its transceiver, from TX to
>>> RX. Every transmitter on the bus should take into account this delay
>>> and avoid starting transmission too soon.
>>
>> They should, yes.  The turnaround delay should be negligible in this
>> day and age - if not, your software design is screwed or you have
>> picked the wrong hardware.  (Of course, you don't always get the
>> choice of hardware you want, and programmers are often left to find
>> ways around hardware design flaws.)
>
> Negligible doesn't mean anything.

Negligible means of no significance in comparison to the delays you have
anyway - either intentional delays in order to separate telegrams and
have a reliable communication, or unavoidable delays due to software
processing.

> If thre's a poor 8 bit PIC (previous
> transmitter) clocked at 8MHz that changes direction in TXC interrupt
> while other interrupts are active, and there's a Cortex-M4 clocked at
> 200MHz (next transmitter), you will encounter this issue.
>

No, you won't - not unless you are doing something silly in your timing
such as failing to use appropriate pauses or thinking that 10 µs
turnarounds are a good idea at 9600 baud. And I did specify picking
sensible hardware - 8-bit PICs were are terrible choice 20 years ago for
anything involving high speed, and they have not improved. (Again -
sometimes you don't have control of the hardware, and sometimes there
can be other overriding reasons for picking something. But if your
hardware is limited, you have to take that into account.)

> This is more evident if, as you are saying, the Cortex-M4 is able to
> start processing the message from the PIC at the midpoint of last stop
> bit, while the PIC disables its driver at the *end* of the stop bit plus
> an additional delay caused by interrupts handling.
>
> In this cases the half bit time is not negligible and must be added to
> the transmission delay.
>

Sorry, but I cannot see any situation where that would happen in a
well-designed communication system.

Oh, and it is actually essential that the receiver considers the
character finished half-way through the stop bit, and not at the end.
UART communication is intended to work despite small differences in the
baud rate - up to nearly 5% total error. By the time the receiver is
half way through the received stop bit, and has identified it is valid,
the sender could be finished the stop bit as its clock is almost 5%
faster (50% bit time over the full 10 bits). The receiver has to be in
the "watch for falling edge of start bit" state at this point, ready for
the transmitter to start its next frame.

>
>
>>> So I usually implement a short delay before starting a new message
>>> transmission. If the maximum expected delay of moving the direction
>>> from TX to RX is 10us, I could think to use a 10us delay, but this is
>>> wrong in your assumption.
>>>
>>
>> Implementing an explicit delay (or being confident that your telegram
>> handling code takes long enough) is a good idea.
>>
>>> If the RX interrupt is at the middle of the stop bit, I should delay
>>> the new transmission of 10us + half of bit time. With 9600 this is
>>> 52us that is much higher than 10us.
>>
>> I made no such assumptions about timings.  The figures I gave were for
>> using a USB 2 based interface on a PC, where the USB polling timer is
>> at 8 kHz, or 125 µs.  That is half a bit time for 4 Kbaud.  (I had
>> doubled the frequency instead of halving it and said the baud had to
>> be above 16 kBaud - that shows it's good to do your own calculations
>> and not trust others blindly!).  At 1 MBaud (the suggested rate), the
>> absolute fastest the PC could turn around the bus would be 12
>> character times - half a stop bit is irrelevant.
>>
>> If you have a 9600 baud RS-485 receiver and you have a delay of 10 µs
>> between reception of the last bit and the start of transmission of the
>> next message, your code is wrong - by nearly two orders of magnitude.
>> It is that simple.
>
> Not always. If you have only MCUs that are able to control direction in
> hardware, you don't need any delay before transmission.
>
>
>> If we take Modbus RTU as an example, you should be waiting 3.5 * 10 /
>> 9600 seconds at a minimum - 3.65 /milli/seconds.  If you are concerned
>> about exactly where the receive interrupt comes in the last stop bit,
>> add another half bit time and you get 3.7 ms.  The half bit time is
>> negligible.
>
> Oh yes, if you have already implemented a pause of 3.5 char times, it is
> ok.
>

Yes, exactly.

>
>>> I know the next transmitter should make some processing of the
>>> previous received message, prepare and buffer the new message to
>>> transmit, so the delay is somewhat automatic, but in many cases I
>>> have small 8-bits PICs and full-futured Linux box on the same bus and
>>> the Linux could be very fast to start the new transmission.
>>
>> So put in a delay.  An /appropriate/ delay.
>>
>>>
>>>>> I wouldn't be surprised if the implementation was different for
>>>>> different manufacturers.
>>>>>
>>>>
>>>> I've seen a bit of variation, including 8 subbit clocks per baud
>>>> clock, wider sampling ranges, re-sync of the clock on edges, etc.
>>>> And of course you don't always get the details of the timings in
>>>> datasheets (and who bothers measuring them?)  But the key principles
>>>> are the same.
>>>>
>>>>>
>>>>>>> None of this matters to me really.  I'm going to use more wires,
>>>>>>> and do the multi-drop from the PC to the slaves on one pair and
>>>>>>> use RS-422 to multi-point from the slaves to the PC.  Since the
>>>>>>> slaves are controlled by the master, they will never collide.
>>>>>>> The master can't collide with itself, so I can ignore any issues
>>>>>>> with this.  I will use the bias resistors to assure a valid idle
>>>>>>> state.  I may need to select different devices than the ones I
>>>>>>> use in the product.  I think there are differences in the input
>>>>>>> load and I want to be sure I can chain up to 32 units.
>>>>>>>
>>>>>>
>>>>>> OK.  I have no idea what such a hybrid bus should technically be
>>>>>> called, but I think it should work absolutely fine for the purpose
>>>>>> and seems like a solid solution.  I would not foresee any issues
>>>>>> with 32 nodes on such a bus, especially if it is relatively short
>>>>>> and you have terminators at each end.
>>>>>
>>>>> In my experience, termination resistors at each end of the line
>>>>> could introduce other troubles if they aren't strictly required
>>>>> (because of signal integrity on long lines at high baud rates).
>>>>>
>>>>
>>>> RS-485 requires them - you want to hold the bus at a stable idle
>>>> state when nothing is driving it.
>>>
>>> But this is the goal of *bias* resistors, not termination resistors.
>>>
>>
>> Yes - but see below.  Bias resistors are part of the termination - it
>> just means that you have terminating resistors to 5V and 0V as well as
>> across the balanced pair.
>>
>>>
>>>> You also want to have a bit of load so that you have some current on
>>>> the bus, and thereby greater noise immunity.
>>>
>>> Of course, but termination resistors are usually small (around 100
>>> ohms) because they should match the impedance of the cable. If you
>>> want only to introduce "some current" on the bus, you could use
>>> resistors in the order of 1k, but this isn't strictly a *termination*
>>> resistor.
>>>
>>
>> If you have a cable that is long enough (or speeds fast enough) that
>> it needs to be treated as a transmission line with controlled
>> impedance, then you do need impedance matched terminators to avoid
>> reflections causing trouble.  Usually you don't.
>>
>> A "terminating resistor" is just a "resistor at the terminator" - it
>> does not imply impedance matching, or any other specific purpose.  You
>> pick a value (and network) appropriate for the task in hand - maybe
>> you impedance matching, maybe you'd rather have larger values to
>> reduce power consumption.
>>
>>>
>>>>> The receiver input impedance of all the nodes on the bus are in
>>>>> parallel with the two terminators. If you have many nodes, the
>>>>> equivalent impedance on the bus is much small and the partition
>>>>> with bias resistors could reduce the differential voltage between A
>>>>> and B at idle to less than 200mV.
>>>>>
>>>>> If you don't use true fail-safe transceivers, a fault start bit
>>>>> could be seen by these kind of receivers.
>>>>>
>>>>
>>>> Receiver load is very small on modern RS-485 drivers.
>>>
>>> ST3485 says the input load of the receiver around 24k. When you
>>> connect 32 slaves, the equivalent resistor would be 750 ohms, that
>>> should be enough to have "some current" on the bus. If you add
>>> *termination* resistors in the order of 100R on both sides, you could
>>> reduce drastically the differential voltage between A and B at idle
>>> state.
>>>
>>
>> If you are pushing the limits of a bus, in terms of load, distance,
>> speed, cable characteristics, etc., then you need to do such
>> calculations carefully and be precise in your specification of
>> components, cables, topology, connectors, etc.  For many buses in
>> practice, they will work fine using whatever resistor you pull out
>> your box of random parts.  For a testbench, you are going to go for
>> something between these extremes.
>
> Ok, I thought you were suggesting to add impedance matching (slow)
> resistors as terminators in any case.