Loetkolben Posted June 3, 2012 at 02:36 PM Share Posted June 3, 2012 at 02:36 PM 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 Quote Link to comment Share on other sites More sharing options...
borg Posted June 3, 2012 at 05:04 PM Share Posted June 3, 2012 at 05:04 PM 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. Quote Link to comment Share on other sites More sharing options...
Loetkolben Posted June 3, 2012 at 05:13 PM Author Share Posted June 3, 2012 at 05:13 PM 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 Quote Link to comment Share on other sites More sharing options...
SierraX Posted June 4, 2012 at 12:09 PM Share Posted June 4, 2012 at 12:09 PM 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 Quote Link to comment Share on other sites More sharing options...
Loetkolben Posted June 4, 2012 at 03:55 PM Author Share Posted June 4, 2012 at 03:55 PM 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.