Ich habe auch mal so einen 1-Wire Temperatursensor ausgelesen (hiess
glaube ich ds1820 ??) Wie auch immer. Das funktioniert ganz gut, aber
ich habe es auch erst mit Speicheroszilloskop hinbekommen, man muß das
Timing sehr genau beachten, sonst verliert der Sensor seinen Strom und
wird resettet.
Michi, habe auch extra "Holzhammer-Methode" geschrieben, weil's
anders nie funktioniert hat. So wollte ich halt jedes Signal einzeln
ausgeben, und beobachten. Nicht mehr durchsteigen? also bitte, so
erkennt man jedes einzelne clocken und ausgeben schritt für schritt.
Ist ja wohl einfacher zu blicken als Sub-Routinen!
Das mit dem Timing hab ich auch schon unter Verdacht, allerdings will
ich erstmal ausschließen, dass es nicht ein dummer Fehler in der
Initialisierung ist.
hüüülfee :-(
Leute ich bekomme den Müll einfach nicht hin!
Habe mir jetzt die C-Quellcodes aus älteren Beiträgen genommen,
angepasst, aber das Ding will einfach nicht! Ich habe keine Ahnung wo
der Fehler liegt.... :-(
Jetzt sagt aber bitte nicht: 30cm vom Bildschirm entfernt sitzt der
Fehler ! :-))
Habe jetzt mal das neue Programm hochgeladen im Anhang, bitte schaut es
euch mal an. Vielleicht ist da ja einen RIESEN DENKFEHLER, der ganz
einfach zu erkennen ist !!
ich brauch hilfeeeeeee
Hi,
hast Du mal in das Beispiel von www.mikrocontroller.com geschaut ??
Da gibt es beispiel Code für das AVRCtrl Board mit DS1820. Hat bei mir
auf anhieb hingehauen.
Hi,
So wie ich das aus deinem 2. Quelltext erkennen konnte, Startest und
die Temperatur umwandlung (Start Conversion), dann liest du die
Temperatur und dann stoppst du die umwandlung (Stop conversion) wieder.
Ist das richtig? Im Datenblatt steht: Umwandlung starten, dann stoppen,
dann auslesen! Noch besser wäre es wenn man auf das "DONE" Bit im
Configbyte wartet bevor man ausliest.
Noch was zu deiner "Holzhammer-Methode". Es mag ja ganz einfach
geschrieben sein, aber ein aussenstehender hat wenig lust sich ne
vieltel Stunde mit deinem Quelltext zu beschäftigen, nur damit er
rausfindet welche Bytes du wofür in den Chip reinschiebst. Dazu kommt
noch das niemand weiß was du an P1.0,P1.1... angeschlossen hast! Es
muss auf einen Blick erkannbar sein, was du in jenen Augenblick in den
Chip eingibst bzw ausliest. Dein 2. Quelltest war schon
übersichtlicher! Modulweise programmieren, in unterprogrammen so wie du
es im 2. Quelltext gemachthast, ist immernoch am übersichtlichsten!
mfg
michi
Hi Rick,
habe selbst noch nicht mit dem DS1620 gearbeitet, nur gerade mal ins
Datenblatt geschaut.
1. Wie schnell läuft Dein µC? Was für einen nimmst Du überhaupt?
Irgendwas 8051-kompatibles, das ist klar. Nun, die sind ja eh recht
langsam und sollten den DS1620 nicht überfordern. Aber trotzdem:
fCLKmax ist 1,75 MHz und die Setupzeiten sollten eingehalten werden.
2. In Deinen ASM-PRGs sind ein paar Bugs drin:
Im ersten:
Die Daten werden vom 1620 mit steigender CLK-Flanke übernommen, nach
deinem Programm müßte es erher die fallende sein. Dadurch verschieb
sich das Datenwort was Du sendest um ein Bit. Der DS1620 empfängt also
0110000x. Damit kann er natürlich nix anfangen.
Im zweiten:
Ich habe mir nur die Routine put1620byte angesehen: hier fehlt das
Rücksetzen der CLK. Hast Du kein Oszi? Damit hätte das eigentlich
auffallen müssen. Außerdem geht es vom LSB zum MSB. Du fängst zwar mit
dem LSB an (and #1) dann folgt aber direkt das MSB (rl acc). Du mußt
aber rechtsrum rotieren. Mit mov-bit Befehlen geht es kürzer und
eleganter:
put1620byte: setb p1.0 ; CLK High
setb p1.1 ; RST = HIGH
mov b, #8 ; Schleifenzähler in b
mov a, ds1620byte
wordlength: clr p1.0 ; CLK low
rrc a ; auszugebenes Bit ins Carry
mov p1.2,c ; Carry an dq
setb p1.0 ; CLK high
djnz b,wordlength
go_back: ret
Wichtig ist noch, daß der DS1620 zur initialisierung eine positive
RST-Flanke bekommt, während CLK=High. Ist RST auf low, bevor
put1620byte aufgrufen wird, ist das gegeben. Also am besten am Anfang
vom HP ein mov p1,#0
Hoffe das hilft,
viel Spaß beim proggen,
Markus_8051
habe soweit jetzt alle fehler beseitigt. Da waren auch noch paar mehr
drinne, die konnte ich dann mit dem Oszi sehen.
Habe aber jetzt noch folgendes Problem:
Initialisierung scheint zu gehen, das Oszgi zeigt mir schonmal das
richtige Bild an.
Das senden vom "Start Convert" und "Stop Convert" scheint auch zu
gehen.
Dann kommt der Befehl 0xAAh, der dem DS1620 auch eingeclockt wird und
laut Oszi läuft das auch. Und genau ab diesem Punkt, spielen Clock und
DQ verrückt. Reset bleibt weiterin oben (so sollte es auch sein), aber
es finden keine 8 Clock zyklen statt bis Reset wieder low wird!
Bekomme vom Sensor "1 1000 0000" zurück in meine "temperatur"
Variable. Also das Vorzeichenbit und MSB kommt, aber ist nur Müll.
Der Fehler muss irgendwo in der "get1620byte" Funktion liegen. Bitte
helft mir mal das Teil zum laufen zu kriegen! Ich kotz gleich ab!!!!
:-(
Im Anhang sind nochmal die Funktionen.
Hi Rick,
Deine Vermutung war richtig, der Fehler liegt in der
get1620byte-Prozedur: Schau mal ins Datenblatt, da ist das
Read-Timing-Diagramm abgedruckt. Während des ganzen Read-Kommandos darf
RST nicht low werden, das passiert aber am Anfang der get16.... mit dem
Befehl mov p1,#2 !!! (müsste für DQ doch eh #4 gewesen sein, oder? na,
dann war aber mein Kommentar wegen RST low falsch?!?) Egal, besser:
setb p1.2
Genauso weiter unten: Mit anl a,#2 liest Du natürlich die RST-Leitung
und nicht die DQ-Leitung aus.Um da nicht durcheinanderzukommen
definiere doch mal oben im Prog
RST EQU P1.1
CLK EQU P1.0
DQ EQU P1.2
Außerdem dachte ich, mit meiner Hilfe in der put-Prozedur könntest Du
die get-Prozedur genauso umschreiben:
;-----------------------------------------------------------------------
-----------------
;** Funktionen: get1620byte -> liest den Wert von DS1620 in 1620byte
;-----------------------------------------------------------------------
-----------------
get1620byte: setb DQ ;| DQ = HIGH=INPUT
; setb p1.0 ; Sowohl CLK als auch RST
; setb p1.1 ; sollten noch HIGH sein!!!
mov b, #8
wordlength2: clr CLK ;|CLOCK= LOW
setb CLK ;|CLOCK= HIGH
mov c, DQ
rrc a
djnz b,wordlength2
vorzeichenbit: clr CLK ;|CLOCK= LOW
setb CLK ;|CLOCK= HIGH
mov c, DQ
mov vorzeichen, c ; ACHTUNG: vorzeichen ist BIT-Variable
mov ds1620byte,a
mov p1, #0 ;|OUTPUT
ret
Soweit die Fehler, die mir noch aufgefallen sind. Ich muß aber zugeben,
das ist noch keine Erklärung dafür, warum die CLK-Impulse aufhören. Doch
halt, da ist nochwas: cjne a,#7,vorzeichenbit ist der Fehler: a bzw
bit_stelle2 ist nur beim ersten Schleifendurchlauf 7. Danach springt er
immer zu vorzeichenbit. Es wird also nur ein weiterer CLK-Impuls
generiert. Stimmt das mit Deinen Beobachtungen am Oszi überein?
Wenn ja sollte ja jetzt alles laufen.
Gut progg!
Markus_8051
juhu es klappt!!!
mußte noch mit dem Oszi noch einen letzten Fehler suchen. Hatte immer
0xFF eingelesen, aber am Ozsci war der richtige Wert zu erkennen. Das
einlesen, nachdem Clock auf High gesetzt wurde war falsch! Ich muss
lesen wenn Clock auf Low ist, also bevor er High wird liegt das Signal
an.
So sieht jetzt die get... Funktion aus:
get1620byte: setb DQ ;| DQ = HIGH=INPUT
mov b, #8
wordlength2: clr CLK ;|CLOCK= LOW
mov c, DQ
setb CLK ;|CLOCK= HIGH
rrc a
djnz b,wordlength2
vorzeichenbit: clr CLK ;|CLOCK= LOW
mov c, DQ
setb CLK ;|CLOCK= HIGH
mov vorzeichen, c ;
mov ds1620byte,a
mov p1, #0 ;|OUTPUT
ret
VIELEN DANK MARKUS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Jo, Du hast recht!
Steht auch so im Datenblatt: Spätestens 150ns nach CLK_Low liegen die
Daten an und 50ns nach CLK_High wird DQ hochohmig, sprich der µC liest
ne 1. Wenn der µC schneller wird, muß Du zwischen clr CLK und mov c,DQ
noch etwas warten.
Aber schön, daß es jetzt klappt.
