Hello Tony,I make different assumptions for bussing signals and testing choices.
Type of Diode drop at If, Schottky vs Si.
Cable capacitance by choice impedance : Worst case 100 Ohm STP
Cable length = 1m
Source impedance using Zol worst case.
Pull up Resistor.
Vol margin testing.
I did not focus on overshoot of Vol which can be eliminated by adding Rs from a 17 ohm source closer to transmission line impedance without matching at having 50% drop.
https://tinyurl.com/yh4ocpyn Falstad Simulation.
Here you will see a silicon diode with a highest Vol max margin at lower pullup current at the expense of slower rise time.
The take away conclusion is 1K may be more optimal balancing rise time duty cycle and Vol margin using be better using a schottky diode considering the Cd ESR tradeoffs of all diodes that affect Vf @ If and recovery time.
I chose a 1MHz clock.
View attachment 172926
I simulated the Vil = 1V worst case min threshold using 2V ideal logic receiver.
-ESP32: with VDD=3.3V
VIL: -0.3 - 0.25VDD
VOL: 0.1VDD and IOL=28mA (typical) with VOL=0.495V
Thus Zol= Vol/Iol= 17 Ω typ. with Vil= 1V min
-RP2040: with VDD=3.3V
VIL -0.3 0.8VDD V
VOL max 0.5V at IOL=2, 4, 8, 12mA depending on settings
Thus Zol= 250Ω, to 41.7 Ω max with Vil= 1V min
-STM32H7: with VDD=1.62V-3.6V
VIL: 0.3VDD V
VOL: max:1.3V at IOL=20mA
I don't know if it helps: The GPIOs can sink or source up to ±8 mA, and sink or source up to ±20 mA (with a relaxed VOL/VOH).
Thus Zol= 65 Ω max with Vil = 1V min
I did some tests and finally I succeed in getting open drain for TX pin (and also for RX pin) by software.The firmware must be able to handle half duplex anyway, specifically only send when the bus is idle.
Regarding baud rate, it must be achievable for all involved nodes. I'd probably go for a standard baud rate like 921k. At this rate, a low ohmic diode/resistor circuit should still work, e.g. 470 to 1k.
I believe, I already answered the question. Disabling inputs however doesn't serve a purpose.By the way, it is also possible to disable input and output and put the pin into a Hi-Z state. I don't know if it is better than open drain?
According to the datasheets of MCUs, the UART can go much more higher than 921k.In the first order 921k is a practical limit, e.g. the highest standard UART rate supported by modern PCs and USB converters. I don't know what's available as common rate with the nodes of your design.
Secondly, there's a limit for open drain busses depending on the range and total load capacitance. You should analyze it for your application parameters.
--- Updated ---
I believe, I already answered the question. Disabling inputs however doesn't serve a purpose.
Having multiple tri-state drivers on a bus (similar to RS-485, as already mentioned) involves a risk of inadvertently enabling multiple drivers at the same time. In constrast to open drain, where it only causes data loss, it may also damage drivers.
thank you Klaus,Hi,
to optimize LOW voltage level you could use a 74LVC1G125 as open_drain driver.
(TI datasheet)
A = GND
/OE = Tx
Y = databus
* They work from 1.7V to 5.5V,
* drive 24mA
* have low V_OL
* are fast (3.7ns)
* can tolerate up to 6.5V on any IO, even if not powered
* have high impedance output when not powered
Klaus
I agree that every microcontroller can work higher than 921k Baud.According to the datasheets of MCUs, the UART can go much more higher than 921k.
Thank you Klaus,Hi,
it is an alternative for the diode.
and it is multidrop, means it still needs an R.
(no damage will occur when multiple nodes are active at the same time)
***
You may use the same IC as single ended push-pull driver.
Then you need function similar to RS485:
* extra microcontroller pin for driver_enable
* and the risk of problems/damage when two (or more) drivers are enabled at the same time, and thus causing high short circuit current.
I agree that every microcontroller can work higher than 921k Baud.
Just to be sur you understand the Baud rate problem correctly:
The key point is that all need to be able to work with the same frequency (wihtin tolerance). And it depends on the individual UART_clock_generators and the system clock which Baud rates are available.
Means: even if every single one may operate up to 10MBaud ... there is a good chance that the "common" frequency is below 1MHz.
Klaus
As already answered several times: it depends on baud rate and trace capacitance. We can not know this.Value of R? 1K (as suggested by Tony) or 4.75K
For push pull driver / totem pole driver you need to-why extra pin for driver_enable? you mean I have to use two pins on the MCU: RX and TX? extra pins to use at the MCU level?
Two options .. divided by a space line and "***"-You said "no damage will occur..." and after "risk of problems/damage..." I don't catch the difference. If you can please explain? thx
Tristate respectively output enable for UART TX is available for most uC, probably except for those with fixed dedicated UART pin.Concerning tri-state pin VS disable pin: I did some tests and for the moment only disabling inputs works, maybe I missed something in the code.
Hello FvM,Some uC provide also configurable open drain option for TX pin.
In my mind, RX is disabled only for the sender to avoid self receiving its own data. maybe it is not required?I'd use a different configuration. RX pins always enabled. TX pins switched between push-pull output and tristate/disabled output.
your "sleep mode" means: supply voltage is shut down?=> yes, one node can be in sleep mode. something to avoid?
HiHi,
your "sleep mode" means: supply voltage is shut down?
If supply is shut down you need an additional circuit at the Rx side, to prevent the Rx_pin protection diodes to pull down the data line.
Klaus
Something like an 74LVCxx gate that can accept input voltge even when supply is shut down.If needed, what kind of circuit would I have to add at the RX side?
The ´125 is an open drain driver ... in case the microcontroller has not.Do you have a response concerning the other question? : -"all other MCUs have TX pin as Open Drain-tristate/disabled ouput (disable the driver)" => finally it is really necessary to do it (thanks to the ´125 driver)?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?