Forum: Mikrocontroller und Digitale Elektronik 1-Wire und DS1820 Testprog


von Bastian (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich habe ein kleines Programm geschrieben, um den 1-Wire Bus zu resetten 
und auf Slaves zu prüfen.

Was haltet ihr davon, und ist das so sinnvoll??



Gruß

Bastian

von Bastian (Gast)


Angehängte Dateien:

Lesenswert?

hier nochmal der Quellcode, falls der Link nicht funktioniert

von Peter D. (peda)


Lesenswert?

Der 1-Wire-Bus ist bidirektional mittels open-drain  Ausgängen, d.h. Du 
darfst niemals den Pin auf high setzen.


Ich würde immer mit Symbolen arbeiten (für Portpins usw.)
Sowas wie:

sbr temp,64

ist viel schwerer zu verstehen als:

sbr temp, 1<<pin_1wire


Die Delays würde ich den Assembler selber aus der Quarzfrequenz 
ausrechnen lassen.



Hier ist mein 1-Wire Beispiel:

http://www.mikrocontroller.net/forum/read-4-32158.html


Peter

von Bastian (Gast)


Lesenswert?

Hallo,

ich darf den pin nie auf high setzen? du meinst, ich setze immer nur 
low, die high kommen vom pullup?

Die Symbole muss ich mir nochmal angucken.

Bei den Delay meinst Du:

ldi  a1, 480 * xtal  1000000  7  ?

allerdings läuft mein µc auf 10 mhz, passt ja nich mehr ins register. 
woher kommen die / 7 eigentlich



Danke

Gruß
Bastian

von Peter D. (peda)


Lesenswert?

"...die high kommen vom pullup?"

sobald das Direction-Bit 0 ist.


Die "/ 7" ist die Anzahl der Zyklen in der Schleife.

Bei 10MHz mußt Du noch mehr Zeit in der Schleife verbraten.

z.B. ein "LPM" verbraucht 3 Zyklen, ein RCALL zu einem RET verbraucht 7 
Zyklen.



Peter

von Bastian (Gast)


Angehängte Dateien:

Lesenswert?

Danke für deine Hinweise.


Ich hab versucht den für den DS1820 Bit und Byte read/write Routinen zu 
erstellen. Leider funktioniert da, bis auf das initialisieren des 
DS1820, gar nichts :-(

Vielleicht hat ja irgendwer lust, meinen Grauenvollen Quelltext 
anzugucken



Gruß
Bastian

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

Ich hätte hier noch meine Routine auf 11MHz aufgebohrt.

Ich hoffe Du verzeihst mir, da ich ja schon einen funktionieren Code 
habe, daß ich da nicht so große Lust habe durch einen anderen 
durchzusteigen.

Es ist ja immer etwas schwerer durch einen fremden Quelltext 
durchzusteigen, d.h den Gedankengang des anderen nachzuvollziehen.



Peter

von Bastian (Gast)


Lesenswert?

Danke Peter, du bist immer eine große Hilfe. Ich werde jetzt mal deinen 
Quelltext nehmen und ihn für mich anpassen.

Allerdings kann ich mir noch nicht richtig die Kommunikation mit dem 
DS1820 vorstellen. Muss ich einfach 2 bytes (44h) senden und dann liest 
er die temperatur ein?

von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

@Bastian,

nein

Auf Seite 21 des Datenblatts (siehe Anhang) ist eine Tabelle mit dem 
richtigen Ablauf.


Peter

von Bastian (Gast)


Lesenswert?

ich hab noch eine Frage zu deinem Code:


sbis  w1_in, w1_pin    ;check short circuit
clc
reti


Soll bedeuten: nur wenn der Bus durch den ds1820 auf null gezogen wird, 
dann wird (durch clc) das carry flag gelöscht?

wie kann ich denn dann das carry flag auswerten? einfach später mit 
brcc?
ausserdem hab ich das problem, dass das carry flag bei mir auch vorm clc 
schon null ist.

von Peter D. (peda)


Lesenswert?

Stimmt, das C flag wird zuerst gelöscht, dann bei der Presence-Erkennung 
gesetzt und nach den 690µs bei ständigem Kurzschluß wieder gelöscht.

Der Presence-Impuls muß also nach den ersten 480µs kommen aber auch 
wieder gehen.


Peter

von Bastian (Gast)


Lesenswert?

bei welchem befehl wird denn das c flag gesetzt? wenn ich es im 
simulator laufen lasse, dann wird es nie gesetzt..


Bastian

von Peter D. (peda)


Lesenswert?

Zeile 28:

cpi     a1, 465 * xtal  1000000  21   ;1      after 15us


Du must natürlich im Simulator zu richtigen Zeit den Pin auf Low setzen, 
d.h. einen Presence-Impuls simulieren.


Peter

von Bastian (Gast)


Lesenswert?

ich glaub ich verstehe grundlegende funkionen nicht.

soll, wenn mit reti aus der routine w1_reset zurückgesprungen wird am c 
flag erkannt werden können, ob ein gerät am bus hängt (c flag 1 = gerät 
dran, c flag 0 = kein gerät)?

warum eigentlich auch reti und nicht ret? auch das cli verstehe ich nich 
ganz.



Bastian

von Peter D. (peda)


Lesenswert?

"(c flag 1 = gerät dran, c flag 0 = kein gerät)?"

Genau.


Ich gehe davon aus, daß der AVR ja noch ne Menge anderes zu tun hat, 
also z.B. auch irgendwelche Interrupts.

Damit nicht nun ein Interrupt dazwischenhaut und ich dadurch den 
Presence-Impuls verpasse, deshalb das CLI-RETI.

RETI = SEI+RET, spart also nur einen Befehle ein.


Peter

von Bastian (Gast)


Lesenswert?

Achso ist das gemeint.

Irgendwas funktioniert bei deinem Code nich, oder wahrscheinlich hab ich 
ihn falsch eingefügt.


Bei meinem reset code konnte man schön auf dem Oszi sehen, wie der 
DS1820 nach dem 480µs low vom µc mit seinem low antwortet.

Bei deinem code antwortet er nicht.
Langsam verzweifele ich :-(

von Bastian (Gast)


Lesenswert?

Hallo nochmal,

ich habe grade mit dem Oszi festgestellt, dass bei deinem 'Generate 
1-Wire Reset'
vom µC der low impuls nur ca. 50µs lang ist

woran kann das liegen?

ich hab ein 10MHz Quarz und

.equ xtal     = 10000000

eingestellt..

von Peter D. (peda)


Lesenswert?

Das liegt an:

 ldi     a1, 480 * xtal  1000000  21


Der Assembler kann nur bis 32Bit rechnen, d.h. 480*10000000 ergibt einen 
Überlauf und das Ergebnis stimmt nicht mehr.


So solte es wieder gehen:

 ldi     a1, 48 * xtal  100000  21


Peter

von Bastian (Gast)


Lesenswert?

Danke für deine Hilfe.

Jetzt läuft es endlich :-)
Ich hab auch eine Temperatur routinen übernommen und meine LCD dazu.

Jetzt muss ich nur noch rausfinden, wie ich mehrere DS1820 an einem Bus 
betreiben kann, bzw. wie ich die Serialnummer von ihnen rausfinden 
kann..

von Bastian (Gast)


Lesenswert?

Hallo Peter,

hast du zufällig noch Routinen, um die Serialnummer der DS1820 
auszulesen und mehrere an einem 1-Wire zu betreiben?

Ich habs selbst versucht, aber kriegs einfach nich hin..

von Peter D. (peda)


Lesenswert?

Das ist doch die "w1_rom_search"

Dazu must "romcode_ptr" eine RAM-Adresse mit 8 Bytes sein, worin dann 
der ROM-Code abgelegt wird, bzw. zum finden des nächsten Devices 
benötigt wird.

Hast Du mehr als 128 Byte RAM, dann must Du die Routine auf 16-Bit 
Z-Pointer erweitern.


Peter

von Bastian (Gast)


Lesenswert?

Hallo Peter,

ich krieg das einfach nich hin mit dem romcode.

Bei meinem 2313 ist der Z-Pointer doch 16-bit, oder? was muss ich denn
da ändern?

wie wird denn im romcode_ptr der 8 byte code abgelegt, bzw. darauf
verwiesen?

ich hatte den rom code per hand ausgelesen und versucht mit .db den rom
code bei 55h zu senden, aber das hat überhaupt nicht funktioniert


gruß

Bastian

von Peter D. (peda)


Lesenswert?

Was geht denn alles schon ?

Die Temperaturanzeige stimmt ?

Hängt Deinen Code mal hier rein und schreib, an welchen Zeilennummern
Du Probleme hast oder vermutest.

Der 2313 hat nur 128 Byte RAM, d.h. der Wert von ZH ist bei
LD/ST-Befehlen egal.



Peter

von Bastian (Gast)


Angehängte Dateien:

Lesenswert?

Die Temperatur wird 3-stellig und mit Kommastelle richtig ausgegeben.
Allerdings nur bei einem DS1820 am Bus, als ohne ROM Abfrage.

Direkt einen anzusprechen kriege ich nich hin. Wie der ROM Code genau
gesendet werden muss verstehe ich nich, im Datenblatt steht leider nich
so viel drin.

Einen wirklich vernünfigen Code, um mehrere DS1820 anzusprechen hab ich
gar nich. Die erfolglosen Versuche hab ich gleich wieder gelöscht.
Zumindest den funkioniernden Ansatz kann ich mal posten.


Gruß
Bastian

von Bastian (Gast)


Lesenswert?

Wo wird in deinem Code der ROM Code gespeichert?
So wie ich das verstehe wird er jedesmal erst ausgelesen. Wäre es nicht
einfacher ihn einmal für alle DS1820 auszulesen und die ROM Codes in
einer Tabelle zu speichern. Zum ansprechen der enizelnen DS1820 dann
auf den jeweiligen ROM Code in der Tabelle zuzugreifen?



Bastian

von Peter D. (peda)


Lesenswert?

"Wo wird in deinem Code der ROM Code gespeichert?"


Garnicht !

Das ist ja das Geniale an der ROM-Search-Methode, daß man die Adressen
nicht kennen muß.

Jeder ROM-Search Aufruf liefert zwar die Adresse, aber danach ist ja
dieser 1-Wire auch schon adressiert, d.h. man muß nur noch die
Temperatur auslesen.

Anhand der Nummer des Bits (in Register a0), welches als nächstes
aufzulösen ist und der Adresse (in den 8 Bytes ab romcode_ptr) des
vorherigen 1-Wire wird beim nächsten ROM-Search Aufruf der nächste
1-Wire adressiert usw.

Den romcode_ptr habe ich auf Register 1 gesetzt, da der TINY12 ja sonst
keinen RAM hat.

Beim 2313 kannst Du ihn aber bequem in den RAM setzen:

.dseg
.org 0x60
romcode_ptr: .byte 8
.cseg


Die ROM-Search Methode adressiert also alle 1-Wire der Reihe nach.

Nachteil:
Fällt ein Sensor aus, rücken alle dahinter automatisch auf, d.h. dann
stimmt die Zuordnung zu den Meßstellen nicht mehr.


Aber jeder Sensor hat ja 2 Byte EEPROM, darin kann man jedem eine
Meßstellennumer zuweisen.

Geht dann mal ein Sensor kaputt, muß man nicht einen neuen ROM-Code in
den MC programmieren sondern trägt dann in den Ersatzsensor einfach die
richtige Meßstellennummer ein.



Hier ist noch ein Beispiel, was die Adressen aller angeschlossenen
1-Wire anzeigt:

http://www.mikrocontroller.net/forum/read-4-27035.html


Peter

Bitte 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
Noch kein Account? Hier anmelden.