Suche Lösungsansatz zum Senden von Befehlen

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.

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

Hi!

Echo des AVR in Verbindung mit Break vom PC bei Fehler wäre noch eine
Variante.

MFG Uwe

Hallo

Danke für die vielen guten Ideen

Gruss

Peter

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

puffer 3 ist natrülich der 1ste parameter, sorry

@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 :)