Hallo,
Ich will einen DS18S20 auslesen... Ich benutze ienen Controller von
Atmel mit nem Takt von 7,37 MHz.
Die Prozeduren zum Reset, Schreiben und Lesen müssten eigentlich
stimmen, hab mal ein Oszi dran gehangen... Doch irgendwie haut das noch
nicht ganz hin...
Könnt ihr mir weiter helfen? Hab meinen C-Code angehängt...
Danke schön!
Warum versuchst du, Fahrräder noch einmal zu erfinden? Die Funktion
delay1() wird auf einem GCC 4.x zu gar nichts mehr evaluieren, weil
sie laut Meinung des Compilers nichts macht. Die Funktion delay_ms()
verzögert zwar irgendwas, aber was lässt dich annehmen, dass sie
etwas Millisekundenartiges darstellen würde?
Tu dir einen Gefallen, und nimm den Krempel aus <util/delay.h>, dafür
ist er nämlich da.
Ich hatte aus Interesse auch mit mit einem DS18S20 (?) angefangen,
hier das Resultat:
Wie du aber mit den aus der Luft gegriffenen Warteschleifen ein
definiertes Timing erreichen willst, haste mir immer noch nicht
verraten. Timing ist aber zwangsweise bei 1-wire das A und O.
Dieses delay1(); ist eine von mir geschriebene Schleife, hab die so
genannt... Sie zählt von 0 bis zum eingegebenen Wert... Muss im
Quelltext wohl verloren gegangen sein...
Sascha wrote:
> Dieses delay1(); ist eine von mir geschriebene Schleife, hab die so> genannt... Sie zählt von 0 bis zum eingegebenen Wert... Muss im> Quelltext wohl verloren gegangen sein...
Nein, ist nicht verlorengegangen. Wie ich dir aber schon einen
Kilometer weiter oben geschrieben habe (interessiert dich eigentlich,
welche Gedanken sich die Leute um dein Zeug machen?), macht sie nur
aus Sicht des Compilers rein gar nichts, folglich eliminiert er sie.
Das ist sein gutes Recht. Du hast keinen Anspruch auf einen
bestimmten Assemblercode, sondern nur einen Anspruch darauf, dass der
generierte Assemblercode funktional genau das tut, was du in C
hingeschrieben hast. Eine Zuweisung zu einer Variablen, die nie
wieder benutzt wird, hat funktional keinen Effekt.
Daher mein Hinweis, bitte doch statt deines selbstgerödelten und nicht
wirklich verstandenen (geschweige denn im Assemblercode getimeten)
Codes bitte die Funktionen aus <util/delay.h> zu benutzen. Das Timing
ist das A und O bei 1-wire (das liegt in der Natur der Sache), da
solltest du besser auf Bewährtes zurückgreifen, statt sinnlose
Fahrräder noch einmal zu erfinden. Als Beispiel dann mein Code, der
ungefähr dasselbe tun sollte wie deiner, außer dass ich eine minimale
Hardwareabstraktion bereits von vornherein eingeplant habe (die deinem
Code aber sicher auch gut zu Gesicht stünde).
Sascha wrote:
> Na das is doch egal ob nu ein Pin ausgang is oder net, den Status erfrag> ich mit PINC0, also nur einem Pin...
Tust Du eben genau nicht !!!
Sebastian wrote:
> Wie realisiere ich:>> "Bitte mit -Os und -std=gnu99 compilieren.">> mit AVR Studio4?
Indem du dich durch die entsprechenden Optionen durchklickerst.
Oder gleich ein externes Makefile nimmst. ;-)
> läuft das Programm?
Es ist keins, sondern nur ein paar Funktionen. Ein lauffähiges
Programm musst du dir schon selbst drumschreiben.
Hallo Sascha
Ich würd ja den Code vom Jörg nehmen da er vorbildlich programmiert ist.
Wenn Du jedoch probieren möchtest ob dein Code funzt, dann definiere
die Variablen im delay Unterprogramm zusätzlich mit der volatile
Anweisung. Die sagt dem Compiler nämlich das er die Variable nicht
wegoptimieren darf.
LG
Michael
Mmmh ich hab das Programm 1 zu 1 übernommen...
funzt aber net... ich seh aufm Oszi nicht, dass das scratchpad
ausgegeben wird... Ich benutze nen Quarz mit 7,3728MHz... Des Weiteren
benutze ich Port G0...
> Ich benutze nen Quarz mit 7,3728MHz...
Hast du dann auch F_CPU angepasst?
Außerdem solltest du wohl auch die printf()s rausnehmen, es sei denn,
du hast stdio irgendwie ohnehin bereits konfiguriert.
Hallo,
Ja ich habe das auf 7372800 geändert, die printf hab ich alle
rausgenomen... Ich probier morgen nochma ein bissel... meld mich dann
wieder... Was ich fragen wollte: die Anweisung _delay_ms(0.48); müsste
doch 480µs verzögern... laut Oszi ist das aber weit mehr...? Hängt das
eventuell von meiner Hardware ab?
MfG
> die Anweisung _delay_ms(0.48); müsste> doch 480µs verzögern...
Genau.
> laut Oszi ist das aber weit mehr...?
Zufällig 3.53 ms?
.
.
.
.
.
.
.
.
.
.
Schalt deinen Quarz bitte ein, dein AVR läuft noch mit dem 1-MHz-
RC-Oszillator...
Wer generiert denn dein Makefile? (Ich vermute mal, du hast es sicher
nicht mit der Hand geschrieben.)
Bei Mfile:
Makefile -> Optimization level -> s (ist aber dort die Voreinstellung)
Bei AVR Studio musste mal selbst gucken, hab' ich hier nicht.
Hallo,
ich versuche jetzt schon seit gestern den ds18s20 zum laufen zu
bekommen, es gelingt mir aber nicht. Ich wollte ganz einfach anfangen
und erstmal den Presence Puls abfragen und genau da liegt schon das
Problem. Der Sensor antwortet einfach nicht. Am Sensor kann es
eigentlich nicht liegen, da ich schon andere ausprobiert habe. Ein Oszi
hab ich leider auch nicht zur Hand. Zum testen habe ich den Code von
Jörg Wunsch benutzt und nur per main()die Funktion ow_reset() aufgerufen
(siehe Anhang). Ich benutze eine AtMega32@16MHz und betreibe den Sensor
mit eigener Spannungsversorgung und 4,7k Pullup an der Datenleitung. Wer
schön wen jemand von euch eine Idee hat.
Gruß Fisch
Hallo.
Nachdem ich den Sensor jetzt parasitär angschlossen funktioniert es
schon besser. Ich kann selbst die Register auslesen. Aber es ist schon
wieder ein neues Problem aufgetaucht. Wenn ich die Temperaturregister
auslese bevor ich eine Wandlung durchgeführt habe, sendet der DS mir 85°
was ja auch seine Richtigkeit hat. Nur wenn ich vorher eine Messung
mache, zeigt er mir immer 127° (bzw. 00 FF) an. Ich warte zwischen
Messung und dem Auslesen >1s. Hat jemand von euch solch ein Problem
schonmal gehabt?