Hallo zusammen Ich kann jetzt über den Uart mittels Interrupt Zeichen senden. Ich benütze aber nur TxD und RxD. Wenn ich aber Befehle auf den AVR senden möchte die aus meheren Zeichen bestehen könnte es Probleme geben. Ich wenn ich den Befehl gesendet habe ein OK zurück oder ein ERROR. Also OK wenn befeh Verstanden Error wenn nicht. Da jedes Zeichen vom Befehl einzel kommen woher weiss ich wann der Befehl komplett angekommen ist. Muss ich das mit einem Timer arbeiten? Dass ich nach einem Bestimmten Timeout den Befehl als gesendet angschau und ihn prüfe? Oder gibt es andere Ansätze oder wie macht ihr das? MfG Peter
Ich nehme meistens Start- und Stopbyte und setze im IRQ Flags, die dann in der Hauptschleife entsprechend ausgewertet werden. Anstatt Stopbyte benutze ich manchmal auch einen Timeout, der im Timer-IRQ runtergezählt wird.
Am einfachsten ist es die Kommandos und Parameter als Text zu senden und mit "Enter" (0x0A oder 0x0D+0x0A) abzuschließen. Der Empfänger weiß dann, wenn das "Enter" sieht, daß ein Befehl komplett ist und kann ihn auswerten. Peter
Hi, du koenntest auch die Daten die gesendet werden als protokoll aufbauen. z.B. (Sender) startbit, adresse, command , laenge des Strings, stopbit. Mfg Dirk
Ich verwende folgendes Protokoll: - Anzahl Datenbyte (Wieviel Byte kommen noch) - Adresse (nur bei Bussystem wie RS485) - Befehlskennung - Daten - Checkbyte als XOR aller Daten Das erste Byte gibt an, wieviel Byte noch kommen, bis der Befehl komplett ist und mit der Adresse wird zB. bei einem RS485-Bus ein bestimmtes Slave-System angesprochen. Die Befehlskennung kennzeichnet den entsprechenden Befehl wie z.B. "W" für WriteEEPROM. Die Daten werden je nach Befehl gesendet. Zur Kontrolle der empfangen Daten diehnt das Checkbyte. Der Empfänger weiss so genau, wann ein Datensatz zu Ende ist ohne erst einen Timeout zu berücksichtigen. Dieser muss allerdings trotzdem eingebaut werden, da es ja auch zu Störungen kommen kann. Wird z.B. eine Störung als 0xFF erkannt würde der Controller ohne Timeout warten, bis 255 Zeichen empfangen wurden. Es können alle binären Daten gesendet werden, was bei der Kennzeichnung durch Start und Stoppbyte nicht möglich ist. Dadurch ist die Datenübertragung schneller wie im Klartext. Allerdings kann man die Applikation bei der Variante von Peter schnell mal mit einem Terminalprogramm testen, was bei meiner Variante nicht möglich ist. Steffen
hab nocheine: ich schiebe im emfangsinterrupt das in empf zeichen in einen Puffer (RAM), den ich durchschiebe (4Byte) kommt nun ein $0D (return) wird das in der dauerschleife erkannt und die interpretierung durchgeführt puffer 1 ist das 2te parameter puffer 2 ist das 3te parameter puffer 3 ist das command puffer 4 ist das Bestätigungszeichen $0D recht simpel gehalten und läuft bei mir gut. nur es gibt eben kein checkbyte, was aber auch nicht nötig ist, denn ein $0D als störung is unwarscheinlich und $0D ist auch niemals als befehlsbyte definiert
@Henning und was machst Du, wenn einer Deiner Parameter 0D ist oder du ein Byte nicht mitbekommst? Gruß Jörg
auf eine überprüfung, ob alles angekommen ist habe ich (bewust) verzichtet. aber an das 0D als parameter habe ich nicht gedacht... danke das muss ich wohl noch ändern, und darf nicht auf 0d reagieren, wenn das vorhergehende Byte auch ein 0d war. dann kann ich schonmal alle werte im Byte nach dem return senden. hmm, hab versucht das so klein wie möglich zu bekommen. und wenn man das befehlsbyte nach vorne stellt muss man das schon auswerten und darauf reagieren, wieviele optionen zu erwarten sind... oder die befehlslänge immer mitschicken... wohl doch nicht so einfach, wie ich gedacht hab :)
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.