Moin, ich habe schon öfter die Maxim DS1820 Temperatursensoren eingesetzt, jedoch habe ich bisher nie negative Temperaturen benötigt, daher habe ich immer nur das Byte 0 gelesen und das "Sign"-Byte 1 nicht mit gelesen. Nun habe ich aber eine Anwendung, in der ich auch negative Temperaturen auswerten muss. Daher dachte ich mir, es müsste ja reichen, wenn ich nur ein 9. Bit lese, statt ein weiteres komplettes Byte (um Zeit zu sparen). Leider führt das dazu, dass ich jetzt immer nur noch den "default"-Wert von 85°C auslese. Offensichtlich funktioniert also Convert_T nicht mehr. Im Datasheet im Kapitel ReadScratchpad steht: The master may issue a reset to terminate reading at any time if only part of the scratchpad data is needed. Offensichtlich stimmt das nicht ganz, denn ich vermute, dass man zumindest ganze Bytes lesen muss und nicht nach 9 gelesen Bits abbrechen kann. Kann das jemand bestätigen? Oder sonst eine Idee, warum ich plötzlich nur noch 85°C auslese? Danke euch!
Robert S. schrieb: > Oder sonst eine Idee, warum ich plötzlich nur noch 85°C auslese? 85°C ist der Kaltstartwert. Den kriegst Du, wenn bisher keine erfolgreiche Temperaturmessung stattfand. Möglicherweise fliegt der DS per Notausgang aus dem Protokoll raus. Ergo: Lies das Ding so, wie Dallas es vorgesehen hatte. In ganzen Bytes, nicht in Bruchstücken.
:
Bearbeitet durch User
Robert S. schrieb: > Offensichtlich funktioniert also Convert_T nicht mehr. Es wird eher ein Fehler in Deinem Programm sein.
Peter Dannegger schrieb: > Es wird eher ein Fehler in Deinem Programm sein. Logisch. Ich wollte damit auch nicht aussagen, dass der Sensor defekt ist. A. K. schrieb: > Lies das Ding so, wie Dallas es vorgesehen hatte. In ganzen Bytes, > nicht in Bruchstücken. Naja, wo steht denn, dass man ganze Bytes lesen muss? Daher ja das Zitat aus dem Datasheet: Robert S. schrieb: > The master may issue a reset to terminate reading at any time if only > part of the scratchpad data is needed. Also meinen die mit "any time" wohl eher "after any full byte".
Robert S. schrieb: > Logisch. Na dann ist ja alles klar. Robert S. schrieb: > Naja, wo steht denn, dass man ganze Bytes lesen muss? Nirgends. Ohne Code kann man nicht mehr dazu sagen.
:
Bearbeitet durch User
Also, was ich mache ist folgendes (8051 ASM): LCALL resetDS1820 LCALL skiprom LCALL convert_t - Pause - LCALL resetDS1820 LCALL skiprom LCALL readscratch LCALL lesebyte Wobei bewiesen ist, dass die Funktionen resetDS1820, skiprom, convert_t und readscratch funktionieren, denn positive Temperaturen konnte ich ja immer lesen. Die Funktion lesebyte hat auch immer funktioniert, bis ich sie auf 9 Bit erweitert habe: lesebyte: MOV A, #00h MOV R6, #08h ; Schleifenzähler looplesebyte: LCALL read ; Das Ergebnis (0 oder 1) liegt nun in TempBit JNB TempBit, BitIstNull INC A ; Entsprechend wird ein Bit im Akku gesetzt... BitIstNull: RR A ; ...und der Akku zum nächsten Bit rotiert DJNZ R6,looplesebyte MOV tempaktuell,A ; nun wurden 8 Bit gelesen und in tempaktuell abgelegt - jetzt kommt die Erweiterung für's 9. Bit - LCALL read JNB TempBit, Positiv SETB SignBit RET Positiv: CLR SignBit RET Danach geht's von vorne los, doch mit der Erweiterung auf's 9. Bit lese ich dann nur noch 85,0°C aus... A.K. könnte Recht haben, dass der DS1820 einen "Notausstieg" macht, weil er mitten im Byte einen Reset bekommt und daher convert_t im nächsten Durchgang nicht mehr ausführt.
:
Bearbeitet durch User
Anders formuliert: Wenn du 85 °C liest, dann funktioniert deine Lese- und auch deine Umrechungsroutine. Der Sensor hat nur noch nie irgendeine Messung erfolgreich durchgeführt. Also liegt dein Problem (erstmal) woanders. Und ich wüßte nicht, wie das Abrrechen des Lesens nach 9 bits vom DS einen Einfluß auf die bereits in deinen Controller gelesenen bits haben kann. Mag sein, daß er danach mit reset oder was auch immer reagiert. Aber das kann dir dann (bis zur Nächsten Messung) völlig egal sein. Also wird wohl deine Umrechnungsroutine das Problem sein.
Ich denke mal, dass das convert_t beim ersten Mal funktioniert und mein Controller auch beim ersten Durchlauf eine korrekte Temperatur erhält (das kriege ich jedoch gar nicht mit, da ja sofort wieder von vorne angefangen wird). Dann bringt er jedoch den Sensor durcheinander, indem er nach dem 9. Bit das Lesen abbricht und der Sensor sich somit selbst resettet. Dadurch verpasst er das erneute convert_t, hat sich aber bis zum readscratch wieder gerappelt und gibt dann wieder 85 aus. Das wäre meine Theorie... Denn ich habe wirklich nirgends etwas geändert, außer die Erweiterung für's 9. Bit. Und ohne diese Erweiterung läuft es ja super, aber halt nur für positive Temperaturen. Ich werde wohl nicht drum herum kommen, (testhalber) das 2. Byte mal komplett mit auszulesen. Und wenn das geht, muss ich mir Gedanken machen, wie ich mein Timing in den Griff kriege...
wenn du Probleme mit der 85°C hast liegt es daran das du die 750ms im Convert_T nicht einhälst. Robert S. schrieb: > Nun habe ich aber eine Anwendung, in der ich auch negative Temperaturen > auswerten muss. Daher dachte ich mir, es müsste ja reichen, wenn ich nur > ein 9. Bit lese, statt ein weiteres komplettes Byte (um Zeit zu sparen). ach jetzt verstehe ich du willst das Byte für die Anzeige ob Plus oder Minus sparen.... trotzdem das Temp_MSB komplett auslesen siehe DS18S20 FUNCTION COMMANDS FLOW CHART Figure 15 im Datenblatt im Commando ReadScratchpad
Robert S. schrieb: > Und wenn das geht, muss ich mir Gedanken > machen, wie ich mein Timing in den Griff kriege... ähm die sollten absolut strikt eingehalten werden!!!
chris schrieb: > ach jetzt verstehe ich du willst das Byte für die Anzeige ob Plus oder > Minus sparen.... Nicht direkt. Ich will nur die Zeit sparen, da ich so schnell wie möglich mehrmals hintereinander die Temperatur auslesen will. >trotzdem das Temp_MSB komplett auslesen siehe > DS18S20 FUNCTION COMMANDS FLOW CHART Figure 15 im Datenblatt > im Commando ReadScratchpad Weil dort immer nur von "Bytes" die Rede ist oder wie kommst Du darauf? chris schrieb: >> Und wenn das geht, muss ich mir Gedanken >> machen, wie ich mein Timing in den Griff kriege... > > ähm die sollten absolut strikt eingehalten werden!!! Mit "Timing" meine ich, dass ich möglichst schnell mehrmals hintereinander auslesen möchte. Sorry für die schlechte Wortwahl! Das 1-Wire-Timing scheint zu passen, sonst hätte ich ja schon Probleme mit positiven Temperaturen. Das mit den 750ms klingt zwar logisch und ich kann das auch nicht völlig ausschließen. Aber warum klappt es dann, wenn ich nur positive Temperaturen auslese? Sehr merkwürdig...
Hi >Nicht direkt. Ich will nur die Zeit sparen, da ich so schnell wie >möglich mehrmals hintereinander die Temperatur auslesen will. Warum? Trotz 1-Wire sind Temperaturänderungen immer noch um Größenordnungen langsamer. MfG Spess
Robert S. schrieb: > Ich will nur die Zeit sparen, da ich so schnell wie > möglich mehrmals hintereinander die Temperatur auslesen will. Das ist lächerlich. Eine Wandlung dauert 500ms, 7 Bits nur 420µs, das sind <0,1% Einsparung!
Peter Dannegger schrieb: > Eine Wandlung dauert 500ms, 7 Bits nur 420µs, das sind <0,1% Einsparung! und wenn es 100 Sensoren sind die gleichzeitig ihre Wandlung machen, dann sieht die Rechnung schon anders aus.
Peter II hat es erfasst. Es geht hier nicht nur um einen Sensor ;) Aber wie auch immer, ich muss es einfach mal ausprobieren. Danke euch erst mal!
Peter II schrieb: > und wenn es 100 Sensoren sind die gleichzeitig ihre Wandlung machen, > dann sieht die Rechnung schon anders aus. Dann könnte man ~5% sparen, ist immer noch nicht beeindruckend viel. Aber hat denn schonmal jemand 100 Sensoren an einem Bus erfolgreich betrieben? Abgesehen davon führen ständige Wandlungen an Luft zu merkbarer Eigenerwärmung (5mW). Ich wandele daher nur alle 10s.
Robert S. schrieb: > Weil dort immer nur von "Bytes" die Rede ist oder wie kommst Du darauf? nein da steht doch eindeutig das der Master ein Reset machen darf und noch eindeutiger wirds unter DS18S20 FUNCTION COMMAND SET Table 4 Read Scratchpad.................................................Notes 2 2) The master can interrupt the transmission of data at any time by issuing a reset Wie möchtest du eigentlich die Adressen der Sensoren auslesen? über einen SearchRom oder einen MatchRom? Bedenke du kannst alle Sensoren am Bus zur selben Zeit mit SkipRom gefolgt von nem Convert_T zur Messung anstupsen. Das spart dir schon mal enorm viel Zeit 1x750ms warten statt 100x750ms und danach kannst du jeden Sensor einzeln Anprechen und nur die Temp auslesen. Mal angenommen um nur einen Sensor auszulesen presence puls > ca 240µs + matchrom > 8bits (4*15µs+4*120µs) = 540µs (01010101) + AdressSend > 64bits (38*15µs+26*120µs) = 3960µs + readscratchpad > 74bits (30*15µs+44*120µs) = 5730µs + presence puls > ca 240µs ------------------------------------------------------------------------ ------------ ca pi mal Daumen 15ms / Sensor und das für 100 ca 1,5s. und die Zeit wird jeder haben beachte was Peter Dannegger schrieb alle 10s und mehr reicht dicke aus um die Eigenerwärmung zu minimiren auf vielleicht 0,2°.
Das nur 9 Bit lesen sollte eigentlich funktionieren. Aber erstmal müßte man wissen, welcher Sensor es wirklich ist. Da der Startwert 85°C ist, kann es nur ein DS18S20 oder DS18B20 sein. Der DS1820 mit 0°C Startwert und 500ms Wandlung wird ja nicht mehr hergestellt.
Nabend, peinlich, peinlich... Ich habe meinen Fehler entdeckt. Zunächst mal: Kein Timing-Problem und nur 9 Bit lesen funktioniert auch. Mein Problem war, dass ich genau bei dem Sensor, bei dem ich das mit dem 9. Bit getestet habe, die Aufrufe LCALL resetDS1820 LCALL skiprom LCALL convert_t vergessen habe. Bei allen anderen hab ich sie drin. So ein Mist! Oh man, tut mir echt Leid! Aber wir sind ja alle nicht dümmer geworden. ;) chris schrieb: > Wie möchtest du eigentlich die Adressen der Sensoren auslesen? > über einen SearchRom oder einen MatchRom? Ich mache einfach ein SkipRom, da jeder Sensor seinen eigenen Port-Pin hat. > Bedenke du kannst alle Sensoren am Bus zur selben Zeit mit SkipRom > gefolgt von nem Convert_T zur Messung anstupsen. Jo, diese Idee kam mir im Laufe dieser Diskussion auch. Das habe ich jetzt auch erfolgreich umgesetzt. > 2) The master can interrupt the transmission of data at any time by > issuing a reset Eben, genau das schrieb ich ja bei Threaderöffnung. Und Recht haben sie ;) Dann nochmals danke für eure Tipps!
Daher immer den genauen und kompletten Code als Anhang posten! Das Posten von einzelnen Schnipselchen ist in der Regel völlig sinnlos. Die Frager posten nämlich immer nur den Code, an dem es garantiert nicht liegt. Manche posten sogar einen völlig anderen Code oder denken sich einfach zum Posten einen neuen aus, den sie nie getestet haben. Manchmal erkennt man schon an den Syntaxfehlern, daß der nie übersetzt wurde, geschweige denn getestet. Ich versteh das nicht, wollen die keine Hilfe? Auch das Beschreiben von Code in Worten, wie man selber meint, ihn geschrieben zu haben, ist völliger Humbug. Code kann man immer nur als Code posten und immer auch mit der richtigen Endung (.c, .asm, .bas). .jpg, .doc, .pdf versteht kein Compiler und wir auch nicht.
:
Bearbeitet durch User
>Ich versteh das nicht, wollen die keine Hilfe?
Die Antwort ist 42!
Wollen die keine Hilfe? 42!
Passt irgendwie nicht.
Also ist das die falsche Frage.
;-)
Peter Dannegger schrieb: > Daher immer den genauen und kompletten Code als Anhang posten! Ist bei kommerziellen Projekten nicht gerade schlau... Chris schrieb: > Hast du mal versucht die Adressen der Sensoren auszulesen? Mit dem 8051 nicht, mit nem STM32 habe ich das mal gemacht.
Robert S. schrieb: > Peter Dannegger schrieb: >> Daher immer den genauen und kompletten Code als Anhang posten! > > Ist bei kommerziellen Projekten nicht gerade schlau... Es muß nicht zwingend der Originalcode sein, aber auf jeden Fall ein Programm, das man so durch den Compiler/Assembler hat laufen lassen und das den Fehler dabei auch gezeigt hat. Peter hat schon recht damit, daß sich Leute viel zu oft für das Posting extra eigenen Code ausdenken, der dann den Fehler, um den es geht, gar nicht enthält, aber dafür andere. Es ist für Leute, die darauf antworten und lang und breit erklären, was der Fehler ist, sehr frustrierend, wenn es danach heißt, daß der "eigentliche" Code diesen Fehler natürlich nicht enthält. Später setzt der Frager dann noch einen drauf, indem er postet, daß er den Fehler selbst gefunden hat und daß dieser wo ganz anders gelegen hat. Deshalb reagieren manche hier etwas allergisch auf sowas.
Hi
>Ist bei kommerziellen Projekten nicht gerade schlau...
Da geht man auch nicht in ein Hobby-Forum.
MfG Spess
Na denn würde ich es mit dem 8051 schleunigst umsetzen weil du Programmzeilen und Hardwareaufwand sparst.
Robert S. schrieb: > Peter Dannegger schrieb: >> Daher immer den genauen und kompletten Code als Anhang posten! > > Ist bei kommerziellen Projekten nicht gerade schlau... Auch kommerzielle Projekte kann man soweit reduzieren, daß der Fehler immer noch auftritt. Und besonders kommerzielle Projekte sollte man modular aufbauen, da erfahrungsgemäß der Auftraggeber noch 1000 Änderungswünsche hat. Dann ist es ein leichtes, die "geheimen" Module wegzulassen. Robert S. schrieb: > Chris schrieb: >> Hast du mal versucht die Adressen der Sensoren auszulesen? > > Mit dem 8051 nicht, mit nem STM32 habe ich das mal gemacht. Wenn man in C programmiert, ist nur die Reset- und die Bit-IO-Funktion anzupassen, der restliche Code bleibt gleich. Die leichte Portierbarkeit von Code war für mich auch ein entscheidender Grund, C zu lernen.
:
Bearbeitet durch User
Ihr habt natürlich Recht, was das Posten des Sourcecodes angeht. Und die Frustration bei den beschriebenen Fällen ist verständlich. Ich kann nicht mehr, als mich dafür zu entschuldigen und Besserung zu geloben. Aber ein komplettes Projekt mit mehreren 1000 Zeilen zu Posten ist sicherlich auch nicht die Lösung. Und so hatte ich Peter anfangs verstanden. spess53 schrieb: > Da geht man auch nicht in ein Hobby-Forum. Sondern? Kannst Du eines empfehlen? Mir wurde hier bisher immer gut geholfen. Und hier sind so einige Leute kommerziell unterwegs. Bei mir ist es in der Regel auch privat, aber wenn ich beruflich ein Problem habe, warum soll ich da anders vorgehen? Peter Dannegger schrieb: > Die leichte Portierbarkeit von Code war für mich auch ein entscheidender > Grund, C zu lernen. Den STM32 programmiere ich natürlich in C. Die 8051-Projekte sind historisch gewachsen. Für ein neues Projekt würde ich so einen uC sowieso nicht mehr einsetzen ;) Chris schrieb: > Na denn würde ich es mit dem 8051 schleunigst umsetzen weil du > Programmzeilen und Hardwareaufwand sparst. Das Problem ist, dass ich viele Sensoren habe, die unter Umständen mit erheblichen Leitungslängen in einer Mischung aus Stern- und Ringtopologie zusammengeschaltet werden könnten. Das wäre nicht gut für den 1-Wire-Bus. Daher "verbiete" ich das lieber von vornherein und schließe jeden Sensor einzeln an die CPU an. Da der Controller eh nichts anderes machen soll, als die Sensoren auszulesen und die Temperaturen per UART weiter zu geben, habe ich genügend IOs zur Verfügung.
Wenn das Auslesen schnell gehen muss kannst du ja auch einen ganzen Port parallel einlesen anstatt die einzelnen Sensoren nacheinander.
Robert S. (efyzz) schrieb: > Chris schrieb: >> Na denn würde ich es mit dem 8051 schleunigst umsetzen weil du >> Programmzeilen und Hardwareaufwand sparst. > > Das Problem ist, dass ich viele Sensoren habe, die unter Umständen mit > erheblichen Leitungslängen in einer Mischung aus Stern- und > Ringtopologie zusammengeschaltet werden könnten. Das wäre nicht gut für > den 1-Wire-Bus. Daher "verbiete" ich das lieber von vornherein und > schließe jeden Sensor einzeln an die CPU an. Da der Controller eh nichts > anderes machen soll, als die Sensoren auszulesen und die Temperaturen > per UART weiter zu geben, habe ich genügend IOs zur Verfügung. Mmmhh ok wieviel möchtest du denn an einen Pin dranhängen und von welchen Leitungslängen reden wir denn? http://shop.wiregate.de/1-wire-bus
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.