C Kommandos empfangen und verarbeiten?!
- Ersteller Janiiix3
- Erstellt am
TommyB
Team Bitschubse
Ist universell gewählt. In OSCAR werden z.B. mehrere TLV Pakete ineinander verschachtelt und die letzte Ebene gibt erst den echten Datentyp an. Sollte man so aber möglichst vermeiden. Es würde alles nur verkomplizieren. Außer natürlich wenn man komplexe Struct's übertragen will.
Aber es heißt ja auch Type (des Datenpaketes), nicht der Daten
Und klar, könnte man. Quasi TLVC, also die CRC hinten anhängen.
Aber es heißt ja auch Type (des Datenpaketes), nicht der Daten
Und klar, könnte man. Quasi TLVC, also die CRC hinten anhängen.
Sowas etwa meinte ich in Beitrag 4 (mit binär aufgebauten Kommandobytes). Da man selten 256 Kommandos (inklusive 0x00 als ignore/reset etc..) braucht, kann man bei Kommandos mit hinreichend geringem Parameterumfang die Parameter gleich ins Kommando miteinpacken. Zum Beispiel hier (wenn das Display hinreichend klein ist):
wenn es nur 127 horizontale Positionen gibt, könnte das Kommandobyte &B1xxxxxxx sein, mit sieben Bit für die Position. Entsprechend für die vertikale Position zb &B01xxxxxx mit sechs Bit (0..63) für die Position.
Trifft vielleicht nicht den Kern, aber ich habe eine Kommunikation zwischen 3 AVR mal so gelöst:
Master = Atmega8 und zwei Slaves = Tiny2313 über TxD/RxD (hier kam mal Dino's RS232- Bus- Ringsystem zum Tragen).
Der Master schickt immer 2 Byte: Das 1. Byte beinhaltet die Nr. des anzusprechenden Tiny (0000_0001 oder 0000_0010), das 2. dann den Code des abzuarbeitenden Kommandos; also 0000_0001 bis 1111_1111 (wenn man so viele braucht).
Die Tinys hatten dann ihre "Liste" , nach der sie die Befehle abarbeiteten (als Beispiel 0000_0111 mach dies, 1111_0000 mach das, usw.) Kam das Bestätigungsbyte 1000_0001 oder 1000_0010 zurück, machte der Mega8 weiter im Programm. Das ging recht schnell und fehlerfrei. Über Geschwindigkeit habe ich mir allerdigs noch nie Gedanken gemacht. Der µC verbringt eh die meißte Zeit mit warten...
Leider hab ich die Programme versemmelt (Crash) und die AVR mittlerweile überschrieben. Das könnte mir jetzt gut als Grundgerüst für meine MoBa- Steuerung dienen: Ein Raspberry mit Touchscreen soll Arbeit auf AVR verteilen bzw. Signale verarbeiten.
EDIT:
Mir fällt gad ein - ich müßte dazu irgendwo auch noch einen 44er mit entsprechendem Slave- Programm rumfliegen haben. Nütz mir aber nicht viel...
Master = Atmega8 und zwei Slaves = Tiny2313 über TxD/RxD (hier kam mal Dino's RS232- Bus- Ringsystem zum Tragen).
Der Master schickt immer 2 Byte: Das 1. Byte beinhaltet die Nr. des anzusprechenden Tiny (0000_0001 oder 0000_0010), das 2. dann den Code des abzuarbeitenden Kommandos; also 0000_0001 bis 1111_1111 (wenn man so viele braucht).
Die Tinys hatten dann ihre "Liste" , nach der sie die Befehle abarbeiteten (als Beispiel 0000_0111 mach dies, 1111_0000 mach das, usw.) Kam das Bestätigungsbyte 1000_0001 oder 1000_0010 zurück, machte der Mega8 weiter im Programm. Das ging recht schnell und fehlerfrei. Über Geschwindigkeit habe ich mir allerdigs noch nie Gedanken gemacht. Der µC verbringt eh die meißte Zeit mit warten...
Leider hab ich die Programme versemmelt (Crash) und die AVR mittlerweile überschrieben. Das könnte mir jetzt gut als Grundgerüst für meine MoBa- Steuerung dienen: Ein Raspberry mit Touchscreen soll Arbeit auf AVR verteilen bzw. Signale verarbeiten.
EDIT:
Mir fällt gad ein - ich müßte dazu irgendwo auch noch einen 44er mit entsprechendem Slave- Programm rumfliegen haben. Nütz mir aber nicht viel...
Zuletzt bearbeitet: