Begriff mit Wert über Serial senden/empfangen

[combie]

Ich habe hier eigentlich die ganze Grammatik definiert,

Nein, ich sehe nur Programmcode.
Und dieser ist offensichtlich nicht korrekt, bzw. tut nicht das, was du willst.
Darum kann ich auch keine korrekte Grammatik daraus ableiten.

Folgendes wäre eine Definition, mit der man arbeiten könnte:
1. Verwendet wird der 7Bit ASCII Zeichensatz
2. Komma und Semikolon sind reserviert und dürfen nicht in den Daten vor kommen
3. Ein Datensatz besteht aus Bezeichner und Value.
4. Der Bezeichner darf maximal 20 Zeichen lang sein. Erlaubt sind alle Buchstaben des Zeichesatzes
5. Das Value entspricht dem Datentype int. Besteht aus den Zahlen 0 bis 9 und evtl Vorzeichen
6. Bezeichner und Value werden durch Komma getrennt
7. Ein Datensatz wird mit Semikolon abgeschlossen




Damit sind dieses 3 gültige Datensätze:

Code: [Select]

led,4;
frosch,42;
Zwiebelkuchen,-4711;


Der Vorteil:
Die gesendeten Daten sind für  Mensch und Maschine leicht lesbar und generierbar.


Um Datensätze dieses Musters zu generieren, eignet sich sprintf().
Um Datensätze dieses Musters zu parsen, eignet sich sscanf().

[stef308]

Also, ich versuche mal zu definieren:

- der 7bit ASCII Zeichensatz, klar - gibt es andere?
- Leerzeichen und Komma sind reserviert für Wertetrennung
- Ein Datensatz besteht wie Du vielleicht gesehen hast, im ersten Teil aus values (HEX) mit Leerzeichen getrennt und im zweiten Teil aus Bezeichner und value mit Komme getrennt. Daher geht sscanf() nicht so richtig.
- Mit der Switch/Case Abfrage bin ich auf einzelne Buchstaben und HEX beschränkt. Wörter habe ich ja versucht, funktioniet aber nicht.
- Values bestehen aus int, Zahlen 0-9 ohne Vorzeichen
- Datensatz wird bei mir einfach mit einer neuen Zeile abgeschlossen (Serial.println()). Spielt das eine Rolle? Ich hatte vorher mal ein Semikolon als Endzeichen drin, ist mir aber überflüssig vorgekommen.

[combie]

- der 7bit ASCII Zeichensatz, klar - gibt es andere?

Dutzende!

Daher geht sscanf() nicht so richtig.
- Mit der Switch/Case Abfrage bin ich auf einzelne Buchstaben und HEX beschränkt. Wörter habe ich ja versucht, funktioniet aber nicht.

Jammern gehört nicht in eine Definition.

- Datensatz wird bei mir einfach mit einer neuen Zeile abgeschlossen (Serial.println()). Spielt das eine Rolle? Ich hatte vorher mal ein Semikolon als Endzeichen drin, ist mir aber überflüssig vorgekommen.

Jammern gehört nicht in eine Definition.
Und wenn dir \n lieber ist, meine Sorge solls nicht sein.
Wobei ich "nicht darstellbare Zeichen" in solchen Formaten hasse wie die Pest.
Z.b. Tab und Leerzeichen sind leicht zu verwechseln.
Verschiedene Zeilenenden
Alte Mac: \r
Linux und neue Mac:\n
Windows: \r\n


Keine gültigen Beispiele angegeben.
Damit kann ich dann auch keinen Parser testen.

Warum sscanf() nicht funktioniert, hast du nicht begründet.

[stef308]

Mit jammern hat das wohl wenig zu tun....

Naja.

Beispiel:

Code: [Select]

0x7E 0x89 0x00 0x01 A,1023 B,825

Der Sendesketch funktioniert soweit ich das beurteilen kann, im Seriellen Monitor wird mit genau das angezeigt, einfach in Zahlenwerten wie z.B. für 0x7E = 126 oder 0x89 = 137. Beim Empfänger kommt auch was an, aber wie in Post

Das habe ich gemacht, aber dann bekomme ich noch komischere Werte eingelesen. Switch/Case funktioniert aber trotzdem nicht, erhalte die Werte nur am Stück eingelesen.

