Hiermit stelle ich eine Implementierung des OneWire-Protokolls für DS18x20 zur Diskussion. Aufbauend auf den Projekten: http://knowledgebase.nxp.com/showthread.php?t=1421 http://gandalf.arubi.uni-kl.de/avr_projects/tempsensor/index.html habe ich eine Anpssung an das LPCXpresso 1769 Boards vorgenommen mit folgenden Änderungen: - Es sollte in einer FreeRTOS Umgebung laufen und damit resistent gegen Task-Wechsel sein. - keine delay-Schleifen enthalten In der Knowledgebase von nxp gab es dazu ein Example, das einen Timer zur Steuerung des Pins verwendet hat. Allerdings hatte diese Implementiereung auch ein paar Nachteile. Im Hauptprogramm wurde der OneWire Pin auf LOW gezogen und dann der Timer gestartet. Wenn an dieser Stelle jetzt ein Taskwechsel dazwischen kommt, geht das mit dem Timing in die Hose. Eine Lösung wäre das Verhindern von Task-Wechseln an vielen Stellen im Code oder eine Verlagerung auch des ersten Schritts in den Interrupt. Ich habe mich für das zweite entschieden. Dann mussten noch die delay-Schleifen raus. Da die Kommunikation eigentlich immer Reset-Schreiben-Lesen oder nur Reset-Schreiben ist, habe ich die gesamte Sequenz im Interrupt verarbeitet ohne nochmal die Hilfe des Hauptprogramms in Anspruch zu nehmen. Bei allen Befehlen ausser dem Starten der Messung reichen ca. 50ms warten in der RTOS-Task aus (was keine Rechenzeit verschwendet) zur Verarbeitung des Befehls. Nach dem Starten der Messung muss wenigsten 750ms gewartet werden bis der DS18x20 seine Wandlung beendet hat. Ich verwende nur die 2 Draht Version mit parasitärem power. Weiterhin habe ich das Umschalten der Pin Direktion im FIODIR Register rausgeschmissen und statt dessen den Pin ständig im OpenDrain-Modus und als Ausgang betrieben. Das Lesen das Pins im FIOPIN Register liefert in diesem Modus trotzdem den wahren Wert am Pin. Am Ende des CONV-Commandos muss im parasitären Modus der Pin hart auf VCC geschaltet werden damit der DS18x200 genügend Strom zur Wandlung bekommt. Während dieser Zeit wird der Opendrain-Modus ausgeschalten und vor dem nächsten Reset wieder eingeschaltet. Einzige kritische Operation die nicht atomar ist, ist die Manipulation des PINMODE_OD Registers. Das passiert bei mir im Interrupt und ist damit geschützt, alle anderen müssen aber aufpassen, dass gleichzeitige Änderungen an diesem Register verriegelt werden müssen. Das wird aber nur selten vorkommen. Es erklärt sich sicherlich von selbst, daß der Inetrrupt eine sehr hohe Priorität haben muss und nicht durch andere Interrups unterbrochen werden darf, sonst geht das gesamte Timing durcheinander. Ich packe mal das gesamte Projekt als zip in den Anhang. Da ist auch das FreeRTOS mit dabei wie es von CodeRed beim Anlegen eines Projektes mit generiert wird und 2 simple Tasks die nur als Demo dienen. Ausgaben gibt es keine, die gemessenen Werte kann man sich nur im Debugger ansehen. In der system_LPC17xx.c sind noch ein paar Änderungen drin die das LPCXpresso 1769 mit den maximalen 120MHz laufen lassen. Anmerkungen und Verbesserungen nehme ich gern entgegen. Jürgen Liegner
Warum nicht mit I2C Chip DS2482-100 über einen richtigen Treiber einbinden? Ist fix gemacht und läuft innerhalb eines RTOS ohne Klimmzüge. Als Grundlage kann die avrlibc von Pascal Stang dienen. Sourcecode ( und auch eine erweiterte avrlibc mit Treibern für weitere 1Wire Chips) für den DS2482-100 kann ich bei Bedarf per email senden. Ich werde die avrlibc zumindest teilweise auf den LPC1114 und den LPC1769 mit FreeRTOS portieren, komme aber erst im November dazu (LCD Controller/I2C/SPI/SD-Card/PWM/RTC und weitere Komponenten). Grüße
Jürgen Liegner schrieb: > Weiterhin habe ich das Umschalten der Pin Direktion im FIODIR Register > rausgeschmissen und statt dessen den Pin ständig im OpenDrain-Modus > und als Ausgang betrieben. Das Lesen das Pins im FIOPIN Register liefert > in diesem Modus trotzdem den wahren Wert am Pin. Das ist für mich eine Art Lackmus-Test für sinnvolle GPIO Bauweise von Mikrocontrollern. Bei denen mit ARM-Macrocell als Basis der GPIO, wie STR9 und LM3, geht nämlich aus der Doku hervor, dass man bei O.D.-Ausgängen den Sollzustand des Output-Registers liest, nicht den Istzustand. Wozu habe ich einen potentiell bidirektionalen O.D.-Pin wenn ich dessen realen Zustand nicht lesen kann? Wenn ich dafür eigens die Richtung wechseln muss, wozu dann überhaupt eine O.D.-Konfiguration von Pins?
Reiner Geiger schrieb: > Warum nicht mit I2C Chip DS2482-100 über einen richtigen Treiber > einbinden? Weshalb, wenns offensichtlich auch ohne geht? Wenn man schon ein schnelles Interrupt-System hat, das dank pfiffiger IRQ-Level-Steuerung der Cortexe auch durch RTOS-Locks nicht blockiert wird...
A. K. schrieb: > Weshalb, wenns offensichtlich auch ohne geht? Wenn mann damit zurecht kommt, geht es natürlich auch ohne. Wenn man komplexere Multisensorsysteme ist es kalt einfacher (übersichtlicher und wartungsfreundlicher/portierbarer) systematisch Treiber zu erstellen. Ist doch einfach nett, wenn mann gleichzeitig SPI Schreibvorgänge((SD-Card)FAT) und I2C-1Wire-Seek für z.B. 40 (auch verschiedene) Sensoren und I2C RTC-Daten abarbeiten kann, ohne auf das spezielle Timing eines Prozessortypen oder einer Prozessorfamilie achten zu müssen, da das alles von vornherein portierbar implementiert ist. Aber natürlich geht's auch ohne, speziell wenn nur man die Möglichkeiten eines Prozessors austesten möchte; dann ist es sogar sehr sinnvoll, wenn man sowas selbst implementiert! Trotzdem: @Jürgen Falls Interesse am Sourcecode vorhanden ist, einfach eine E-Mail senden. Grüße
Hallo Reiner Geiger, diesen Chip kannte ich bisher nicht. Deine Argumente sind sicherlich nachvollziehbar. Ich bin für meinen Teil aber recht glücklich, dass ich mit dem LPCXpresso 1769 ein Board zum Basteln für kleines Geld kaufen kann und das mich auch von der Herstellung weiterer smd-Boards befreit. Da ist Ethernet mit dem Anschluss einer Buchse erledigt. Ein eeprom ist schon auf dem Xpresso mit drauf und was ich sonst noch so anschließen muss ist mit einer Lochrasterplatine erledigt. Deshalb sehe ich für meine Projekte davon ab, wie ich mich für eine Produktionsentwicklung entscheiden würde steht auf einem anderen Blatt. Ausserdem wollte ich damit nur ein paar Schwächen beseitigen den der Code, der als Basis von meinem diente, aus meiner Sicht noch hatte.
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.