Hallo! Ich möchte eine AVR-basierte Schaltung mit einem Linux Server verbinden. Die Schaltung beinhaltet ein LCD, Tasten, Sensoren und ein Piezo Element. Die Kommunikation soll sowohl vom Server (Bspw. LCD Update) als auch von der Schaltung (Bspw. Taster gedrückt) ausgehen können. Grundsätzlich hätte ich aber auch kein Problem mit Pollen. Was würdet ihr mir empfehlen, um eine zuverlässige bidirektionale Kommunikation zwischen Server und Schaltung zu ermöglichen? Die Verbindung soll so tolerant sein, dass auch beim Neustart von Server oder Schaltung eine Synchronisation wieder erfolgen kann. Der Server besitzt (nutzbar) nur USB Schnittstellen. Meine Idee wäre ein FT232 und dann der UART vom uC. Was meint ihr dazu? Wie bekomme ich den Sync hin, nachdem eines der Geräte out-of-sync ist (bspw. ungeplanter Neustart)? Danke im Voraus!
Peter E schrieb: > Der Server besitzt (nutzbar) nur USB Schnittstellen. Meine Idee wäre ein > FT232 und dann der UART vom uC. ist das nicht ein Widerspruch, UART ist nun mal asyncron http://de.wikipedia.org/wiki/Universal_Asynchronous_Receiver_Transmitter Peter E schrieb: > Wie bekomme ich den > Sync hin, nachdem eines der Geräte out-of-sync ist (bspw. ungeplanter > Neustart)? indem regelmäßig Uhrzeiten und Syncbytes ausgetauscht werden, ggffs. noch Onlinezeit nach erstem Sync?
Joachim B. schrieb: > ist das nicht ein Widerspruch, UART ist nun mal asyncron das ist möglicherweise ein Missverständnis. Ich weiß wofür das 'A' steht ;) Ich meine Folgendes: Der Server möchte Text auf dem LCD ausgeben. Er schickt dabei mehrere Befehle und den Payload an die Schaltung. Diese bekommt jedoch einen Teil nicht mit, vielleicht weil sie irgendwo festhängt und der Watchdog reagiert. Sie empfängt nun Datenbytes und interpretiert diese als Befehle, da das erste empfangene Byte möglicherweise dem gesendeten Byte 42 entspricht. Bei Syncbytes bin ich nicht sicher wie dies realisiert werden soll, ohne sämtliche Daten escapen zu müssen, um sie nicht versehentlich in den Nutzdaten, beispielsweise bei einem Firmware Update, welches binäre Daten enthält, zu verwenden.
Peter E schrieb: > Ich meine Folgendes: Der Server möchte Text auf dem LCD ausgeben. Er > schickt dabei mehrere Befehle und den Payload an die Schaltung. Diese > bekommt jedoch einen Teil nicht mit, vielleicht weil sie irgendwo > festhängt und der Watchdog reagiert. Sie empfängt nun Datenbytes und > interpretiert diese als Befehle, da das erste empfangene Byte > möglicherweise dem gesendeten Byte 42 entspricht. dann lasse die beiden sich doch die Hände schütteln, ich hatte das mal als abgewandelte IEEE mit 2 parallelen 8 Bit Kabel zwischen apple2 und PC1500 gebaut einer sendet ein Steuerwort (der Name deiner ersten Freundin und eine beliebige Zahl welches in dieser Folge kaum in Nutzdaten auftaucht) und Daten und Zeitstempel, der Empfänger spiegelt es zurück und erhält wenn es richtig empfangen wurde ein OK und gibt es erst dann auf dem LCD aus (vorausgesetzt die Zeitstempel liegen nicht meilenweit auseinander, dann könnte der verunsicherte ja noch mal nachfragen oder sich neu syncronisieren)
Peter E schrieb: > Ich meine Folgendes: Der Server möchte Text auf dem LCD ausgeben. Er > schickt dabei mehrere Befehle und den Payload an die Schaltung. Diese > bekommt jedoch einen Teil nicht mit, vielleicht weil sie irgendwo > festhängt und der Watchdog reagiert. Sie empfängt nun Datenbytes und > interpretiert diese als Befehle, da das erste empfangene Byte > möglicherweise dem gesendeten Byte 42 entspricht. Befehlsbyte vom Server: 0x01 bis 0x3F = Befehle die nicht bestatigt werden. 0x40 bis 0x7F = Befehle müssen bestätigt werden. Bestätigung vom Slave: Empfangenes Befehl mit bit 7 gesetzt, Payload ist berechnetes CRC. P.S. Bestätigung hat nichts mit Antwort zu tun, beantwortet wird, falls nötig, zusätzlich.
Da musst du dir halt ein Protokoll einfallen lassen, dass Datenverluste absichert. Google einfach mal CRC. Dann weis dein Empfänger, ob die Nachricht vollständig und richtig ist oder nicht. Wenns richtig war -> Befehl ausführen und ACK senden, wenn's falsch war nichts tun. Der Server schickt dann nach einem Timeout die Sachen nochmal. Zielführend ist sicher auch, wenn man die Statusleitungen der RS232-Schnittstelle verwendet.
Peter E schrieb: > Bei Syncbytes bin ich nicht sicher Wer bringt da bloss immer wieder Sync Bytes ins Spiel? Die gibt es bei Asynchron nicht, die werden bei synchroner Übertragung (SDLC,HDLC) vorausgeschickt - und dafür braucht man ein USART (mit S!). Asynchron schickt man zweckmässigerweise Records mit Startbyte, ev. Länge, Befehl, Daten, Prüfsumme, Endezeichen. Gültig ist die Übertragung erst, wenn alles von Start bis Ende empfangen ist und die Prüfsumme stimmt, sonst kommt eine Fehlermeldung zurück und die Übertragung muss überholt werden. Auf die Art kann es nicht passieren, dass Daten als Befehle missverstanden werden, und wenn man nicht binär, sondern Zahlen als ASCII-Text schickt, stellt sich auch die Frage nach dem Escapen garnicht erst. Ausserdem kann man mitlesen, das erleichtert sehr die Fehlersuche. Also z.B. STX TDies ist der Text Prüfsumme CR oder STX V-12,35 Prüfsumme CR T für Befehl Text, da gibt es nichts misszuverstehen: der Empfänger nimmt erst nach dem STX Zeichen an und speichert die, bis CR kommt. Jeder Record synchronisiert sich daher neu. V heisst Spannung, ist gleich -12,35 V. Georg
Georg schrieb: > Asynchron schickt man zweckmässigerweise Records mit Startbyte, ev. > Länge, Befehl, Daten, Prüfsumme, Endezeichen. Gültig ist die Übertragung > erst, wenn alles von Start bis Ende empfangen ist und die Prüfsumme > stimmt, sonst kommt eine Fehlermeldung zurück und die Übertragung muss > überholt werden Mein Problem ist, dass die Daten (zu) groß werden können. Möchte ich beispielsweise alle Pixel des LCDs aktualisieren, würde ich einen Befehl "Setze Pixel" mit Anzahl der Bytes abschicken und dann den entsprechenden Payload, also 1 Byte pro Pixel. Die Daten müssen allerdings direkt zum Display geschrieben werden, da der (verfügbare) RAM nicht ausreichen wird, die Daten lokal zwischenzuspeichern. Da Dein Ansatz für alle anderen Befehle gut funktioniert - gibt es für den LCD Fall vielleicht eine andere Möglichkeit?
Peter E schrieb: > Da Dein Ansatz für alle anderen Befehle gut funktioniert - gibt es für > den LCD Fall vielleicht eine andere Möglichkeit? Indem du die Pixel in Blöcke aufteilst von z.B. 32 Pixeln. Nach jedem Block erhält der Sender ein Acknowledge. Das gilt übrigens für jeden langen Datensatz. Und du sendest die Daten als ASCII. 0x3A sendest du als '3' und 'A' oder 'A' und '3', je nachdem, was dir besser gefällt. Also ein Byte, genau genommen Character, pro Nibble. mfg.
Thomas Eckmann schrieb: > Indem du die Pixel in Blöcke aufteilst von z.B. 32 Pixeln. Gute Idee, vielen Dank!
> vielleicht eine andere Möglichkeit? Was für eine? Welche Richtung? Wenn ein PC in den µC schreibt, und dieser µC zwischendurch den Strom verliert? Dann schreibt der PC eben weiter, ... ins Leere.... Und wenns die USB Leitung unterbricht, dann bekommt die Anwendung ein Signal vom OS. Alles kein Drama (glaube ich) .... Oder wenn der PC auf halben Weg abschmiert, dann wäre ein Timeout auf dem µC sinnvoll. Auch könnte man alle 32 Byte, oder so, eine Prüfsumme mitsenden. Dann sind die Blöcke nicht so groß. Und man kann bei Fehlern frühzeitig abbrechen. > Mein Problem ist, dass die Daten (zu) groß werden können. Kleinere Blöcke senden. Stückeln.
Georg schrieb: > Wer bringt da bloss immer wieder Sync Bytes ins Spiel? Die gibt es bei > Asynchron nicht, darf ich daran erinnern? Peter E schrieb: > Die > Verbindung soll so tolerant sein, dass auch beim Neustart von Server > oder Schaltung eine Synchronisation wieder erfolgen kann. also müssen beide schon wissen ob sie noch die gleiche Laufzeit haben, wenn einer resettet sollte der andere den Status schon mitbekommen, Sync Bytes ist vielleicht der falsche Ausdruck, nennen wir es absprechen ob beide noch im selben Universum unterwegs sind und nicht der eine von Popobacken redet der andere von kuchenbacken. Der PC weiss doch nicht ob der letzte gesendete und mit OK beantworte Status immer noch das aktuelle Bild auf dem LCD wiederspiegelt wenn der PC z.B. Ergänzungen schickt, oder man schreibt immer alle Daten neu.
Joachim B. schrieb: > Der PC weiss doch nicht ob der letzte gesendete und mit OK beantworte > Status immer noch das aktuelle Bild auf dem LCD wiederspiegelt Auch kein echtes Problem. Ich habe z.B. Messwertreihen auf dem PC gespeichert, die dieser vom Messgerät abgerufen hat, die waren schlicht und einfach nummeriert. Der PC hat die Daten abgerufen, die er in seiner Datei noch nicht hatte, das funktioniert mit tagelangen Ausfällen und selbst mit einem neuen Ersatz-PC. Etwas mehr Nachdenken bitte - das man grosse Datenmengen in Blöcken überträgt ist keine revolutionäre Neuerung. Datenrecords nummerieren oder mit Zeitstempel versehen auch nicht. Anzeigen würde ich nicht modifizieren, sondern regelmässig neu senden, wenn es sich nicht um ganze Grafiken handelt. Georg
Georg schrieb: > Auch kein echtes Problem. Ich habe z.B. Messwertreihen auf dem PC > gespeichert, die dieser vom Messgerät abgerufen hat, die waren schlicht > und einfach nummeriert. Der PC hat die Daten abgerufen, die er in seiner > Datei noch nicht hatte, das funktioniert mit tagelangen Ausfällen und > selbst mit einem neuen Ersatz-PC. stimmt Georg schrieb: > Etwas mehr Nachdenken bitte - das man grosse Datenmengen in Blöcken > überträgt ist keine revolutionäre Neuerung. Datenrecords nummerieren > oder mit Zeitstempel versehen auch nicht. das muss an den TO ist nicht meine Baustelle.
Joachim B. schrieb: > das muss an den TO ist nicht meine Baustelle. Klar, war auch für ihn, hätte mich deutlicher ausdrücken sollen. Georg
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.