Hier mal die Ausgabe aus dem Seriellen Monitor:

Code: [Select]

serialBuffer = 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 137 0 1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 137 0 1 A,1A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 137 0 1 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 126 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0
serialBuffer = 126 26 137 0 1 A,1023 B,825

startDelimeter = 0
lengthByte = 0
apiIdentifier = 0
apiFrameId = 0
A = 0
B = 0


Das stimmt: serialBuffer = 126 137 0 1 A,1023 B,825, dann setzt er Werte ein die es nicht gibt oder macht Zusatzwerte in die Folge.

erwähnt, macht er zum Teil andere Werte hinein oder lässt sie weg. Das einordnen/parsen geht wohl nicht da immer 0 für alle Bezeichnungen ausgegeben wird.

sscanf(): Habe ich mir angeschaut und was versucht, doch da müssten ja immer die gleichen Trennzeichen vorhanden sein und gleiche Datenlänge, nicht? So habe ich das mal verstanden. Bei mir ist die Datenlänge nicht immer gleich und die Trennzeichen wie oben erwähnt...

[combie]

Also war deine Definition nicht korrekt/unvollständig!

> im ersten Teil aus values (HEX) mit Leerzeichen getrennt
Hier fehlt die Anzahl!
Ist die immer gleich?

>im zweiten Teil aus Bezeichner und value mit Komme getrennt.
Bezeichner immer Einbuchstabig?
Immer die gleiche Anzahl Paarungen?

Bitte..
Die Definition muss eineindeutig sein.

Mit jammern hat das wohl wenig zu tun....

Wer will, findet Wege.
Wer nicht will, findet Gründe.

Und diese Gründe kommen wie Jammern bei mir an.

[SkobyMobil]

Hallo,
"(fertige Alternativen interessieren dich nicht, oder?)"

Der hat sich an seinem Sketch festgebissen wie ein Terrier am Schienbein...

Bei der seriellen Kommunikation mit dem Arduino sind schon ganz andere untergegangen. Da sollte (muss) man (auch Frau)
bei Null anfangen.

"Wörter habe ich ja versucht, funktioniet aber nicht."
An diesem und anderem kann man dann sehen das hier nur probiert wird, was denn schon alles sagt.

Ich will hier ja nicht meckern, aber Stef- so läuft das nicht.
Was ist denn hiermit?
Das könnte vielleicht etwas hilfreich sein.
Tommy knallt Dir hier einen für die vollen rein, damit kommst Du nicht klar. combie läßt hier den AnfängerKurs raus, und den
plappers Du nur nach. Du scheinst zu wissen, was Du willst, hast aber keine Ahnung und noch viel weniger Konzept für Deinen Sketch.
Ich kann Dir nur raten da von vorne anzufangen.
Einen schönen Tag, noch!
Gruß und Spaß
Andreas
Ich habe da auch geblutet, weiß also tatsächlich mal wovon ich rede.

[stef308]

Erster Teil: Anzahl HEX Werte? Alle ein HEX Wert ausser einer wäre aus zwei HEX bestehend, habe ich hier aber mal weggelassen.

Zweiter Teil: Bezeichner immer Einbuchstabig, war mal so angedacht ja. Wie schon gesagt, wegen der Switch/Case anweisung geht ja nur Einbuchstabig...
Nein, es kann sowohl nur eine Paarung kommen, es können aber auch sieben Paarungen kommen die dann eingeordnet werden sollen.

[stef308]

@Andreas:
Ich schaue mir schon auch die Theorien an, aber dann muss man das ja auch "versuchen" umzusetzen.
Eine Switch/Case Variante mit Wörtern abzufragen ist mir nicht bewusst, dass es das gibt oder funktionieren sollte. Ich habs versucht, weil man darüber scheinbar nichts wirklich findet. Die Theorie sagt geht mit int oder char values. Also mache ich das so.
Mir ist schon klar, dass ich bei Null stehe, aber ich habe mit all diesen Beispielen schon einiges dazugelernt.

Was ist denn hiermit?

Ich habe mir da schon einiges durchgelesen und greif da auch immer mal wieder rein, wenn ich mir nicht sicher bin.

