Manche Arduino-Anwendungen benötigen eine eindeutige Seriennummer. Besonders wenn man Arduinos vernetzt muss man die einzelnen Knoten eindeutig identifizieren können.
Dazu könne man eine solche eindeutige Seriennummer im Code fest einbauen oder im EEPROM ablegen. Das hat den Nachteil das man beim Austausch der Hardware bzw. beim Programmieren eines neuen Knotens im Netz die jeweilige Seriennummer immer manuell neu hinterlegen muss.
Ich verwende da jetzt den Temperatursensor DS1820. Der hat eine interne feste Seriennummer:
das ist also ein Tipp und keine Frage.
Die Idee finde ich gut. Wirklich.
Und wenn jemand keinen Dallas hat, der kann einen Portexpander ranhängen, 8 oder 16 Bit, an alle Eingänge Jumper bauen und damit eine Binäradresse einstellen. Das wäre dann komplett Programmunabhängig.
danke - deshalb hab ich sie hier gepostet. Als Anregung für Andere.
Doc_Arduino:
Und wenn jemand keinen Dallas hat, der kann einen Portexpander ranhängen, 8 oder 16 Bit, an alle Eingänge Jumper bauen und damit eine Binäradresse einstellen. Das wäre dann komplett Programmunabhängig.
geht auch
wenn man noch genügend Ports frei hat kann man sich den Portexpander sparen und z.B. mit drei Pins acht verschiedene Seriennummern fest verdrahten verlöten. Mit vier Pins kommt man auf 16.
Mit dem DS1820 reicht ein Pin um einen deutlich grösseren Nummernbereich für die Seriennummer zu erhalten.
Die wird dann aber nicht mehr von einem selbst sondern vom MAXIM bei der Herstellung des DS1820 festgelegt.
Ein Chip, der sagt dass er XYZ heißt und kostet 5€.
Jetzt kommt der Jürgen, knallt da nen TempSensor rein der auch XYZ heißt + Temperatur messen kann + nur 2€ kostet.
Und warum nicht noch komplizierter?
zB so:
#define XYZ
defines kann man im laufendem Sketch auch nicht ändern, man brauch den "Hardware Namen" auch nicht austauschen, dieser ist nämlich unkaputtbar.
Was ich aber als ein Problem sehe, wenn ich 2 TempSensoren verbaue und in 2 Jahren einen austauschen muss, dann muss ich entweder im Code die Namen ändern oder die TempSensoren vertauschen (was ganz kake ist, weil die Kabel dann zu kurz sind) oder ich hab Glück und des passt so.
Jetzt haben alle denselben Sketch drauf, lesen den Namen und schicken mir an die App, zB TempDaten.
Die App fragt nach, wer ist hier der Holger, gib mir mal die Daten damit ich die in die obere Ecke hinzaubern kann.
Jetzt ist der Holger aber gestorben, das heißt ich muss den Namen von dem neuem Kollegen herausfinden und dann der App erzählen dass der Holger die Welt verlassen hat und die soll ab jetzt bitte nicht den Holger fragen sondern die Matilde.
Und nun, was wäre einfacher, die App zu ändern oder den Sketch bei jedem Upload gleich anpassen, was dann ewig lebt.
Und wenn dann mal der Arduino tot ist, weiß man immer noch wie der Name im Sketch war, entweder die App fragen oder nen aufkleber auf den Arduino.
Hallo,
was ist hier denn so besonders? Das die Dinger ne´eigene ID haben steht doch in den Datenblättern.
Liest die denn keiner, obwohl immer darauf verwiesen wird? Hier wurde das auch schon angesprochen.
Gruß und Spaß
Andreas
was ist denn hier los? Also wenn jemand den Thread nicht gelesen hat, dann du Skoby. Leider.
Jürgen wollte nur nett auf eine Idee hinweisen. Mehr nicht. Dann kamen noch 2 weitere Alternativen hinzu.
Ich sehe kein Problem und keinen Widerspruch. Ich sehe nur 3 Möglichkeiten einer Art Seriennummer bzw. Adressierung. Genau wie Jürgen im letzten Post schreibt hatte ich sein Vorhaben verstanden.
SkobyMobil:
Hallo,
was ist hier denn so besonders?
nichts
Das die Dinger ne´eigene ID haben steht doch in den Datenblättern.
richtig
Liest die denn keiner, obwohl immer darauf verwiesen wird?
doch
Aber dort steht keine fertige Arduinofunktion die die Abfrage dieser ID vereinfacht.
Bitte entschuldige das ich für die Seriennnummer eine Funktion geschreiben und diese dann hier eingestellt habe. Falls es hier schon so was gepostet wurde bitte ich um Entschuldigung das ein altes Thema aufgewärmt habe.
Ich war bisher der Meinung das eine Community durch Beiträge der Teilnehmer lebt. Die Vielfalt macht sie dann interessant.
Auch eine banale Funktion kann für den einen oder anderen interessant sein.
uwefed:
Weil Du vieleicht jeden Arduino anders Flashen mußt. Bei einer HardwareID haben alle denselben Sketch drauf.
genau das hat mich genervt.
Ich will ein Bus-System auf RS-485-Basis aufbauen. Bisher hab ich da für jeden Knoten eine ID mit #define festgelegt.
Gerade bei der Entwicklung wo man auf dem Tisch mehrere Knoten liegen hat ist das bei einem Softwareupdate aufwendig jedes Mal die IDs manuell anzupassen.
Als mögliche Lösungen hatte ich u.A. folgende Optionen im Auge:
Hardware-ID z.B. mit vier Pins die durch Lötbrücken "programmiert" werden
Hardware-ID mit DIP-Schalter
ID im EEPROM ablegen
Seriennummer des DS1820 zu nutzen.
Da ich ich teilweise sowieso die Option mit der Temperaturmessung bei einigen Knoten möchte ist es für mich nicht allzuaufwendig jedem Knoten einen DS1820 zu spendieren. Die Dinger kosten ja nicht mehr viel.
Hier mal ein Beispiel wo ich ein TFT-Shield mit einem DS1820 nachgerüstet habe:
Der DS1820 ist zwischen dem Shield und dem TFT-Display platziert. Eine Temperaturmessung ergibt dann die Temperatur "innerhalb" des Gerätes.
skorpi08:
Und nun, was wäre einfacher, die App zu ändern oder den Sketch bei jedem Upload gleich anpassen, was dann ewig lebt.
genau das will ich nicht (mehr).
Wenn ich beispielsweise in meinem Hausbus 10 Knoten habe und dann mal ein Update machen mill muss ich jedesmal vor dem Hochladen den Sketch manuell ändern. Mit einem DS1820 spar ich mir das.
skorpi08:
Und wenn dann mal der Arduino tot ist, weiß man immer noch wie der Name im Sketch war, entweder die App fragen oder nen aufkleber auf den Arduino.
Dann löte ich entweder den DS1820 aus und verwende ihm im neuen Arduino oder ich nehm einfach einen neuen DS1820 und trage die neue Seriennummer beim Master ein.
Ich denke das ein Softwareupdate häufiger vorkommt als ein Austausch der Hardware.
Hmm....bei mir werden/sollen die Ardus über BT vernetzt werden. Haben diese nicht eine Art Mac-Adresse wie Netzwerkkarten? Wäre ja eindeutig genug. Man muss aber so oder so irgendwas fest einprogrammieren, da ich ja anhand der ID/Adresse oder sonst was z.B. den Bluetooth-Client Namen festlegen müsste. Geht ein BT-Modul kaputt (oder ein DSxxxx) muss der Code trotzdem angepasst werden. Hm..
Ansonsten wie man es früher gemacht hat mit Jumpern. Mit vier digitalen IO-Pins könnte man schon 16 Geräte adressieren, was in meinem Fall schon ausreicht (am besten die analogen Eingänge als digitale nehmen, wenn man sowieso nicht alle braucht - so hätte man immer die selben Pins). Das ganze ohne Extra-Kosten und direkt durchführbar. Die Software würde beim Start den Zustand der Pins auswerten und entsprechend Bluetooth-Namen und Softwaremodul ermitteln und ausführen.
Bei einem defekten Ardu muss der Nachfolger nur noch den Jumper des defekten drauf bekommen um direkt korrekt zu funktionieren. Finde ich iwie simpler..
Es gibt bestimmt viele Möglichkeiten, dies zu lösen.
Man kann auch mit Spannungsteilern an einem Analogpin arbeiten, da kann man bestimmt auch 10 Adressen sicher einstellen. Mit 2 Analogeingängen wären es schon 100. Und mehr Geräte mit demselben Sketch hat man bestimmt nicht im Heimbereich.
Man sollte im übrigen einen Tip nicht schlechtreden, nur weil man selbst das so nicht machen würde. Da aber eine grosse Firma für dieses Problem einen extra Chip designt hat und vertreibt, muss es doch viele Profis geben, die darauf setzen.
Somit kann sich jeder aus dem Thread die passende Lösung raussuchen.
Somit kann sich jeder aus dem Thread die passende Lösung raussuchen.
Das sehe ich auch so!
Und je nach Anwendung kann das lustig variieren ...
In einem Sensor Netzwerk habe ich es so gelöst, dass die Knoten ID im EEPROM steht. Und die DS-Dinger an jeden beliebigen Knoten gesteckt werden können.
Auch im Betrieb umgesteckt werden können.
Da haben die DS klare Namen bekommen (Zettelchen am Kabel).
Denn die blöde Nummer kann sich ja keiner merken.
z.B.:
Kühlwasser Temperatur 1
Öl Temperatur 1
Außen Temperatur 1
Außen Temperatur 2
Außen Temperatur 3
u.v.m.
Nur die Zentrale weiß um den Einsatzzweck jedes einzelnen Sensors.
Der Knoten selber weiß nix, außer den Pin, wo alle seine DS dran hängen.
Er scannt seine Sensoren, und teilt der Zentrale mit, welche DS IDs er gefunden hat.
Und welche Temperaturen da anliegen.
Der Zweck der Geschichte:
Jeder Mensch kann die Sensoren umverteilen, wie es gerade nötig ist.
Geht ein Knoten defekt, wird er einfach ersetzt.
Ist der Bus eines Knotens überfüllt, wird auf 2 Knoten verteilt.
Ohne jede Konfiguration.
Einzig ein Sensordefekt bedarf einer Sonderbehandlung.
Da muss dann einer aus der Entwicklungsabteilung einen neuen Sensor fertigen (z.B. Neuen Zettel ankleben, Stecker dran) und den Sensor in der DB austauschen. Eine Sache von wenigen Minuten.
](
