Announcement: there is an English version of this forum on Hallo Leute, ich versuche gerade von mehrere 1Wire-IC's, die ID auszulesen. Realisieren möchte ich dies über einen 1-Wire zu RS232 Wandler ( DS2480B ) Ich habe momentan zwei Devices am 1Wire hängen: 1x DS2431 1x DS2413+ Solange nur einer der beiden Devices an der Leitung hängt, funktioniert das Code-Beispiel aus dem Datenblatt des DS2480B einwandfrei. Ich sende übers Terminalprogramm folgende Befehle: C1 E1 33 FF FF FF FF FF FF FF FF E3 C1 und erhalte die ID des Devices, so wie sich das gehört. Hängen jedoch beide Devices dran, kommt es wohl zu einer Datenkollision, da ich nur sinnlose Werte erhalte. Wie liest man nun die ID's nacheinander aus? Gibts da nen Trick? mfg
Danke Peter, habe es gerade ausprobiert und auch google damit gefüttert. Nun sollte man noch 16 bytes rausschieben, jedoch weiß ich nicht, was in den Bytes drinstehen soll, die rausgeschoben werden. Rückmeldung bei FF: A3 08 00 00 82 A2 80 80 08 00 00 00 00 00 00 AA Rückmeldung bei 00: 89 0A 08 A0 28 A2 20 00 00 00 00 00 00 00 08 88 Ist die Vorgehensweise so denn überhaupt korrekt?
Die Ermittlung der IDs ist keine einfache Angelegenheit bei OneWire. Besser ist es du kennst die IDs schon. Ansonsten gibt es schon AppNotes von Maxim: http://www.maxim-ic.com/app-notes/index.mvp/id/187
Die ID's muss ich leider im Nachhinein auslesen, sonst wärs ja einfach :-) Genau mit dieser AppNote von Maxim/Dallas schlag ich mich jetzt schon die letzten Tage rum, mit nur wenig Erfolg. Hat einer von euch das schonmal gemacht?
Ja, wo ist denn das Problem? Weiter unten auf der Website gibt es sogar eine komplette Beispielapplikation... Viel mehr als Copy&Paste ist da nicht mehr nötig...
Ich schließe mich meinem Vorredner an: Bei mehr als einem Device an de Leitung hilft nur ein Search-ROM-Befehl zum auslesen und dafür gibt es reichlich fertige (und funktionierende) Code-Examples beim Hersteller! Copy&Paste reicht vollkommen!!! Ansonsten sollte man sich erst einmal mit den genauen Abläufen auf dem Bus vertraut machen! Dieser produziert eine wired-AND-Verknüpfung und basiert praktisch auf dem Auftreten von Daten-Kollisionen! Viel Erfolg beim ausprobieren!!!!
Tobias W. schrieb: > ich versuche gerade von mehrere 1Wire-IC's, die ID auszulesen. > Realisieren möchte ich dies über einen 1-Wire zu RS232 Wandler ( DS2480B > ) > Ich habe momentan zwei Devices am 1Wire hängen: > 1x DS2431 > 1x DS2413+ Noch ein Tipp: Versuch als erstes, den Search-ROM Befehl (F0h) erstmal mit nur einem Device am Bus zum Laufen zu bringen! Wenn das schon nicht funzt, muss es and der Adaption des Codes liegen! Wobei, wie hier auch schon erwähnt wurde, kann man den eigentlich unverändert verwenden! Ich hoffe, du kriegst es zum Laufen!!!
Ich versuch es mal so zu formulieren: Ich brauch "nur" die Befehlsfolge, die ich an den ComPort schicken muss, um diese AND-Codefolge zu bekommen. Diese sollte ja 128bit lang sein? Was ich bisher versucht hab: Ich habe mir das Datenblatt des D2480B runtergeladen und mit dem Code-Beispiel auf Seite 11 probiert. Mir ist leider nicht klar, welchen Wert diese 16 Bytes haben müssen, die da rausgeschickt werden. Ein C-Programm hilft mir so leider nicht weiter, da ich die ganze Befehlsfolge für den COM-Port benötige. :-/ Ich werde wohl erstmal mit einem Device probieren. Ansonsten seh ich momentan kein Land...
Tobias W. schrieb: > Ein C-Programm hilft mir so leider nicht weiter, da ich die ganze > Befehlsfolge für den COM-Port benötige. :-/ Jetzt wird es kompliziert! Auf die Art, wie du es gerne machen würdest, habe ich mit den Adapter (Serial/USB->1-wire) noch nicht gearbeitet und kann dir deahalb nicht (Sofort) sagen wie die genau Zeichen-Folge auszusehen hat! Grundsätzlich gilt: Der ROM_Search erfordert Lese- Und Schreibzyklen. Der Read-befehl ist im Prinzip nichts anderes eine Write-1, auf die der Slave auf dem Bus antwortet. Um Das genau zu verstehen, hilft echt nur Lesen der genauen Spezifikation!!!!! Ansonsten meine Rat: Mach es in C und nimm die fertigen Programme von Dallas. Wenn du unter Windows Programmieren kannst (Visual Studio etc.), kopier die Dallas-Codes in ein neues Projekt (Ich benutze die TMEX-Driver-Version) und greife darüber auf deinen COM-Port zu. Das ist einfacher und auch besser nach zu vollziehen als "blind" die ASCCI-Zeichen zu senden. http://www.maxim-ic.com/products/ibutton/software/sdk/sdks.cfm Es geht bestimmt auch so, ist aber, so meine ich, letztendlich komplizierter, als ein bisschen Zeit in die Anpassung der Beispiel-Programme zu investieren Gruß, Markus
Nun mal nicht gleich das Korn in die Flinte werfen :) Wenn du dich nicht in die SEARCH_ROM Thematik einabeiten willst, wie wäre es denn damit: - stecke beide Devices einzeln und nacheinander an den Bus - ermittle für jedes Device nacheinander die GUID (READ_ROM) - jetzt kannst du die Geräte mit der richtigen GUID ansprechen (MATCH_ROM) so wärs einfacher...
Noch etwas zum Thema SEARCH ROM zur Identifikation bereits verbauter Sensoren. Hiermit bekommt man zwar die ROM-IDs, jedoch nicht den Einbauort. In den meisten Fällen ist eine Zuordnung der ID zum Einbauort notwendig. Hier bleibt einem nichts anderes übrig, die Sensoren entweder vorher einzeln zu identifizieren oder die eingebauten Sensoren schrittweise in das System einbindet (und so per SEARCH ROM die neue ID herauszufinden).
@ Markus: Ja, ich weiß, einfach ist anders, jedoch wollt ichs einfach mal probieren... Ich bin jetzt auch dazu über gegangen, mir mit dem Applikationsbeispiel ne .dll zu basteln, die ich dann benutzen kann. @ Mario: Genau das geht leider nicht. Die Devices sind SMD Bauteile, die bereits bestückt sind. :-/ Naja, ich werd jetzt zusehen, dass ich die .dll zum laufen bekomme. Als reines Terminalprogramm funktioniert es bereits! Danke für die Hilfe!
Hallo Tobias, ich programmiere Microchip PIC24F. Habe auch an das gleiche Problem gestoßen. Hast du schon eine Lösung gefunden? Die Beschreibung des DS2480B ist sehr schlecht. Endeffekt ist es nicht klar, welche Aufgaben übernimmt DS2480 beim Search-Lauf. Überall ist geklärt, dass Erkännung der ROM-Numb bitweise verläft. Laut Search-Flowchart von DS2480 muss ein Packet verschikt werden und danach Packet von 17 byte empfangen. Dieser wird analysiert, verarbeitet und dann weiter an DA2480 versendet. Wann ist die Ende des Prozesses. Die ROM-Nummer ist 64bit-Lang, muss ich 2^64 mal wiederholen? Glaube nicht. Ich habe auf einer polnischer Seite eine Lösung in C++ gefunden. Dort läuft Emittlung der Nummer bitweise. Was bedeutet dann command "Search Acceleration"? Vielleicht DS2480 ist überhaubt nicht nötig? Danke
Ich kenne jetzt den DS2480 nicht, aber ich fand die Appnote von Atmel wesentlich verständlicher: http://www.atmel.com/Images/Atmel-2579-Dallas-1Wire-Master-on-tinyAVR-and-megaAVR_ApplicationNote_AVR318.pdf > Die ROM-Nummer ist 64bit-Lang, muss ich 2^64 > mal wiederholen? Eigentlich nicht, man baut sich ja einen binären Baum mit den ID's auf. 2^64 ID's abzusuchen dürfte auch ziemlich lange dauern...
Die Arbitrierung der 1-Wire-Geräte am Bus erfolgt bitweise. Ein 1-Wire-Device sendet eine 1, indem es den Bus kurz auf LOW zieht und eine 0 indem es den Bus lange als LOW zieht. Würde ein Gerät eine 1 und ein anderes gleichzeitig eine 0 senden, so würde nur die 0 ankommen. Zuerst senden alle Geräte das erste Bit ihrer Geräte ID gleichzeitig auf dem Bus. Anschließend wird das erste Bit nocheinmal invertiert gesendet. Kommen beim Master zwei mal 0 an, so gibt es Geräte am Bus, die als erstes Bit eine 0 und eine 1 haben. Kommen beim Master 0 und 1 an, so gibt es nur Geräte am Bus, die eine 0 als erstes Bit haben. Bei 1 und 0 ist es umgekehrt. Kommt 1 und 1 zurück, hängt kein aktives Gerät am Bus. Nachdem das Bit auf diese Weite geprüft wurde, sendet der Master wiederum eine 0 oder eine 1 (je nach Fortschitt im Algorithmus). Darauf hin, werden sich alle Geräte deaktivieren, bei denen dieses Bit nicht diesem Wert entspricht. Für alle anderen Geräte wird nun mit dem nächsten Bit weiter gemacht. Auf diese Weise probiert der Master alle möglichen IDs durch und führt darüber eine Statistik. Im Endeffekt wird so eine Liste mit allen IDs am Bus aufgenommen. Valeri K schrieb: > Die ROM-Nummer ist 64bit-Lang, muss ich 2^64 mal wiederholen? > Glaube nicht. Doch, das ist wirklich so. Jedoch fallen bei der Arbitierierung einige Bitkombinationen automatisch raus, so dass nicht alles geprüft werden muss.
Hier wird der Algorithmus erklärt: https://www.maximintegrated.com/en/app-notes/index.mvp/id/187 nuk schrieb: > Eigentlich nicht, man baut sich ja einen binären Baum mit den ID's auf. Stimmt, das war der Ausdruck, der mit nicht einfiel.
Hallo Kollegen, es ist klar, wie das Search über einzelnen Bits funktioniert. Dieses Algorithmus kann ohne kontroller-DS2480B programmiert werden. Man kann theoretisch mit einem Pin des µC's die ganze Ermittlung durchführen. Bei mir auf dem UART-Bus sitzt DS2480B. Mein µC spricht nur mit ihm. Dieser hat verschiedene commands zu ausführen. Eine davon ist Search Accelerator Control. In der Appnote 192 (http://pdfserv.maximintegrated.com/en/an/AN192.pdf ) auf der Seite 13 Figure 7 gibt's OWSEARCH FLOW. Hier steht "Write the 22 byte packet and receive the 17 byte response". Für mich dies bedeutet, dass ich zuerst einen 22-Byte Packet mit 16-Byte search data byte konstruiren muss und an DS2480b versenden. Danach bekome ich 17-Byte responce, aus dem ich die ROM-Nummer des Dev's entziffern kann. Das ist doch nicht das bitweise Algorithmus, in dem ich einzelnen Bits direct und complement und discrepancy bearbeiten muss. Habe verschiedene Varianten ausprobiert, kriege keinen responce. Also es bleibt mir nichts anderes übrig als bitwese Algorithmus verwenden. Der DS2480B hat auch "Single Bit"-Command. Mit dieser kann ich bitweise direct- und complement-Bit ablesen und danach discrepancy ermitteln usw. Durch binären Baum bekome ich dann alle ROM_ID's. Thja, sehr aufwendigen Weg. Ich habe anders von DS2480B erwartet. Oder verstehe ich etwas nicht richtig? Danke.
Valeri K schrieb: > Für mich dies > bedeutet, dass ich zuerst einen 22-Byte Packet mit 16-Byte search data > byte konstruiren muss und an DS2480b versenden. Danach bekome ich > 17-Byte responce, aus dem ich die ROM-Nummer des Dev's entziffern kann. Ja. > Das ist doch nicht das bitweise Algorithmus, in dem ich einzelnen Bits > direct und complement und discrepancy bearbeiten muss. Jein. Den bitweisen Algorithmus macht der DS2480. Du musst einen richitgen Request zusammenbauen (S.14 Figure 8). Wenn ich das richtig verstehe, besteht der beim ersten Mal aus 128 '0'-Bits. Bei weiteren Versuchen werden die Bits bis zur ersten Diskrepanz verwendet (mit '0'-Bits dazwischen) und bei der ersten Diskrepanz wird das Richtungsbit auf '1' gesetzt. Alle nachfolgenden Bits sind wieder '0'. Als Antwort/response solltest Du wieder 16 Bytes (=128 Bits) bekommen, wo jeweils ein Bit eine mögliche Diskrepanz und das zweite Bit ein Stück vom ID-Code darstellen. Für mich sieht der DS2480 nach keiner echten Hilfe aus. Er verlangt zur Suche einen abgewandelten Algoritmus, der aber genauso komplex zu verstehen ist, wie der ursprüngliche Suchalgorithmus.
@ wigor (Gast) >Für mich sieht der DS2480 nach keiner echten Hilfe aus. Er verlangt zur >Suche einen abgewandelten Algoritmus, der aber genauso komplex zu >verstehen ist, wie der ursprüngliche Suchalgorithmus. Er ist eine Hilfe, um (Embedded)PCs und große uCs mit Linux etc. mit einem einfachen UART an OneWire zu koppeln, denn ohne einen GUTEN Echtzeitteiber kann ein PC kein derartig präzises Bit-Timing erzeugen. Alle höheren Logikfunktionen (Osi Layer 2 und mehr) muss der PC selber machen.
Danke wigor, so mache ich: req: E3 C1 resp: CD req: E1 F0 //"Search" resp: no req: E3 B1 //"Accelerator on" resp: no req: E1 00 00 00 .... 00 E3 A1 resp: no An dieser Stelle bin ich stehen geblieben. Weiter geht's nicht. Alerdings, 16mal 00...00(128bit)verstehe ich so,dass es nach ROM 00..00 (64bit) gesucht wird. Alle search_direction r = 0. Sollte DS2480 bitweisen Algorithmus übernehmen, dann schickt er mir die Stellen, an der er discrepancy(bit d) entdeckt hat und den zweiten Bit(bit r)(Figure 10). Bei nächstem Versuch muss ich 16Byte neu konstruiren und wieder an DS2480 senden. An den Stellen search_direction (bit r, Figure 8) setze ich 0 oder 1 abhängig von der Nummer, die ich suche. Die Frage: kann ich nur eine voraus bekannte Nummer suchen, oder die ganze Routine bringt mir alle Nummer, die am 1-Wire Bus sitzen? Naja, weiter ist schwierig. Ich muss sowieso zuerst erste responce bekommen. Danach wird einfacher. Danke für die Hilfe.
Angehängte Dateien:
-
DS2480_search_accelerator.png
100 KB -
DS2480_FSM.png
130 KB
Valeri K schrieb: > req: E1 F0 //"Search" > resp: no Laut Datenblatt müsste da schon ein F0 als Response kommen. Ich würde mal das erste E3 weglassen. Nach Reset ist er ja schon im Command mode. Wie schnell ist Deine UART-Schnittstelle? Hast Du ein Oszilloskop zur Hand? Wie ist Dein Aufbau? Alles auf Steckbrett?
Hallo Wigor, nun alles läuft wunderbar schön. zwischen jeden Sendebyte habe ich delay ca 100µS in ISR eingebaut. Nun alles ok. So schnell kann DS2480 nicht. Ich habe 10 St. von DS18B20 hinter dem DS2480. Ich sehe jetzt alle ROM_ID's. Muss nur 10mal Abfrage-Packet schicken, um die ID's zu bekommen. Alles OK! Danke für die Hilfe.
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.