Hallo, Es gibt eine Option in manchen Protokollstack: Little Endian (Intel) oder Big Endian (Motorola) Format. Ich denke, diese ist sinnvoll für 16- oder 32-Bit uC wegen mehreren Bytes. Hat diese Bedeutungen für 8-Bit uC? MfG Senmeis
http://de.wikipedia.org/wiki/Byte-Reihenfolge Kommt auf den Prozessor an! Schau in deinem UserGuide dort steht sicherlich auch wie die Bit's der Bytes organisiert sind! hatte auch schon Prozessoren wo die Bitreihenfolge gedreht war!
Owen Senmeis wrote:
> Hat diese Bedeutungen für 8-Bit uC?
Ja, denn auch 8bit Micros pflegen mit Daten grösser als 8 Bits zu
arbeiten. Und dann werden die irgendwie im Speicher angelegt.
>Hat diese Bedeutungen für 8-Bit uC?
Eine Bedeutung hat Little/Big-Endian für einen Prozessor nur, wenn er
mit anderen (externen) Teilnehmern kommuniziert, und dabei andere Daten
als nur Zeichen (chars) überträgt.
Wie der uP intern seine Daten ablegt, ist an sich egal, solange man
nicht z.B. ein char-Array auf long castet. Und das passiert am ehesten,
wenn von aussen byteweise irgendwelche Daten hereinkommen.
int x = 0x1234; *(char *)&x liefert bei little- und big-endian unterschiedliche Ergebnisse, ganz egal ob der Prozessor 8/16/32/64bittig ist. Bei sauberer Programmierung ist das kein Problem. Aber manche Leute verwenden auch gern mal unions in denen Typen verschiedener Grösse zwecks Umwandlung übereinander liegen - und finden das ok.
mal eine Frage zwischen rein, wenn ich vom motorolla-format ausgehe und dann auf intel umwandle, muss ich dann alle bits spiegeln oder nur jeweils die Bits von einem Byte, also die Reihenfolge der Bytes bleibt gleich, nur die Bits in den Bytes werden gedreht, oder wird alle gedreht?
Nur die Bytes. Die Bits werden zwar manchmal anders numeriert, aber deren Wertigkeit im Byte ändet sich nicht.
Es werden KEINE Bits gespiegelt. Es geht beim Thema Endianness lediglich um die Reihenfolge der BYTES.
@lkmiller: Formal korrekt aber ein bischen krass formuliert. Es spielt ja auch dann eine Rolle, wenn man einfach nur mit vorgegebenen Datenstrukturen umgeht. Beispielsweise einer bei Controllern recht verbreiteten SD-Card mit FAT Filesystem.
Ist es bei nem 8-Bit Controller wie z. B. Atmel AVR nicht nur Sache des Compiler, ob big oder little endian verwendet wird?
Nicht ganz. Es gibt ein paar Stellen die das nahelegen: - 16bit-Werte in I/O-Registern sind little-endian, soweit diese Register überhaupt direkt hintereinander stehen. - Ebenso die Anordnung in Prozessor-Registern, zumal Register in den RAM-Bereich gemappt werden. - Und die Return-Adressen auf dem Stack sind daher konsequenterweise bei AVRs big endian.
Ich kenne nur einen 8bit Prozessor, bei dem hardwareseitig die Anordnung von 16bit Werten nirgends vorkommt, nicht in den Befehlen, nicht den Vektoren, nicht auf dem Stack, einfach nirgends: SC/MP.
Fast. Aus den 70ern, vorrangig auf Embedded Systems (sic) und günstigen Preis optimiert. Anfangs in PMOS gebaut war er wohl einer der langsamsten Micros überhaupt (12-46µs pro Befehl). Hierzulande eigentlich nur deshalb in grösseren Kreisen bekannt, weil Elektor damals recht ernsthaft daran rumbaute. Ein 8080 war damals für Bastlerkreise prohibitiv teuer. Zu den interessanten Eigenschaften gehörte, dass es keinen direkten Sprungbefehl gab, der sich weiter als 128 Bytes wegbewegte (und auch keinen Unterprogrammaufruf). Schon in einem einem kleinen 2KB Tiny-Basic wimmelte es infolgedessen von Sprungkaskaden von einem Ende zum anderen.
das würde ich dann aber nicht "interessante Eigenschaft" nennen, eher mangelnde Realitätsnähe des Chipddesigners :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.