Unterschied uint16_t, short int und unsigned int?

Hallo,

kann mir jmd. den Unterschied zwischen..

uint16_t short int unsigned int

..erklären?

Danke.

Gruß Chris

Hallo Chris,

u oder unsigned bezeichnet einen Typ ohne Vorzeichen. Der Wert kann nur positiv sein, dafür kann er grösser sein (z. Bsp. 0 … 65535 statt -32768 … 32767).

int sind abhängig vom Prozessortyp. Beim Arduino UNO ist es ein z. Bsp. ein 16 - Bit Wert, bei einem 32 Bit Prozessor wären es 32 Bit.

uint16_t ist immer 16 Bit unsigned.

short int ist normalerweise 16 Bit. Ob das immer so ist, kann ich aber nicht garantieren.

Wenn die Bitbreite wichtig ist, sollten also immer uint16_t, uint32_t usw. verwendet werden.

Gruss
René

Also ist uint16_t und unsigned int im Fall des Arduinos (Uno) das Gleiche?
short int kann negativ sein und unterscheidet sich somit von den o.a. Typen?

Gruß Chris

Testsketch:

uint16_t test1;
unsigned int test2;
short int test3;

void setup() {
  Serial.begin(9600);
  test1--;
  Serial.print("uint16_t      Anzahl Bytes: "); Serial.print(sizeof(test1)); Serial.print("  max. Wert: "); Serial.println(test1);
  test2--;
  Serial.print("unsigned int  Anzahl Bytes: "); Serial.print(sizeof(test2)); Serial.print("  max. Wert: "); Serial.println(test2);
  test3--;
  Serial.print("short int     Anzahl Bytes: "); Serial.print(sizeof(test3)); Serial.print("  max. Wert: "); Serial.println(test3);
}

void loop() {
}

Ausgabe teensy (32 Bit):

uint16_t      Anzahl Bytes: 2  max. Wert: 65535
unsigned int  Anzahl Bytes: 4  max. Wert: 4294967295
short int     Anzahl Bytes: 2  max. Wert: -1

Ausgabe UNO:

uint16_t      Anzahl Bytes: 2  max. Wert: 65535
unsigned int  Anzahl Bytes: 2  max. Wert: 65535
short int     Anzahl Bytes: 2  max. Wert: -1

Cool! Danke.

Gruß Chris

Hallo,

stimmt das mit dem short int wirklich? Denke nicht. Wenn es 2 Byte groß ist, kann max nicht -1 sein.

Edit: okay, an Hand der -1 sieht man nur das der Typ nicht unsigned ist. :)

Der Text "max. Wert" ist nicht allgemeingültig, war auf die unsigned Typen bezogen. Quick and dirty :P

short ist auf den AVRs das gleiche wie int. Auf 32 oder 64 Bit Prozessoren ist es ein 2 Byte Datentyp, während int 4 Byte hat. Also in der Arduino Welt nur bei ARMs relevant.

Typen wie uint16_t haben da den Vorteil, dass sie Plattform-unabhängig sind. Das ist sowohl auf dem AVR als auch dem ARM 16 Bit. Deshalb wird das oft in Libraries verwendet, wogegen man es in einfachen Sketches kaum sieht.

Serenifly:
Deshalb wird das oft in Libraries verwendet, wogegen man es in einfachen Sketches kaum sieht.

Das ist dann so wie mit delay. Das findet sich vorwiegend auch nur in den einfacheren Sketches.
Will man diese zunächst meist leicht lesbaren Sketche dann auf “non-blocking” adaptieren um sie in andere Sketche zu integrieren, wird es dann oftmals ekelhaft. So geht es mir zumindest regelmäßig. :stuck_out_tongue:

Gruß Chris

Chris72622: Ups- Doppelpost.

Bitte löschen, sorry.

Das kannst Du selbst machen: rechts unten "More/Remove" :)

agmue:
Testsketch:

uint16_t test1;

unsigned int test2;
short int test3;

void setup() {
 Serial.begin(9600);
 test1–;
 Serial.print("uint16_t      Anzahl Bytes: “); Serial.print(sizeof(test1)); Serial.print(”  max. Wert: "); Serial.println(test1);
 test2–;
 Serial.print("unsigned int  Anzahl Bytes: “); Serial.print(sizeof(test2)); Serial.print(”  max. Wert: "); Serial.println(test2);
 test3–;
 Serial.print("short int     Anzahl Bytes: “); Serial.print(sizeof(test3)); Serial.print(”  max. Wert: "); Serial.println(test3);
}

void loop() {
}



Ausgabe teensy (32 Bit):


uint16_t      Anzahl Bytes: 2  max. Wert: 65535
unsigned int  Anzahl Bytes: 4  max. Wert: 4294967295
short int     Anzahl Bytes: 2  max. Wert: -1



Ausgabe UNO:


uint16_t      Anzahl Bytes: 2  max. Wert: 65535
unsigned int  Anzahl Bytes: 2  max. Wert: 65535
short int     Anzahl Bytes: 2  max. Wert: -1

Hi agmue,

denke das hier wir meinen Fehler an anderer Stelle lösen!
Danke.

:grinning:

Serenifly:
Typen wie uint16_t haben da den Vorteil, dass sie Plattform-unabhängig sind.

Wenn sie denn existieren! “diese Typen”
Es gibt/gab genügend Plattformen, welche eben kein uint16_t kennen.

OK, in der Arduino Welt ist mir das noch nicht begegnet.
Aber Signalprozessoren mit 9 Bit pro Byte sind mir schon unter gekommen.
Aus solchen Bytes kann man kein uint16_t basteln, dann gibts auch kein uint16_t für den Prozessor.
Und in meiner Urzeit sogar einmal ein Kessel, mit 36 Bit pro Byte

