RS232 Baudrate bestimmen

Was machst genau?

Mit 7 bittigen Dingern kriegs nie Klartext auffm Terminalschirm.

w.

hwabnig@ .- --- -. dotat schrieb:

Verdammt noch mal, Recht hast du.

Ich habe eigentlich angenommen, dass die Bits schon automatisch von Linux ge-un-stufft werden, also dass dann halt in einem Byte eben bei einer 7-Bit-Übertragung immer das MSB Null ist. Pustekuchen.

Das muss ich selber machen. Und nachdem ich ein bischen rumgefrickelt habe, bekomme ich jetzt wenigstens auch Ergebnisse, die stabil sind. Aber das was rauskommen soll, kommt nicht raus. Werden da eigentlich die Stoppbits mit in den Datenstrom eingebettet, also muss ich je 9 Bit zu einem Byte konvertieren oder 7 Bit?

Und ist RS232 MSB first oder LSB first? Ich habe im Netz sowohl als auch gefunden.

Viele Grüße, Johannes

Johannes Bauer schrieb:

Sollte ein anständiges Terminalprogramm nicht genau das machen?

Christian

Christian Zietz schrieb:

Ja, aber ich benutze kein Terminalprogramm, sondern schreibe C-Code. Hab gedacht, dass es da vielleicht bei tcsetattr(3) etwas entsprechendes gibt, aber entweder ich habs übersehen oder man muss es tatsächlich selber machen. Jetzt pfriemel ich gerade ein bischen rum und guck wie viele Bits da denn wirklich Daten sind und wo der Schrott liegt.

Viele Grüße, Johannes

Johannes Bauer schrieb:

... CSIZE Character size mask. Values are CS5, CS6, CS7, or CS8.

Sollte reichen.

Falk

Falk Willberg schrieb:

Nö, auch wenn ich die Maske auf die 7 Bit setze, sind die MSBs der empfangenen Bytes trotzdem manchmal 1. Oder muss ich da nicht angeben, wie der Sender es überträgt, sondern wie ich es empfangen will? Kann ich mir eigentlich nicht vorstellen. Na Versuch macht kluch.

Falk Willberg schrieb:

Gerade nocheinmal ausprobiert, nein, es reicht definitiv nicht. Wenn ich hier CS8 angebe, kommt völliger Murks raus. Wenn ich CS7 angebe werden die empfangenen Bits verlustfrei (also ohne Verschnitt) auf Oktetten abgebildet. Das heißt also ich muss wirklich erstmal 7 Bytes abwarten und die dann zu 8 Bytes konvertieren. Nervig. Eventuell muss ich auch 9 Bytes zu 8 Bytes konvertieren, wenn die noch die Stoppbits reingeschnippelt haben (glaube ich aber nicht) bzw. die Parität.

Das ist sehr grenzwertig und keine schöne Aufgabe.

Viele Grüße, Johannes

Johannes Bauer schrieb:

Ich nehme alles zurück: c_oflags....

Aber "manchmal 1" klingt so, als wäre das das parity-bit, das als bit7 ausgegeben wird...

Erwartest Du binäre Daten oder wenigstens teilw. ASCII?

Falk

Falk Willberg schrieb:

Hm, möglich... Ich versuche mal ISTRIP.

Binär. Am Ende jeder Zeile allerdings trotzdem ein \r\n (darauf synchronisiere ich...)

Viele Grüße, Johannes

Falk Willberg schrieb:

Ich nehme die Rücknahme zurück. c_cflags, muß also auch für RX gelten, wäre ja sonst sinnlos.

Wie hast Du das ICANON gesetzt?

Falk

Falk Willberg schrieb:

Raw, also aus. Ich merke jetzt allerdings wie sehr mich das aufregt und kann mich nicht mehr konzentrieren, werde es morgen früh nocheinmal versuchen - da sind meine Nerven dann auch wieder in Arbeitslaune :-)

Viele Grüße, Johannes

Johannes Bauer schrieb:

Tja, dann...

Hehe, das scheint jedem bei der ersten Berührung mit den TTYs[0] so zu gehen. Später wird es dann besser.

Tipp zu Schluß: stty 9600 raw 9600 ... < /dev/ttyNN und hexdump -C < /dev/ttyNN schont die Nerven.

Und wenn Du dann mal ein Text-GUI benutzen willst, suche nach (n)curses[1]. Der Name scheint aus der Erfahrung mit TTY entstanden zu sein.

Falk [0]Wie ist eigentlich die C-Api für RS232 unter Windows? [1]

hwabnig@ .- --- -. dotat schrieb:

So ein Quatsch! NUHR!

Falk Willberg schrieb:

Naja, also erste Berühung mit TTYs, hehe, das war das ja nicht gerade ;-) Ich hab 2000 schonmal eine Kombination aus screen und except (naja, nur in schlecht halt) gebastelt - weil ich damals nicht wußte, dass es die beiden gibt. Das war auch mit ptys und hat recht passabel (aber unflexibel) funktioniert.

Ja, damit habe ich schon die ganze Zeit überprüft, ob mein Programm auch macht, was es machen soll - tut es.

Curses ist mir geläufig :-) Ich finde minicom und hexedit prima, beides ncurses.

So jetzt noch nen Kaffee und dann schau ich mal was ich gestern die ganze Zeit übersehen habe.

Viele Grüße, Johannes

So? Wenns einen memory Dump mit 7 bit überträgst? w.

hwabnig@ .- --- -. dotat schrieb:

Ja

Du redest Dummzeugs! Noch dazu in absolut blöder primitiver Ausdrucksweise. Aber was soll man von so einem wie Dir auch erwarten?

Wir sprechen hier nicht über Memorydumps, sondern über die Datenübertragung eines Messgerätes zu einem PC. Und das geht in simplem 7-Bit Ascii-Code.

Dein Argument ist nur wichtigtuerischer Schwachsinn!

Abgesehen davon kann man auch Memorydumps mit 7 Bit übertragen. Das ist nur eine Frage des Protokolls.

Also weiter: NUHR!

Solange man das in einer für den Übertragungskanal geeigneten Codierung (z.B. Base64 oder meinetwegen auch nibbelweise als Hexchars) tut, kommt exakt der richtige Dump an.

Wenn man aber (wie beim OP) ohnehin nur 7Bit-ASCII-Daten übertragen will, braucht's keine besondere Codierung. Die kommen auch so korrekt an. Und sind im Terminal auch direkt lesbar.

Heiko Nocon schrieb:

Wobei bei diesem Gerät nach meinen Infos ein AFAIK 13-Byte Code verwendet wird der kein ASCII ist. Mit einem Terminalprogramm wird da nur "Schrott" angezeigt werden. Man muss da jedes Byte bitweise aufdröseln bzw. zusammensetzen um die verschiedenen Informationen zu bekommen.

Am Sat, 19 Jul 2008 17:46:20 +0200 schrieb Jens Fittig:

Ich habe hier eines da werden einfach die Segmente der Anzeige als Bits codiert übertragen.

Lutz