Interner Oszillator - I2C-Timing-DS1820

Ein DS1820 hat kein I2C !

Weder I2C noch 1-Wire sind empfindlich gegenüber den Toleranzen des 
taktgebenden Oszillators, solange die maximal zulässige Taktrate des 
Slaves nicht überschritten wird. Bei sehr ungenauer Taktversorgung legt 
man das Zeitverhalten / den I2C-Takt entsprechend langsamer aus.

Andreas Kaiser wrote:
> Weder I2C noch 1-Wire sind empfindlich gegenüber den Toleranzen des
> taktgebenden Oszillators, solange die maximal zulässige Taktrate des
> Slaves nicht überschritten wird.

Bei Onewire ist das so falsch. Das Timing ist zwar relativ entspannt 
(zulässiger Bereich etwa 2:1), aber komplett Timiningunabhängig ist das 
definitiv nicht !

Benedikt K. wrote:

> Bei Onewire ist das so falsch.

Hier geht es um Toleranzen in Grössenordnung der üblichen internen 
R/C-Oszillatoren. Als "sehr ungenau" sehe ich da 20-30%.

Andreas Kaiser wrote:
> Benedikt K. wrote:
>
>> Bei Onewire ist das so falsch.
>
> Hier geht es um Toleranzen in Grössenordnung der üblichen internen
> R/C-Oszillatoren. Als "sehr ungenau" sehe ich da 20-30%.

Wenn man das so sieht hast du recht. Es war nur etwas schwammig 
ausgedrückt, vor allem im Zusammenhang mit der maximalen Frequenz.

Gisbert wrote:
> ok..freudscher Verschreiber - ich meinte natürlich 1-Wire
>
> Sollte also gehen oder?

Es sollte gehen. Im Vergleich zu den zulässigen Toleranzen beim 
Onewirebus ist der Oszillatordrift vernachlässigbar.

> Was sagt eure Erfahrung denn so zum Platzbedarf des Codes um ein DS1820
> auszulesen..ich bin recht knapp mit Platz.

Die Software sollte ziemlich klein sein, wenn du dich auf das 
notwendigste beschränkst (also kein automatischen Anlernen der Sensoren, 
sondern feste Adresse oder Adresse ignorieren).

Gisbert wrote:

> Was sagt eure Erfahrung denn so zum Platzbedarf des Codes um ein DS1820
> auszulesen..ich bin recht knapp mit Platz.

Bei mir deutlich unter 300 Bytes bei 1 Sensor pro Leitung. In Assembler. 
War kein Rekordversuch, geht evtl. auch kleiner.

Wenn's nicht zu heiss wird, kein Problem. Bei hoher Temperatur ist das 
jedoch nicht mehr möglich (=> Datasheet). Hat den Vorteil, dass man 
"spinnende" Sensoren auch mal zeitweilig abschalten kann.

Bei Peters Code gilt zu beachten, dass die Anstiegszeit bei langem Kabel 
recht signifikant ist und in seinem Code die Zeit zwischen den Bits zu 
kurz werden kann. Und man sollte Interrupts nicht aus dem Auge lassen, 
nicht alle Stellen sind gegen Interrupts mit signifikanter Laufzeit 
abgesichert (sowas ist zwar unsauber, aber nicht selten anzutreffen).

Keine Ahnung ob du den selben Code meinst, aber bei dem Code von peter 
den ich verwende, sind nur die Bit Schreib/Leseroutinen und der 
Resetimpuls Interruptgeschützt. Und das reicht, da diese die einzigen 
Zeitabhängigen Routinen sein.
Für richtig lange Kabel: P82B96. Damit sind auch >200m kein Problem.

Dieser liefert mit weniger Aufwand eine höhere Genauigkeit.

Benedikt K. wrote:

> Keine Ahnung ob du den selben Code meinst, aber bei dem Code von peter
> den ich verwende, sind nur die Bit Schreib/Leseroutinen und der
> Resetimpuls Interruptgeschützt.

Der 480µs Resetimpuls selbst nicht, nur die 66µs Wartezeit bis zur 
Abfrage sind abgesichert. Was praktisch immer ausreichen wird - aber ich 
habe hier schon manch schlimme Interruptroutine gesehen, bei der einem 
parasitär betrieben Sensor das Licht ausgehen würde.

Das Hauptproblem betrifft parasitäre Sensoren: Nach dem Start-Kommando 
muss innerhalb von 10µs der starke Pullup eingeschaltet werden. An 
dieser Stelle ist Peters Code nicht abgesichert und 10µs sind in 
Interrupts leicht erreicht.

Das Problem mit der Anstiegszeit löst sich mit 5µs Wartezeit am Ende von 
w1_bit_io.