OpenBK7231T_App
OpenBK7231T_App copied to clipboard
DS1820 read timings are incorrect
Datasheet https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf clearly states:
Output data from the DS18B20 is valid for 15µs after the falling edge that initiated the read time slot. Therefore, the master must release the bus and then sample the bus state within 15µs from the start of the slot. Figure 17 illustrates that the sum of TINIT, TRC, and TSAMPLE must be less than 15µs for a read time slot.
The same is for DS18S20 in https://www.analog.com/media/en/technical-documentation/data-sheets/ds18s20.pdf
But code has two delays before data sampled from bus: delayA = 6us and delayE = 9us. So, requirements are not met - read occurs after 15us after slot start.
Yes, I know about https://www.analog.com/en/resources/technical-articles/1wire-communication-through-software.html . And that article is incorrect too - at least about grey line on figure 1. Slave with 2-wire connection has no way to get energy between read slots with a such timings.
Oscillograms confirm that the data is valid on the bus for no more than 30 µs (for my test sensor). 30us is gt than 15us, but such violations could produce failures.
Currently I'm trying to find the cause why my sensor stops responding after reaching 92C (the case is reproducible). And it seems timings could be an issue (unfortunately, sensor is mounted, so I could not connect scope there. Another sensor, bought recently, works perfectly in lab - just because it is seems to be from another vendor, and behaves differently).
Will update here when do "problematic sensor" tests with modified firmware.
With timings and port settings updated, read becomes more stable on high temp. No hw changes was made, only firmware upgrade:
how does this tie in with @MaxineMuster's recent work with DS1820 driver?
I included all @rpv-tomsk fixes in the "extended" driver (quote from #1627 "... Use "HAL usleep" as proposed by @rpv-tomsk with his implementation for Beken").