Hallo Forum, kann ich mit einem AVR ohne Quarz (8 Mhz int. Oszillator) eine saubere I2C Kommunikation z.B. mit einem (mehreren) DS1820 realisieren? Grüße, Gisbert
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 !
ok..freudscher Verschreiber - ich meinte natürlich 1-Wire Sollte also gehen oder? Was sagt eure Erfahrung denn so zum Platzbedarf des Codes um ein DS1820 auszulesen..ich bin recht knapp mit Platz. Grüße, Gisbert
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.
Ich habe mir mal den 1-Wire Code von Peter angesehen - dort wird die Phantomspeisung erwähnt. Ist das empfehlenswert (vor allem bei längerem Kabel)? Grüße, Gisbert
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.
Schönen dank erst mal.... Ich habe ca. 300 Bytes Platz, programmiere in C, habe nur einen Pin frei und wollte eigentlich 2 x DS1820 abfragen.... Es wird also spannend (ich werde mich da mal rantasten) Der Nachfolgetyp des DS1820 ist ja der DS18S20 - gibts da in der Praxis unterschiede? Grüße, Gisbert
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.