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