|
Anzeige
|
LSB oder MSB an der UART vom PC
Gast
#4668343
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? 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.
Gast
#4668426
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
Gast
#4668608
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
Gast
#4668617
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.
Gast
#4668832
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 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. 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.
Gast
#4678956
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
Gast
#4678960
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? 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. 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 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. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
