[TCP/IP] 20x4 LCD - Stringlaenge im Paket ?

Hallo zusammen,

muss auch hier das Textfeld im IP Paket immer eine Laenge von 20 Byte haben? Im Dokutext wird das Wort "maximum" gebraucht? Das wuerde mir sagen, der Textstring darf auch kuerzer sein. Auch das "Hello" ist ja kuerzer als 20 Zeichen.

Bitte um Info, ob das Feld kuerzer sein darf oder nach hinten mit "\x00" auf 20 Byte aufgefuellt werden muss.

Doku:

LCD20x4.write_line

    Function ID: 1

    Request: line – uint8

            position – uint8

            text – char[20]

vs.

The text can have a maximum of 20 characters. For example: (0, 7, “Hello”) will write Hello in the middle of the first line of the display.

Der Loetkolben

Mh, der String sollte entweder genau 20 Zeichen lang sein oder ein \0 am Ende haben.

Auffüllen ist mit der Momentan verwendeten Firmware auf den LCD Bricklets nicht notwendig, würde ich aber empfehlen. Vielleicht wird es mi der WIFI Extension notwendig werden das wir "Sanity Checks" einführen für TCP/IP Paketgrößen, die gibt es im Moment nicht.

An der Stelle merkt man das wir nur eine Dokumentation für alle Sprachen und TCP/IP haben, bei den Sprachen übernehmen die Bindings das Auffüllen.

Hallo borg,

danke fuer Antwort. Habe genau vor einer Minute mal mit dem Hai den Brickviewer getracet und da wird das Feld mit der Laegen 20 Byte uebertragen. Was mich so irritiert hat ist das Wort "maximal". Bei den Bindings verstehe ich das ja, aber bei TCP muesste es doch "Exact 20 Bytes" heissen.

Versendeter Text mit brickv : "TEST0123456789"

04:01:1a:00:00:00:54:45:53:54:30:31:32:33:34:35:36:37:38:39:00:00:00:00:00:00

04:01: = Init

1a:00: = 26 Bytes

00:00: = Position

54:45:53:54:30:31:32:33:34:35:36:37:38:39:00:00:00:00:00:00 = 20 Byte

wir "Sanity Checks" einführen für TCP/IP Paketgrößen, die gibt es im Moment nicht.

Oh ja bitte! Es kann sein, wenn ein Bit im Paket falsch ist, dass sich dann der Stapel aufhaengt oder sonstige Muelldaten liefert. Den Vorschlag wollte ich schon mal machen, aber ich glaube das ist recht viel Arbeit.

Auch ich tue mich schwer mit den Sachen. Danke fuer die Unterstuetzung.

Der Loetkolben

Cool... merkwürdigerweise funktioniert es bei meinen Tests mit diesen Hinweisen recht gut:

echo -n -e "\x02\x01\x13\00\x02\x00Test123456789" | nc -w1 localhost 4223

Da wäre ich alleine nie drauf gekommen!

Edit:Trotzdem irgendwie merkwürdiges verhalten

Hallo SierraX.

:WARNUNG: Mach es nicht!

Diesen Fehler habe ich bei Enumerierungsabfrage gemacht, wobei ich das der Feld der UID nur so weit genutzt habe wie die UID lang ist.

Das hat unschoene Seiteneffekte gehabt. Die eigentliche Abfrage mit der UID im kurzen Feld hat funktioniert, aber die naechsten Abfragen von anderen Bricklets haben dann gehangen.

Als ich dann das UID Feld mit \x00 auf 8 Bytes aufgefuellt habe, hat die eigentliche Abfrage weiterhin und auch die anderen Anfragen reibungs funktioniert!

Genaues im ersten und letzten Post von mir hier: [geloest] [TCP] Master Brick "Resolve UID" behindert Bricklet

Auch deshalb will Tinkerforge einen Sanitycheck einbauen! S.o.

Der Loetkolben.