Von vorne anfangen ist ja schön und gut, aber komplett falsch kann ich nicht liegen, denn ich empfange immerhin fast die richtigen Werte. Noch nicht immer, aber fast. Ich sehe das einfach so, wenn es an einem "kleinen" Problem liegt, warum soll man dann einfach alles hinschmeissen und was anderes Anfangen?

[combie]

Dein Sender aus https://forum.arduino.cc/index.php?topic=594415.msg4044613#msg4044613

Sendet keine hexadezimal kodierten Zahlen.

Das Beispiel
>0x7E 0x89 0x00 0x01 A,1023 B,825
ist also falsch.
Weit ab von der Realität.

Erster Teil: Anzahl HEX Werte? Alle ein HEX Wert ausser einer wäre aus zwei HEX bestehend, habe ich hier aber mal weggelassen.

Das empfinde ich als unlogisch.
Verstehe ich nicht.
Wie, oder warum, was weglassen, was zur Grammatik gehört?

war mal so angedacht

Ah, ja...
Es gibt also keine Notwendigkeit das bescheuerte Format/Grammatik zu nutzen.
Du könntest dir auch was schöneres ausdenken....

Nein, es kann sowohl nur eine Paarung kommen, es können aber auch sieben Paarungen kommen die dann eingeordnet werden sollen.

Is klar...
Mal eben keine kleine Wichtigkeit vergessen zu erwähnen.
Versuche bitte nochmal die Grammatik klar auszuformulieren.

Solange ein solches (in deinem Kopf) Chaos herrscht, wird das nichts.
Solange können wir nicht erfolgreich kommunizieren
Weder wir beide, noch Sender mit Empfänger.

Eine Switch/Case Variante mit Wörtern abzufragen ist mir nicht bewusst, dass es das gibt oder funktionieren sollte. Ich habs versucht, weil man darüber scheinbar nichts wirklich findet.

Und wieder dieser ablenkende rückwärts gerichtete Blick/Begründung, den ich als Jammern empfinde.

[stef308]

Das habe ich mal weggelassen, weil ich den fürs auslesen am Empfänger nicht notwenigerweise brauche. Die Datenpaket-Länge wird in zwei HEX Werten ausgegeben was der Sender senden muss. Daher wären diese zwei Werte gleich eine Bezeichnung. Der Rest ist so wie beschrieben.

Es gibt also keine Notwendigkeit das bescheuerte Format/Grammatik zu nutzen.

Bescheuertes Format? Das ist doch egal, ob ich mit dem Sender A = 1 sende oder AllesGuteZumGeburtstag = 1. Der Empfänger speichert es ja dann in die richtig definierte Benamsung ab und sagt, wenn Teil A gefunden, speicher das gleich AllesGuteZumGeburtstag. Dann passt ja alles wieder, es muss nicht so viele Zeichen senden und mit Kommentaren kann ja alles dokumentiert werden.

Also:
Ich teile den Sendesketch der Taster und Joysticks dann so auf, dass ich, wenn sich der Joystick bewegt oder Knopf gedrückt wird, dann gesendet wird. Sonst nicht. Da kann es sein, dass nur 1 Signal rausgehen muss, oder auch mehrere gleichzeitig, z.B. x- und y-Achse der Joysticks. Wenn ich jetzt das ganze als Datenpaket senden muss, dann muss ich eine Reihenfolge aus Startwert, Datenlänge, Rückmeldebefehl und z.B. den x und y Werten einhalten. Da die Werte die ich da ins Paket packe nicht immer gleich sind, kann die Menge varieren. Ich hoffe man versteht es so besser.

[combie]

Die Datenpaket-Länge wird in zwei HEX Werten ausgegeben was der Sender senden muss.

Habe ich der eben schon versucht zu sagen!
Das tut dein Sender nicht.
Er sendet dezimale kodierte Zeichenketten.



Und:

Nein, die Definition ist noch nicht klar.

Mittlerweile dreht sichs um Joystick Positionen und Knöpfe.
Die Positionen können negativ und positiv werden. (denke ich mir mal so)
Knöpfe nicht.

Was  Rückmeldebefehl sein soll ist auch noch geheim.
Wie du Knöpfe übertragen willst auch.


Weiterhin verstehe ich nicht, warum du das so kompliziert machen willst.

Bescheuertes Format?

