Forum: PC-Programmierung LSB oder MSB an der UART vom PC


von montagskind (Gast)


Lesenswert?

Hallo,

ich verwende "Linux 4.2.0-41-generic #48~14.04.1-Ubuntu" auf einem Intel 
Rechner. Per UART möchte ich nun Daten gesendet bekommen und frage mich 
ob ich sie (per default) als MSB oder als LSB erhalten sollte.
Kann mir jemand sagen wie ich das herausfinden kann (abgesehen von 
"einfach mal probieren")? Meiner meinung müsste es ja am CPU-Typ liegen 
und nicht am Betriebssystem, oder?

von Clemens L. (c_l)


Lesenswert?

UARTs senden üblicherweise das niedrigste Bit eines Bytes zuerst.

Bytes werden einzeln behandelt, also ist es egal, ob die CPU Little oder 
Big Endian benutzt.

von jb (Gast)


Lesenswert?

1. Downloaden:
http://www.compuphase.com/software_termite.htm
2. Starten und auf hex view stellen.
3. Vom MC ein 'a' senden und schaunen ob du 0x65 empfängst.

Gruß J

von Georg (Gast)


Lesenswert?

montagskind schrieb:
> Per UART möchte ich nun Daten gesendet bekommen

Eine Datei wird genauso gesendet wie sie gespeichert ist, Byte für Byte.

Sendet ein Programm daten, kommt es natürlich auf das Programm an, da 
kann man keine allgemeine Aussage machen, wie z.B. ein 16bit-Wert 
gesendet wird, das hat auch mit der CPU nicht unbedingt was zu tun, 
sondern eher mit dem Programmierer. Ich ziehe daher, wie heute üblich, 
Übertragungen als ASCII-Zahlen vor, da stellt sich die Frage nicht.

Georg

von Peter II (Gast)


Lesenswert?

Georg schrieb:
> Eine Datei wird genauso gesendet wie sie gespeichert ist, Byte für Byte.

es will aber wissen wie die Bytes übertragen werden.

Bei UART ist aber die Reihenfolge der Bits festgelegt, da kommt immer 
das gleiche raus.

von Georg (Gast)


Lesenswert?

Peter II schrieb:
> es will aber wissen wie die Bytes übertragen werden.

Nein, nach der Fragestellung wollte nicht LSBit wissen, sondern LSByte - 
also die Frage nach Big oder Little Endian, daher vermutet er ja, dass 
das von der CPU abhängt.

Dass die Reihenfolge der Bits aus dem UART vom CPU-Typ abhängen könnte 
wäre mir jetzt neu. Nicht mal bei einem Software-UART.

Georg

von Timmo H. (masterfx)


Lesenswert?

Clemens L. schrieb:
> Bytes werden einzeln behandelt, also ist es egal, ob die CPU Little oder
> Big Endian benutzt.
Anders sieht es natürlich aus wenn der TO int32 auf char* castet und 
dann überträgt. Da kann man sich mit htonl bzw. ntohl behelfen.

von Volker S. (vloki)


Lesenswert?

Vor gar nicht langer Zeit hatte ich mal das Problem Java-Programmierer 
zu überzeugen Daten per USART (auch über BT, USB) Little-Endian zu 
übertragen.
Java war einem System aus vielen Komponenten die einzige, die 
standardmäßig Big-Endian verwendet. (diverse uC, Smartphones, Win-PC, 
Linux-PX...)

Zum Glück konnte ich sie in diesem Fall dazu bewegen Java dazu zu 
bringen auch Little-Endian zu verwenden.

von Georg (Gast)


Lesenswert?

Volker S. schrieb:
> Java-Programmierer
> zu überzeugen Daten per USART (auch über BT, USB) Little-Endian zu
> übertragen.

Ich verstehe das Problem nicht wirklich. Um einen 16 oder 32 bit Wert zu 
senden, muss man ihn in Bytes aufteilen, und in welcher Reihenfolge die 
gesendet werden liegt doch beim Programmierer.

Ich ziehe sowieso wegen der besseren Testbarkeit ASCII-Übertragung vor, 
wie im Internet üblich, da stellt sich die Frage garnicht erst.

Georg

von Peter II (Gast)


Lesenswert?

Georg schrieb:
> Ich ziehe sowieso wegen der besseren Testbarkeit ASCII-Übertragung vor,
> wie im Internet üblich, da stellt sich die Frage garnicht erst.

wo wird denn im IP-Protokoll etwas im ASCCI Übertragen?

Kaum ein Low-Level Protokoll kommt auf die Idee, es aber ASCII zu 
machen. Es wäre nur eine sinnlose Resourcenverschwendung.

Warum sollte sich 2 Computer in der Sprache der Menschen unterhalten?

von Timmo H. (masterfx)


Lesenswert?

Georg schrieb:
> Ich verstehe das Problem nicht wirklich. Um einen 16 oder 32 bit Wert zu
> senden, muss man ihn in Bytes aufteilen, und in welcher Reihenfolge die
> gesendet werden liegt doch beim Programmierer.
Das stimmt schon, aber ein 16 oder 32 Bit Wert wird bei Little und Big 
Endian Maschinen eben anders im Speicher abgelegt. Wenn man also einfach 
einen int32_t foo, beginnend mit der Adresse von foo gecastet auf ein 
char array von 4 Byte überträgt, dann kommt es für die Gegenstelle mit 
einem anderen Endianness verdreht an. Castet man nun die empfangenen 4 
Bytes bei der Gegenstelle einfach wieder auf ein int32 dann kommt eben 
nicht der Wert heraus den man erwartet.

: Bearbeitet durch User
von Clemens L. (c_l)


Lesenswert?

Peter II schrieb:
> Georg schrieb:
>> Ich ziehe sowieso wegen der besseren Testbarkeit ASCII-Übertragung vor,
>> wie im Internet üblich, da stellt sich die Frage garnicht erst.
>
> wo wird denn im IP-Protokoll etwas im ASCCI Übertragen?
>
> Kaum ein Low-Level Protokoll kommt auf die Idee, es aber ASCII zu
> machen.

Das bezieht sich auf die meisten Protokolle oberhalb von IP, z.B. HTTP, 
SMTP, IMAP.

> Warum sollte sich 2 Computer in der Sprache der Menschen unterhalten?

http://www.catb.org/esr/writings/taoup/html/textualitychapter.html

: Bearbeitet durch User
von Volker S. (vloki)


Lesenswert?

Georg schrieb:
> Ich verstehe das Problem nicht wirklich. Um einen 16 oder 32 bit Wert zu
> senden, muss man ihn in Bytes aufteilen, und in welcher Reihenfolge die
> gesendet werden liegt doch beim Programmierer.

Die Pfuscher wie ich, die nur in ihrer kleinen Welt leben, zerlegen 
keine Werte. Da wird einfach ein Byte-Zeiger auf den 16/32Bit Wert 
genommen und mit dem wird dann das Ganze verschickt. (Der Zeiger wird 
natürlich für jedes Byte inkrementiert). Der Empfänger schreibt es 
wieder mit Zeigern einfach sequenziell in den entsprechenden Speicher 
und es passt. Ja, ich weiß, das funktioniert nur in meiner kleine Welt.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.