On 04/11/2022 16:40, Rick C wrote:
> On Friday, November 4, 2022 at 5:49:42 AM UTC-4, David Brown wrote:
>> 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.
>>> 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.)
>>>
>>> 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.
>
> You are making an assumption of implementation. There is a processor in the USB cable that is implementing the UART. The driver enable control is most likely is implemented there. It would be pointless and very subject to failure, to require the main CPU to handle this timing. There's no reason to expect the driver disable to take more than a fraction of a bit time, so the "UART" needs a timing signal to indicate when the stop bit has been completed.
>

I'm making the assumption that you are using appropriate hardware. No
processor, just a USB device that has a "transmitter enable" signal on
its UART.

I'm getting the impression that you have never heard of such a UART
(either in a USB-to-UART device, or as a UART peripheral elsewhere), and
assume software has to be involved in enabling and disabling the
transmitter. Please believe me when I say such UARTs /do/ exist - and
the FTDI examples I keep giving are a case in point.

> The timing issue is not about loading another character into the transmit FIFO. It's about controlling the driver enable.
>

Yes, and it is a /solved/ issue if you pick the right hardware.

>
>> 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.
>>
>> 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.
>
> Your numbers are only relevant to Modbus. The only requirement is that no two drivers are on the bus at the same time, which requires zero delay from the end of the previous stop bit and the beginning of the next start bit. This is why the timing indication from the UART needs to be the end of the stop bit, not the middle.
>

A single transmitter, while sending a multi-character message, does not
need any delay between sending the full stop bit and starting the next
start bit. That is obvious. And that is why a "transmission complete"
signal comes at the end of the start bit sent on the transmitter side.
On the receiver side, the "byte received" signal comes in the /middle/
of the stop bit, as seen by the receiver, because that could be at the
/end/ of the stop bit as seen by the transmitter due to clock
differences. (It could also be at the /start/ of the stop bit as seen
by the transmitter.) The receiver has to prepare for the next incoming
start bit as soon as it identifies the stop bit.

But you want an extra delay of at least 11 bits (a character frame plus
a buffer for clock speed differences) between messages - whether they
are from the same transmitter or a different transmitter - to allow
resynchronisation if something has gone wrong.

I've explained in other posts why inter-message pauses are needed for
reliable UART communication protocols. They don't /need/ to be as long
as 35 bit times as Modbus specifies - 11 bit times is the minimum. If
you don't understand this by now, then we should drop this point.

>
>>> 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.
>
> You are thinking software, like most people do.

It doesn't matter whether things are software, hardware, or something in
between.

> The slaves will be in logic, so the UART will have timing information relevant to the end of bits. I don't care how the master does it. The FTDI cable is alleged to "just work". Nonetheless, I will be providing for separate send and receive buses (or call it master/slave buses). Only one slave will be addressed at a time, so no collisions there, and the master can't collide with itself.
>

Yes, with the bus you have described, and the command/response protocol
you have described, there should be no problems with multiple
transmitters on the bus, and you have plenty of inter-message idle periods.

However, this Usenet thread has been mixing posts from different people,
and discussions of different kinds of buses and protocols - not just the
solution you picked (which, as I have said before, should work fine). I
think this mixing means that people are sometimes talking at cross-purposes.

>> 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.
>
> How long is a piece of string? By keeping the interconnecting cables short, 4" or so, and a 5 foot cable from the PC, I don't expect problems with reflections. But it is prudent to allow for them anyway. The FTDI RS-422 cable seems to have a terminator on the receiver, but not the driver and no provision to add a terminator to the driver.
>

There is no point in having a terminator at a driver (unless you are
talking about very high speed signals with serial resistors for slope
control). You will want to add a terminator at the far end of both
buses. This will give you a single terminator on the PC-to-slave bus,
which is fine as it is fixed direction, and two terminators on the
slave-to-PC bus, which is appropriate as it has no fixed direction.

(I agree that your piece of string is of a size that should work fine
without reflections being a concern.)

> Oddly enough, the RS-485 cable has a terminator that can be connected by the user, but that would be running through the cable separately from the transceiver signals, so essentially stubbed! I guess at 1 Mbps, 5 feet is less than the rise time, so not an issue. Since the interconnections between cards will be about five feet as well, it's unlikely to be an issue. The entire network will look like a lumped load, with the propagation time on the order of the rise/fall time. Even adding in a second chassis, makes the round trip twice the typical rise/fall time and unlikely to create any issues.
>
> They sell cables that have 5 m of cable, with a round trip of 30 ns or so. I think that would still not be significant in this application. The driver rise/fall times are 15 ns typ, 25 ns max.
>

The speed of a signal in a copper cable is typically about 70% of the
speed of light, giving a minimum round-trip time closer to 45 ns than 30
ns. Not that it makes any difference here.