Ja!
Solange ich das nicht verstehe.
Solange du das nicht implementieren kannst.
Solange ist das für mich: Bescheuert/Unbrauchbar

Deine Salami Taktik macht es nicht besser.
Sie erzeugt so langsam Frust bei mir.

[stef308]

Ich hatte es mal auf "Serial.print(0x7E, HEX);" geändert. Dann sendet es doch HEX Werte? Das hat aber nicht geholfen, zumal mein einfacher Sketch am Anfang dieses Themas den HEX Wert in Switch erfolreich einliest und in den richtigen case ausgibt mit dem aktuellen Sendesketch von vorhin.

Nein! Habe ich doch schon geschrieben, die Werte die ausgegeben werden sind von 0 bis 1023, die Nullstellung des Joysticks liegt hier in der Mitte. Die Knöpfe/Taster senden nur Werte 0 oder 1 (HIGH oder LOW/gedrückt oder nicht) raus.

Der Rückmeldebefehl habe ich ebenfalls schon erwähnt. Das ist ein (nach Tabelle) HEX Wert, z.B. 0x01, der als vierter Wert mitgesendet werden kann/soll, damit ich eine Rückmeldung über den Empfangs-/Sendestatus erhalte. Dieser Wert muss ich dann gemäss Handbuch eingeben, hat aber immer dasselbe Format => HEX Wert.

Kompliziert, weil ich sonst keine Rückmeldung erhalte. Das Datenpaket muss eine gewisse Reihenfolge der Daten haben. Und eben an vierter Stelle steht dann der mitgesendete Befehl für den Empfänger, damit mir der eine Rückmeldung schickt. Beim Empfänger aber muss ich ja meine eigentlich gesendeten Daten wieder auslesen. Und dafür müsste ich dann die gesendeten Daten von Anfang an einordnen (wie mit switch/case angedacht) und sie zuweisen. Dann habe ich wieder Bezeichnung A = Wert 1, ect., worauf dann im eigentlichen Programmablauf zugegriffen werden kann um die Motoren einzuschalten, Lichter an/aus, ect..

Weniger kompliziert wäre eine Variante gewesen, bei der ich einfach meine Daten ganz normal mit Serial.write() und Serial.read() sende/empfange, aber dann muss ich über die AT Befehle gehen, damit ich eine Rückmeldung des Empfängers erhalte. Das wäre dann Serial.write(+++) damit man in die Oberfläche des Sendemoduls kommt, dann muss 1sek. gewartet werden, um dann den Befehl Serial.write(ATDB) zu senden. Dann kommt auch eine Rückmeldung, aber die Loop ist gestört und läuft zu langsam ab. Das Senden und Empfangen sollte am Besten nebenbei erfolgen, während die Loop mit den Befehlen (Motor an/aus, wenn eben der Wert 1 (gedrückt) des Taster reinkommt, dann mach das und das) ungestört (beinahe ungestört) weiterläuft.

Das ganze soll nur dafür dienen, dass ich bei Verbindungsabbruch der Sende- und Empfangsmodule einen letzten Befehl kurz vorher senden kann, dass alles ausgeschaltet wird, bevor die Verbindung weg ist.

Ich hoffe es ist nun klarer!

Grüsse

Stef

[Tommy56]

Solange Du nicht begreifen willst/kannst, dass Hexadezimal nur eine andere Darstellung der gleichen Zahl für die Nase vorm Monitor ist (0xff == 255 == B11111111), solange wirst Du Dich im Kreis bewegen und es nicht auf die Reihe bekommen.

Gruß Tommy

[stef308]

Ja, aus diesem Grund verstehe ich auch nicht so recht was Combie mit dem sagen möchte. Ich habe nur versucht das zu erklären, was ich gemacht habe/mache will.
Wenn die Werte so angegeben, oder so angegeben gesendet werden, dann werden sie doch eigentlich auch wieder "richtig" eingelesen?

[Tommy56]

Eben, weil Dir die Grundlagen dazu fehlen.

Serial.print(0x7E,HEX) sendet 2 Zeichen 7 und E
dagegen
Serial.write(0x7E) sendet ein Byte mit dem Wert B01111110 oder 126 oder 0x7E, was alles das gleiche ist.

Gruß Tommy