mikrocontroller.net

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


Autor: Tobias W. (racer01014)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SEARCH ROM [F0h]

Peter

Autor: Tobias W. (racer01014)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: Tobias W. (racer01014)
Datum:

Bewertung
0 lesenswert
nicht 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?

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!!!!

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!!!

Autor: Tobias W. (racer01014)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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/...

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

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht 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...

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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).

Autor: Tobias W. (racer01014)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Valeri K (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: nuk (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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-1Wir...

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

Autor: Brummbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Brummbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier wird der Algorithmus erklärt:
https://www.maximintegrated.com/en/app-notes/index...

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.

Autor: Valeri K (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: wigor (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Valeri K (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: wigor (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht 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?

Autor: Valeri K (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.