Announcement: there is an English version of this forum on Moin, ich beschäftige mich momentan mit Temperaturmessungen und da stolpert man ja sofort über den DS18B20. Ich hätte eine 3. Ader für VDD, also KEINE parasitäre Versorgung. Soweit ich das verstanden habe, könnte ich DQ an einen Port hängen der als Open-Drain konfiguriert ist und dann per Bit-Banging lesen und schreiben. Ich frage mich, ob es irgendwelche Bus-Protokolle gibt, die einem da Arbeit abnehmen können? Was ist z.B. mit USART im Modus Single Wire (Half Duplex)? Könnte man am USART-Pin irgendwie den Reset-Puls senden (keine Ahnung wie das gehen soll wenn der Port schon als USART_TX konfiguriert ist), dann per HAL_UART_Transmit einen ROM Command senden (keine Ahnung wie das ohne die passende Baudrate gehen soll) und z.B. per HAL_UART_RxCpltCallback die Antworten empfangen? Wenn es sein muss, mache ich das alles per Hand und mit Timern, aber wenn es einen Weg gibt sich nicht so lange mit Timing-Problemen herumzuschlagen, wäre das schön. Vielen Dank schon mal.
Gerd schrieb: > Ich frage mich, ob es irgendwelche Bus-Protokolle gibt, die einem da > Arbeit abnehmen können? Was ist z.B. mit USART im Modus Single Wire > (Half Duplex)? Es gibt AppNotes für 1-Wire per UART. > Wenn es sein muss, mache ich das alles per Hand und mit Timern, aber > wenn es einen Weg gibt sich nicht so lange mit Timing-Problemen > herumzuschlagen, wäre das schön. Es gibt Protokollkonverter zwischen I²C/SPI und 1-Wire. Und es gibt fertigen Code im Internet.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Es gibt Protokollkonverter zwischen I²C/SPI und 1-Wire. > > Und es gibt fertigen Code im Internet. Und wenn du uns sagst welches System du hast bekommst du auch vernünftige Antworten.
Gerd schrieb: > ich beschäftige mich momentan mit Temperaturmessungen und da stolpert > man ja sofort über den DS18B20. Ich hätte eine 3. Ader für VDD, also > KEINE parasitäre Versorgung. Soweit ich das verstanden habe, könnte ich > DQ an einen Port hängen der als Open-Drain konfiguriert ist und dann per > Bit-Banging lesen und schreiben. Ja. > Ich frage mich, ob es irgendwelche Bus-Protokolle gibt, die einem da > Arbeit abnehmen können? Welche Arbeit? > Was ist z.B. mit USART im Modus Single Wire > (Half Duplex)? Kann man machen, aber warum? > Wenn es sein muss, mache ich das alles per Hand und mit Timern, Es gibt mehrere, fertige OneWire Libs. Z.B. die hier. Beitrag "Re: Onewire + DS18x20 Library" Timer braucht man dafür nicht. > aber > wenn es einen Weg gibt sich nicht so lange mit Timing-Problemen > herumzuschlagen, wäre das schön. Was für ein Gejammer!
Immer die wichtigsten Daten vergessen. 1. Auf welcher MC soll das Laufen 2. Wie weit ist die Entfernung zwischen MC + den Sensor. Ich denke ohne die Antworten kann man nur besseres raten machen.
Der Raspi Linux kennt einen 1-wire-Zugriff (unter /sys/bus/w1), evtl haben andere Linuxe das auch
Gerd schrieb: > Wenn es sein muss, mache ich das alles per Hand und mit Timern, aber > wenn es einen Weg gibt sich nicht so lange mit Timing-Problemen > herumzuschlagen, wäre das schön. Millionen von DS18B20 laufen, ohne dass sich die Programmierer mit den Timing-Details rumgeschlagen haben. Das ist genau der Sinn von Bibliotheken. Was ist bei dir die Motivation für eine Neuerfindung des Rades?
Hallo zusammen, vielen Dank für eure Hilfe. Momentan beschäftige ich mich mit einem Cortex M0, den ich mit STM32CubeIDE in C programmiere. Ich muss natürlich nicht das Rad neu erfinden und bin dankbar für gute Libs und sei es nur, um darin zu stöbern. Ich habe bei meinen Recherchen jedoch verschiedene Vorgehensweisen gesehen, wobei eben auch der USART vorkam. Ich fragte mich zwar, wie man mit dieser Schnittstelle einen speziellen Reset-Puls senden kann, aber da diese Interfaces im Grunde nur konfiguriert und mit Daten gefüttert werden und man sich anschließend um den ganzen Low-Level-Kram nicht kümmern muss, machte das bis auf die ungeklärten Fragen für mich durchaus Sinn.
admin schrieb: > evtl haben andere Linuxe das auch Ja. Notfalls über einen Umweg: DS2482 an einen I²C-Bus hängen, schon gibt's einen 1w-Bus. https://www.kernel.org/doc/html/latest/w1/masters/ds2482.html Falls es an erreichbaren I²C-Bussen mangelt: Per I²C-Tiny-USB auch leicht nachrüstbar.
:
Bearbeitet durch User
Gerd schrieb: > Ich fragte mich zwar, wie man mit dieser Schnittstelle einen speziellen > Reset-Puls senden kann ... Ein USART in der synchronen Betriebsart sollte doch nicht dauern mit Start-Stop dazwischen funken ...
(prx) A. K. schrieb: > Es gibt Protokollkonverter zwischen I²C/SPI und 1-Wire. Was soll das für ein Baustein sein? Falls Du den DS2482 meinst, das ist aber kein wirklicher Konverter. Das Timingproblem nimmt er einem nicht wirklich ab. Einziger Unterschied ist, das man sich nicht mehr um die Serialisierung der Befehle und Daten für den DS18B20 kümmern muß. Dafür muß man halt den DS2482 zusätzlich ansprechen. Vorteile bringt der DS2482, wenn man die parasitäre Versorgung des DS18B20 vor hat. Ansonsten gibt es genug Codebeispiele im Netz, wie man 1-Wire mit µC anspricht.
Schlaumaier schrieb: > 1. Auf welcher MC soll das Laufen > 2. Wie weit ist die Entfernung zwischen MC + den Sensor. Es ist völlig wurscht auf welchem µC das laufen soll. Das ändert am Code nichts Relavantes. Die Leitungslänge ist für's erste auch erstmal so ziemlich egal, wenn man die Hinweise des Dabla beachtet. Halt wieder mal ein Schlaumeierhinweis.
Zeno schrieb: > Falls Du den DS2482 meinst, das ist aber kein wirklicher Konverter. > Das Timingproblem nimmt er einem nicht wirklich ab. Es gibt inzwischen drei Nachfolger für I2C, evt. sind die pflegeleichter: - DS2483, inzwischen auch schon veraltet - DS2484, inkl. Pegelwandler 3.3/5V - DS2485, "1-Wire Command Scripting Capability", nur 3.3V, DFN-6 und natürlich den DS2480B mit UART <-> 1-Wire
Gerd schrieb: > Moin, > > ich beschäftige mich momentan mit Temperaturmessungen und da stolpert > man ja sofort über den DS18B20. Ich hätte eine 3. Ader für VDD, also > KEINE parasitäre Versorgung. Soweit ich das verstanden habe, könnte ich > DQ an einen Port hängen der als Open-Drain konfiguriert ist und dann per > Bit-Banging lesen und schreiben. > Bit-Banging geht nur mit gesperrten Interrupts, da sonst das Timing gerne durcheinander kommt. Am einfachsten geht es mit der Ansteuerung ueber UART.
Zeno schrieb: > Das Timingproblem nimmt er einem nicht wirklich ab. Ich hätte gedacht, dass man da nur die Wartezeit der Messung berücksichtigen muss
Bauform B. schrieb: > - DS2485, "1-Wire Command Scripting Capability", nur 3.3V, DFN-6 Der macht am Ende auch nix anderes als der 2482. Du sagst dem Teil per i2c "sende den Befehl 0x44 (startet die Konvertierung beim DS1820) auf den 1-Wirebus". Daraufhin serialisiert er den Befehl 0x44 und gibt ihn über den 1-Wirebus aus. Das Ganze ist eigentlich sogar noch ein bischen aufwändiger als wen man den 1-Wirebus selbst ansprechen würde. Um diesen einen 1-Wire befehl senden zu können, muß man den Baustein erst mal ansprechen, gegebenenfalls initialisieren. Dann teilt man ihm mit das man einen 1-Wirebefehl senden möchte und schickt im anschließend diesen Befehl. Beim Datenlesen ist es ähnlich, erst teilt man ihm mit das man Datenaus dem Register lesen möchte und danach kann man die Daten lesen. Man ist also nach wie vor selbst für Einhaltung der Zeitabstände zwischen den Befehlen verantwortlich. Der Baustein nimmt einem also auch nur die richtige Serialisierung der Befehls-/Datensequenzen ab. Was dieser IC gegenüber dem DS2482 besser ist, das er Standardbefehlssequenzen wie Reset-1-Wire, ReadByte, WriteByte in einem Rutsch ausführen kann. Ebenso scheint er 1-Wiresearch zu beherrschen. Wenn er letzteres komplett macht, dann ist das wirklich ein Gewinn. Bauform B. schrieb: > und natürlich den DS2480B mit UART <-> 1-Wire Ja und auch dieser setzt am Ende nur die Befehlssequenzen um, d.h. ich sage ihm per RS2323 "sende über 1-Wire den Befehl xy". Die Behle in der richtigen Reihenfolge generieren muß ich auch hier selbst.
(prx) A. K. schrieb: > Ich hätte gedacht, dass man da nur die Wartezeit der Messung > berücksichtigen muss Das Timing der der Byteübertragung auf dem 1-Wirebus übernimmt er schon. Aber wie Du bemerkt hast die Wartezeit zwischen den Messungen, oder auch die Zeit zwischen den einzelnen Befehlen und die komplette Belehssequenz ist immer noch Deine Sache. Du muß sogar prüfen ob auf dem 1-Wirebus noch irgendwelche Aktivitäten sind bevor Du die nächste Aktion durchführst oder die Daten abrufst. Ist zwar kein Hexenwerk, da Du dafür nur per i2c einen Befehl senden mußt und dann das Register lesen mußt. Was die Bausteine übernehmen ist das Strongpullup bei parasitärer Speisung. Wenn der µC i2c anbietet macht sich das mit den genannten IC schon ganz gut, da man die Sequenzen nicht selber serialisieren muß. Um den i2c Kram muß man sich ja meist auch nicht kümmern, da es hierfür entsprechende Bibliotheken gibt, die es vereinfachen.
Zeno schrieb: > Das Ganze ist eigentlich sogar noch ein bischen > aufwändiger als wenn man den 1-Wirebus selbst ansprechen würde. Bis auf das "Problem", dass die I²C- / TWI-Schnittstelle bei vielen µC in Hardware vorhanden ist. One-Wire ist doch eher die Ausnahme.
STK500-Besitzer schrieb: > Zeno schrieb: >> Das Ganze ist eigentlich sogar noch ein bischen >> aufwändiger als wenn man den 1-Wirebus selbst ansprechen würde. > > Bis auf das "Problem", dass die I²C- / TWI-Schnittstelle bei vielen µC > in Hardware vorhanden ist. One-Wire ist doch eher die Ausnahme. Was ist an diesen 2 Sätzen so unverständlich? Zeno schrieb: > Wenn der µC i2c anbietet macht sich das mit den genannten IC schon ganz > gut, da man die Sequenzen nicht selber serialisieren muß. Um den i2c > Kram muß man sich ja meist auch nicht kümmern, da es hierfür > entsprechende Bibliotheken gibt, die es vereinfachen.
Uwe B. schrieb: > Bit-Banging geht nur mit gesperrten Interrupts, da sonst das Timing > gerne durcheinander kommt. Korrekt, aber das trifft nur eine Bitzeit von ca. 60-100us. Zwischen den Bits dürfen Interrupts reinfunken, es gibt keine obere Grenze. Das ist für die Mehrzahl der Anwendungen akzeptabel, incl. dem Linuxkernel! > Am einfachsten geht es mit der Ansteuerung > ueber UART. Nö, am einfachsten geht es definitionsgemäß mit einem beliebigen, digitalen IO-Pin. Das mit dem UART ist zwar nett, aber nicht zwingend. Und UNEINFACH, vulgo schwert oder schwierig ist One Wire wohl kaum! Das ist fast schon TRIVIAL! Erst recht, wenn man fertige Bibliotheken verwendet. Ich hatte "damals" zwar auch 2-3 Tage an der Funktion zum Scannen aller IDs gebastelt, aber am Ende hat es nicht nur gut funktioniert, es war auch überaschend einfacher Code. Naja, ein geklöstes Problem ist immer "einfach".
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.