@Chris72622
Nach weit über 1000 Postings, nach solchen Grundlagen im Forum fragen, kommt mir sehr befremdlich vor.

Lesestoff + Lesestoff

Dort steht exakt, welche Typen IMMER zur Verführung stehen, und welche nur manchmal.
Ebenso ihre Größen/Wertebereiche.

In der Regel ist es so, dass man immer Typen in der natürlichen Größe des µC verwenden sollte, wenn man die Wahl hat.
Denn diese sind meistens am effektivsten implementiert.
Die Verwendung kleinerer Typen bringt selten Vorteile.
Auch nicht immer im Speicherverbrauch siehe: Alignment oder “Alignment requirement”

short int test3 = irgendwas;
test3–;

Das kann zu Problemen führen, denn der Über- und Unterlauf von Signed Typen führt auch mal zu undefiniertem Verhalten des Programms.
Der Grund ist schlicht: Die C++ Sprachdefinition weiß nicht, ob der µC Einer- oder Zweierkomplement verwendet.

combie: @Chris72622 Nach weit über 1000 Postings, nach solchen Grundlagen im Forum fragen, kommt mir sehr befremdlich vor.

Due Ursprungsfrage von Chris ist ja auch schon über 4 Jahre her ;) . Hier wurde halt mal wieder ein uralter Post 'ausgegraben'.

combie: @Chris72622 Nach weit über 1000 Postings, nach solchen Grundlagen im Forum fragen, kommt mir sehr befremdlich vor.

Nach einem Espresso mit leckerem Honigbrötchen fällt mir sofort das Datum von 2016 auf!

combie:

short int test3 = irgendwas; test--;

Das kann zu Problemen führen, ...

agmue: Quick and dirty :P

Guten Morgen!

Due Ursprungsfrage von Chris ist ja auch schon über 4 Jahre her

Och!

Dann nehme ich den Einlauf zurück. Aber der Rest bleibt wegen Relevanz stehen!

... wobei, Chris schon 8 Jahre dabei ist, nicht erst 4 ....

noiasca: heißt das auch, dass dann z.b. ein for(byte i = ...) eher kontraproduktiv gegenüber einem for(int i = ) ist der Effekt am Arduino sichtbar/messbar?

Bei einem 'standad' Arduino (ATMega) ist 'byte' die natürliche Größe der Daten.

heißt das auch, dass dann z.b. ein for(byte i = ...) eher kontraproduktiv gegenüber einem for(int i = )

Kann man schlecht verallgemeinern, aber wenn ich dazu gezwungen werde, dann sage ich ja.

for(byte i = ...) mag auf einem AVR Vorteile haben

Denn ein 32 oder 64 Bit System kann immer nur eben diese Bitzahl aus dem Speicher lesen, in Registern halten, damit rechnen und muss diese mühselig zu Bytes zerhacken. Einige der großen Prozessoren haben Befehle für die kleinen Daten Typen, aber das heißt nicht dass diese besonders effektiv funktionieren.

Es gibt schon Gründe, warum byte kein definierter C/C++ Datentype ist(hat sich das geändert?). Hier ist der wohl wichtigste

Auf AVR kann byte Vorteile haben, zumindest was die Platz sparende Speicherung betrifft. Aber für Rechenoperationen/Funktionen, wird es oft zu unsigned aufgeblasen, gerechnet, und wieder zum Byte zerhackt. Beispiel aus der Gcc AVR ABI

Calling Convention An argument is passed either completely in registers or completely in memory. To find the register where a function argument is passed, initialize the register number Rn with R26 and follow this procedure:

If the argument size is an odd number of bytes, round up the size to the next even number. ..........

Aufrufparameter werden also in 16 Bit Häppchen zugeordnet.

ist der Effekt am Arduino sichtbar/messbar?

for(byte i = ...) hat auf einem ESP oder ARM, wohl keine Vorteile. for(int i = ) hat auf einem AVR, wohl keine Vorteile Viele der Nachteile werden durch die aktivierte Optimierung weg gebügelt. Unsere Compiler sind da sehr gut. Wenn du auf einem AVR for(int i = ) statt for(byte i = ...) schreibst, und der Compiler erkennen kann, dass i nie größer als 255 werden kann, wird er den gleichen Code generieren.

Messbar? Also, nicht immer... Aber wenn kleinste Änderungen am Code die Optimierung umstellen, kann einem das schon ein Beinchen stellen.

Bei einem 'standad' Arduino (ATMega) ist 'byte' die natürliche Größe der Daten.

Ja, für den AVR an sich.... Aber nicht für den Compiler. Der kennt char und int, aber kein byte. Der Datentype byte ist eine Arduino Extrawurst.

combie:
Och!

… wobei, Chris schon 8 Jahre dabei ist, nicht erst 4 …

Gibt es nicht sowas wie Jugendsünden, die man ab einen gewissen Alter beflissentlich zufällig vergißt?? :wink: :wink:
Grüße Uwe

uwefed: Gibt es nicht sowas wie Jugendsünden, die man ab einen gewissen Alter beflissentlich zufällig vergißt?? ;) ;)

Die Jugend achtet das Alter nicht mehr, zeigt bewusst ein ungepflegtes Aussehen, sinnt auf Umsturz, zeigt keine Lernbereitschaft und ist ablehnend gegen übernommene Werte

Quelle: ca. 3000 v. Chr., Tontafel der Sumerer