Forum: Mikrocontroller und Digitale Elektronik 1Wire: Mehrere ID's über DS2480B


von Tobias W. (racer01014)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

SEARCH ROM [F0h]

Peter

von Tobias W. (racer01014)


Lesenswert?

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?

von Mario G. (mario)


Lesenswert?

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

von Tobias W. (racer01014)


Lesenswert?

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?

von Mario G. (mario)


Lesenswert?

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...

von Markus (Gast)


Lesenswert?

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!!!!

von Markus (Gast)


Lesenswert?

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!!!

von Tobias W. (racer01014)


Lesenswert?

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...

von Markus (Gast)


Lesenswert?

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

von Mario G. (mario)


Lesenswert?

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...

von Christian H. (netzwanze) Benutzerseite


Lesenswert?

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).

von Tobias W. (racer01014)


Lesenswert?

@ 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!

von Valeri K (Gast)


Lesenswert?

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

von nuk (Gast)


Lesenswert?

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...

von Brummbär (Gast)


Lesenswert?

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.

von Brummbär (Gast)


Lesenswert?

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.

von Valeri K (Gast)


Lesenswert?

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.

von wigor (Gast)


Lesenswert?

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.

von Falk B. (falk)


Lesenswert?

@ 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.

von Valeri K (Gast)


Lesenswert?

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.

von wigor (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Valeri K (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.