ich werde in absehbarer Zeit ein Projekt starten, innerhalb dessen ein serieller Datenaustausch stattfinden soll. Das Ganze wird nichts zeitkritisches sein und die Menge der zu übertragenden Daten wird sich auch in Grenzen halten. Über die serielle Schnittstelle sollen z.B. Werte bestimmten Variablen zugewiesen werden können.
Da ich jetzt schon eine ganze Weile arduinotechnisch nichts mehr gemacht habe, habe ich folgende Frage:
Was wäre aus Eurer Sicht eine pragmatische Lösung? Gibt es evtl. hierfür eine sinnvolle Bibliothek, die mir die Programmierung eines eigenen Protokolls abnehmen könnte?
Was wäre aus Eurer Sicht eine pragmatische Lösung? Gibt es evtl. hierfür eine sinnvolle Bibliothek, die mir die Programmierung eines eigenen Protokolls abnehmen könnte?
Naja ... wenn die Daten wichtig sind (es darf nix fehlen oder verändert ankommen), muss man ein entsprechendes Handshake und eine Prüfsumme einsetzen. Wenn die Daten geheim sind, zusätzlich ver- und entschlüsseln.
Dazu braucht man aber nicht unbedingt eine wahnsinnig komplexe "Lib" (vlt. abgesehen von der Verschlüsselung, um das Fahhrad nicht neu zu erfinden) - für den Rest (Handshake und Prüfsumme) sollten jeweils einige zehn Zeilen selbst verfassten Codes völlig ausreichen.
Auf PC/Mac-Seite verwendest du eine Programmiersprache deiner Wahl (z.B. Python, Xojo, Processing, Delphi ...). Bliebe noch die Frage der Hardware. USB hat den Vorteil, dass die Stromversorgung gleich mit erledigt ist, ansonsten bevorzuge ich inzwischen LAN oder WLAN, da entfällt das Treiber-Gefrickel und man ist wirklich plattform-unabhängig ...
Das Ganze soll mit einer Kombination aus einem FTDI und einem Arduino Pro mini laufen und somit wie ein kleiner USB-Stick anmuten, der Berechnungen ausführen kann. Der Pro mini soll somit lediglich die Logik des Projektes beinhalten, während auf einer Softwareoberfläche (nicht Bestandteil meiner Frage) mit der Maus Tasten gedrückt werden können. Das drücken dieser Tasten soll dann den Pro mini zum Nachdenken veranlassen. Das Ergebnis würde er dann wieder seriell der Software mitteilen. Innerhalb der Software kann ich jedoch leider lediglich eine serielle Schnittstelle ansprechen und auf einmalig zu definierende entreffende Strings reagieren. Eine spezielle Prüfsummenlogik oder Handshakes o.ä. schließe ich somit von vorneherein aus.
Wenn ich mich nicht selber um Korrektheit oder Kollisionen kümmern will, würde ich auf CAN setzen.
Dem gebe ich meine (bis zu 8 Byte) Nutzdaten mit und Die kommen 'am anderen Ende' an - eigentlich an JEDEM Ende, jeder Teilnehmer empfängt ALLES und muß selber entscheiden, ob Das für Ihn wichtig ist - also Dein Programm.
Anders als bei anderen Protokollen wird hier aber nicht der Empfänger angesprochen, sondern jeder Teilnehmer hat Seine eigene(n) ID(s), aber jede ID gibt's nur 1x.
So kann jeder Empfänger selber entscheiden, ob Er von diesem Sender (diesem Sensor) was wissen will.
Teilnehmer, Die gar Nichts empfangen, melden auch kein Problem - wenn also EIN Empfänger die Daten korrekt erkannt hat (und eben KEINER ein Problem gesehen hat), ist die Sache für den Sender 'durch' - es gibt hier keinen expliziten Empfänger, sondern nur eindeutige Sender (Wobei, wie bereits geschrieben, beliebig viele IDs von jedem Teilnehmer benutzt werden können, also z.B. Eine für die Temperatur, Eine für den Luftdruck, ...., und bei zwei identischen Teilnehmern müssen sich hier, so viel zu identisch ;), die IDs unterscheiden, sonst kann der CAN-Bus sich aufhängen (Kollisionserkennung schlägt fehl, Die basiert auf verschiedenen IDs, je Kleiner, desto höhere Priorität).
Ist aber auch schon ein/zwei Tage her, daß ich mich aktiv mit CAN beschäftigt habe, habe bestimmt noch 'was' vergessen ...
postmaster-ino:
... habe bestimmt noch 'was' vergessen ...
Da es sich um eine Punkt-zu-Punkt-Verbindung, also keinen Bus handelt, dürften die vergessenen Punkte kaum relevant sein. Auch bin ich trotz meiner positiven Erfahrungen mit dem CanBus nicht so überzeugt, daß der bei diesem Thema die richtige Empfehlung ist. Bei hohem Datendurchsatz, großer Datensicherheit bei großen Entfernungen sähe ich das anders.
Weder hoher Datendurchsatz, noch große Entfernungen sin gefordert. Funktionierten sollte es aber trotzdem natürlich schon.
Ich teste momentan noch den cmdMessenger und frage mich, ob man den evtl. so anpassen kann, dass er z.B. aus folgendem eingehenden seriellen Befehl die anfängliche Bezeichnung, gefolgt von den einzelnen Zahlen differenzieren kann:
priority,1,1,2,4
Mich stört beim cmdMessenger, dass die Cmd Id einfach nur ein Integer zu sein scheint und kein "Klartextbefehl". Falls das mit dem cmdMessenger nicht gehen sollte, bliebe nur der Eigenbau, oder fällt Euch sonst evtl. noch was Passenderes ein?
Ich tu mich mit den Erklärungen zum cmdMessenger im Playground zugegebenermaßen etwas schwer.
es ist nicht so, dass ich den cmdMessenger nicht nutzen will. Wenn ein Projekt bei mir am anlaufen ist, ändern sich u.U. permanent die Rahmenbedingungen. Das ist in auch in diesem Fall so. Der Hinweis im Bezug auf "Parser" war jedenfalls zielführend, da ich diesen Begriff zwar in der Vergangeheit mal gehört hatte, er mir jedoch wieder "entflogen" war.
Ich werd also mal im Netz rumstöbern, was sich so findet.
Die in Deiner letzten Antwort aus meiner Sicht leicht mitschwingende Ironie sei Dir gegönnt.
Gute Frage. In diesem Fall ja. Klartextbefehle sollen es einer dritten Person erleichtern, den Arduino zu "konfigurieren".
Wenn z.B. ein "save,1,5" das Preset 1 auf Position 5 speichern soll, geht das leichter von der Hand, wie wenn diese (u.U. unbedarfte) Person anstatt dessen "7,1,5;" eingeben muss.
Da Du für die "unbedarften" Personen die Bedienung/Konfiguration sowieso dokumentieren musst (woher soll der sonst wissen, was die 1 und die 5 bedeuten?), kannst Du auch eine Tabelle mit den numerischen ID und den inhaltlichen Befehlen beilegen.
Gute Frage. In diesem Fall ja. Klartextbefehle sollen es einer dritten Person erleichtern, den Arduino zu "konfigurieren".
Ich bevorzuge als Mittelding einbuchstabige Befehle mit numerischen Parametern S1,5<newline> in diesem Beispiel.
Ein Buchstabe 'S' kann genauso leicht wie eine Ziffer erkannt und in einem if oder switch verwendet werden, und ist etwas leichter les- und erinnerbar für Menschen. Für "Unbedarfte" braucht man Dokumentation genauso für "save" wie für 'S'. Mit etwas Phantasie und nicht zu umfangreichem Befehlsumfang reicht 1 Buchstabe leicht.