Hallo Zusammen,
Ich versuche gerade ein eigenes Protokoll zum Kommunizieren mit einem
XMC4700 Mikrocontroller zu schreiben ( als totaler newbie).
Ich werde Strom und Zeit Werten zum µC schicken und entsprechen wuerde
ich in beiden Richtungen Feedback bekommen.
Ich war gerade beim recherchieren und habe gesehen, dass in der ASCII
Tabelle die ersten 32 Zeichen Kontrollzeichen sind mit unter anderem
Gruppen Separatoren.
Da ich nicht sicher bin, dass ich es richtig verstanden habe, frage ich:
könnte ich die Zeichen zum Trennen meiner Daten bekommen ? wenn ja ,
vielleicht ein konkretes Beispiel?
Für mich waren immer STX immer drei unterschiedliche Zeichen daher war
ich verwirrt, aber könnte ich dann im µC folgendes schreiben?:
1
char(oderuint8_t)x;
2
3
if(x="STX"){
4
.....
5
6
}
Versteht mein µC ein Zeichen wie Unit separator ("US", 0x1F) oder
acknowlage ("ACk", 0x06) als solches oder soll ich die Prozedur dazu
schreiben?
ich schreibe die PC Seite vom programm in VBA. Schreibe ich dann :
1
serialport.output = "STX"
Mir ist es bewusst, dass es sehr Beginner Fragen sind. Die sind aber
nicht so Intuitiv, zumindest in meinem Fall:)
Falls jemand so was ( Kommunikationsprotokoll für serielle
Schnittstelle) mal gemacht hat, wäre ich sehr dankbar für einen
Beispiel!
Danke!!
Der MC erkennt von sich aus überhaupt keine Steuerzeichen, dass muss
immer die Software machen.
"STX" sind tatsächlich 3 Zeichen
#define STX 0x02
if (x==STX)
{
}
Nesrine G. schrieb:> Für mich waren immer STX immer drei unterschiedliche Zeichen daher war
STX ist nur die Bezeichnung des Steuerzeichens und steht für die Zahl 2,
ebenso wie CR (Carriage return) auch nur eine Bezeichnung ist und für
die Zahl 0xd steht
Nesrine G. schrieb:> ich werde meine Steuerzeichen entsprechend definieren.
Ja, das ist schon mal ein guter Ansatz, du darfst nur keine Daten binär
senden, denn damit man das Protokoll anhand der Steuerzeichen auswerten
kann (z.B. Start = STX, Ende = ETX), dürfen diese in den Daten nicht
vorkommen. Also Daten nur mit lesbaren ASCII-Zeichen, im Klartext: nicht
ein Byte 0xFF senden, sondern "255". Ist zum Fehlerfinden sowieso besser
wenn die Übertragung lesbar ist. Dass das etwas mehr Daten sind spielt
praktisch nie eine Rolle.
Georg
Hallo Nesrine,
habe gerade ein ganz einfaches DFÜ-Programm geschrieben, leider nicht
für deinen Prozessor sondern für einen uralten 8085 (8Bit-CPU), das
Prinzip ist aber ähnlich.
wie Georg anmerkte übertrage ich auch nur ASCII-Zeichen in meinem Fall
als Intel-Hex Format. Der Übertragungsweg ist mit Hardware Handshake
RTS/CTS abgesichert da der alte Rechner nur mit 3MHz läuft, sonst würde
er sofort überrannt.
Anschließend müssen die Daten, also die Intel-Hex Zeilen noch
entsprechend Interpretiert werden. Im Intel-Hex Format ist eine
Prüfsumme pro Zeile enthalten, so sind Übertragungsfehler weitestgehend
abgedekt.
Der Bootloader für den ATMEGA macht das so ähnlich, gibt es sicherlich
auch für deine CPU.
Es gibt natürlich bessere Übertragungsprotokolle X-Z-Modem oder Kermit,
diese brauchen aber auf beiden Seiten die Protokollunterstützung,
auf dem PC ist das ja kein Problem da die gängigen Terminalprogramme
alles an Board haben, auf der Mikrokontrollerseite ist das aber schon
eine größere Herausforderung ...
LG Werner
http://werners-seiten.de/index.html
Georg schrieb:> Nesrine G. schrieb:>> ich werde meine Steuerzeichen entsprechend definieren.>> Ja, das ist schon mal ein guter Ansatz, du darfst nur keine Daten binär> senden, denn damit man das Protokoll anhand der Steuerzeichen auswerten> kann (z.B. Start = STX, Ende = ETX), dürfen diese in den Daten nicht> vorkommen. Also Daten nur mit lesbaren ASCII-Zeichen, im Klartext: nicht> ein Byte 0xFF senden, sondern "255". Ist zum Fehlerfinden sowieso besser> wenn die Übertragung lesbar ist. Dass das etwas mehr Daten sind spielt> praktisch nie eine Rolle.>> Georg
Danke Georg ,
das genau habe ich mir auch überlegt. Davor hatte ich die Kommunikation
binär definiert. Ich hatte geplant die einzelnen Werte ( Strom und
Zeit), die ich senden wollte, mit der getbytes() Methode in VBA zu
senden. Aber die Kommunikation mit ASCII Zeichen zu gestalten ist
definitiv besser um die Daten zu erkennen. Dafür wird es aber viel mehr
Speicher brauchen, ich werde wahrscheinlich einen FIFO implementieren
müssen.
Danke nochmal!
Danke!
Werner R. schrieb:> Hallo Nesrine,>
Hallo Werner,
> habe gerade ein ganz einfaches DFÜ-Programm geschrieben, leider nicht> für deinen Prozessor sondern für einen uralten 8085 (8Bit-CPU), das> Prinzip ist aber ähnlich.>> wie Georg anmerkte übertrage ich auch nur ASCII-Zeichen in meinem Fall> als Intel-Hex Format. Der Übertragungsweg ist mit Hardware Handshake> RTS/CTS abgesichert da der alte Rechner nur mit 3MHz läuft, sonst würde> er sofort überrannt.
Ich habe noch nie mit dem Format gearbeitet, ich schaue nach was es auf
sich hat, vielleicht ist es für meine Bedürfnisse besser geeignet :)
>> Anschließend müssen die Daten, also die Intel-Hex Zeilen noch> entsprechend Interpretiert werden. Im Intel-Hex Format ist eine> Prüfsumme pro Zeile enthalten, so sind Übertragungsfehler weitestgehend> abgedekt.>> Der Bootloader für den ATMEGA macht das so ähnlich, gibt es sicherlich> auch für deine CPU.
Sorry was meinst du damit ? (bitte nicht an meinem Unwissen
verzweifeln!:))
>> Es gibt natürlich bessere Übertragungsprotokolle X-Z-Modem oder Kermit,> diese brauchen aber auf beiden Seiten die Protokollunterstützung,> auf dem PC ist das ja kein Problem da die gängigen Terminalprogramme> alles an Board haben, auf der Mikrokontrollerseite ist das aber schon> eine größere Herausforderung ...
Also von der PC Seite werde ich eine Windows Application in vba oder
vb.net schreiben in VBA 2010 express. In dem XMC werde ich natürlich die
Funktionen entsprechend den geschickten Nachrichten aufteilen und
erkennen. Meinst du das?
Danke! ich schaue mir gleich dein Projekt an.
>> LG Werner> http://werners-seiten.de/index.html
Basti schrieb:> such doch mal nach "byte stuffing"! Dann kannst du auch Daten binär> senden und was du möchtest. Ist auch nicht schwer zu implementieren.>> VG>> Basti
Danke Basti,
Ich habe dieses Link gefunden:
http://rn-wissen.de/wiki/index.php?title=Bascom_UART_Input
Es hat mir geholfen ein besseres Verstaendnis zu haben.
Das auch fand ich super. Es ist zwar fuer Arduino aber die Denkweise
hilft eine Beginnerin wie ich ziemlich viel:
http://forum.arduino.cc/index.php?topic=396450
Viele Protokolle verwenden den ganz normalen Zeilenumbruch, um das Ende
der aktuellen Sequenz zu signalisieren.
Sehr sinnvoll wenn diese in "lesbarer" Form übertragen werden.
Sehr sinnvoll, wenn die Längen der Sequenzen unterschiedlich sind. So
können z.B. 0 (1 Zeichen) gefolgt von einem Zeilenumbruch und 0.2 (3
Zeichen) ebenfalls gefolgt von einem Zeilenumbruch, jederzeit separiert
werden. Auch wenn die tatsächliche Sequenz: '0' '\n' '0' '.' '2' '\n'
ist.
Sehr sinnvoll, wenn man so nebenher überprüfen will, ob das System
funktioniert. Dann ist eine lesbare Zeile, ein Datensatz.
Werden "echte" Binärdaten (0 dez ... 255 dez) übertragen, so sieht die
Sache schon ganz anders aus.
Hallo Nesrine,
OK, mein Lösungsansatz ist schon etwas "speziell".
Wie auch Georg anmerkte, erster Weg nur ASCII-Zeichen also Text
übertragen.
Auf der PC-Seite reicht dafür ein einfaches Terminalprogramm.
Im Microcontroller würde ich erstmal das empfangene Zeichen als Echo
wieder zum PC zurücksenden. Hier zeigt sich ob die V24-Schnittstelle
mitspielt, normalerweise reicht eine Dreidrahtverbindung
PC<-->Controller, also Sende- (TX) / Empfangsleitung (RX) und Masse aus.
Bei meinem lahmen 8085 waren die Handshakeleitungen RTS/CTS erforderlich
also Hardwarehandshake.
Beim Softwarehandshake XON/XOFF muss der Controller zuerst XON senden
(11h bzw ASCII DC1). Der PC startet nun die Datenübertragung. Nach dem
Empfang bzw. zur Weiterverarbeitung muss der Controller mit XOFF (13h
bzw. ASCII DC3) den Sender (PC) anhalten.
Alle anderen Protokolle bauen darauf auf...
Mit der Anregung von Basti gehen auch Binärdaten, dort wird jedes Byte
in zwei ASCII-Zeichen zerlegt, übertragen und beim Empfänger wieder
zusammengebaut.
So ähnlich ist das mit dem Intel-Hex Code auch.
Hier wird eine Startmarke, erzeugt, Adressdaten (wo das Programm später
ausgeführt wird), Anzahl der Datenbytes, die eigendlichen Binärdaten
(als ASCII) dazu Prüfsumme und schließlich mit RETURN und LineFeed
abgeschlossen. Das macht der Assembler aber alles automatisch, nur im
Empfänger muss wieder auseinandergedröselt und ein Programm daraus
werden...
Hoffe das ich mich einigermaßen verständlich ausgedrückt habe.
LG Werner
Amateur schrieb:> Viele Protokolle verwenden den ganz normalen Zeilenumbruch, um das Ende> der aktuellen Sequenz zu signalisieren.>> Sehr sinnvoll wenn diese in "lesbarer" Form übertragen werden.> Sehr sinnvoll, wenn die Längen der Sequenzen unterschiedlich sind. So> können z.B. 0 (1 Zeichen) gefolgt von einem Zeilenumbruch und 0.2 (3> Zeichen) ebenfalls gefolgt von einem Zeilenumbruch, jederzeit separiert> werden. Auch wenn die tatsächliche Sequenz: '0' '\n' '0' '.' '2' '\n'> ist.> Sehr sinnvoll, wenn man so nebenher überprüfen will, ob das System> funktioniert. Dann ist eine lesbare Zeile, ein Datensatz.>> Werden "echte" Binärdaten (0 dez ... 255 dez) übertragen, so sieht die> Sache schon ganz anders aus.
Ja Das ist für mich gerade auch der Hauptgrund warum ich auf lesbare
Zeichen umstelle.
Meine längsten Nachrichten werden ungefähr so sein :
1
<Command><Board Nbr><Anzahl Werte> dann wiederholt :<Stromwert>Zeitwert><Index in der Sequenz>
Ich werde also mehrere "Trennzeichen" (TZ) benutzen" :
- Anfang/Ende Kommunukation
- Trennung Strom, Zeit, und Indexwerte.
Ein FIFO ist eine sehr einfache Struktur, zu der es auch genügend,
praktisch fehlerfreie Implementationen gibt.
... aber. Wenn Input und Abholung nicht übereinstimmen, läuft dieser
auch irgendwann über. Meist nicht während der Testphase!
Viele Stapel fragen dies erst gar nicht ab und viele Anwender machen das
Gleiche.
Thread beobachten
Seitenaufteilung abschalten