Hallo! Ich bin Einsteiger im Bereich Mikrocontrollerprogrammierung in C. Normalerweise versuche ich egal welche Anwendung so flexibel wie möglich zu gestalten. Im Tutorial habe ich gesehen, dass Variablen z.b. mit dem Dateityp uint16_t anstatt mit einem unsigned int bzw. uint8_t anstatt mit unsigned char definiert wurde. Diese Bezeichnungen ersetzen sicherlich in irgendeiner Headerdatei oder so die ursprüngliche Bezeichnung und sind wenn ich das richtig sehe leichter Lesbar und schneller zum tippen. Wenn allerdings der Quellcode von jemandem eingesehen wird, dem diese (ich denke speziell für den µC) eingerichteten Bezeichnungen unbekannt sind bzw. er diese Headerdatei nicht hat, ist der Code demnach nicht so leicht übertragbar...? Mich interessiert nun ob man sich diese neue Bezeichnung aneignen sollte oder ob man von vornherein lieber bei der längeren Schreibweise bleiben sollte? Gruß Waldemar
Bei den "neuen" Schreibweisen weißt du genau, wieviel Bit deine Variable hat. Da das bei einigen "Rechenarten" wichtig ist, ist es notwendig diese für eine Portierung auf ein anderes System zu behalten (also die Bitzahl). Gruß, Lasse
uint16_t wenn es genau 16 Bits sein sollen, des Platzverbrauchs wegen. unsigned wenn es mindestens 16 Bit sein sollen, es aber auf 32 Bit Prozessoren der Effizienz halber auch mehr sein darf.
ja, Richtig... Du meinst also, wenn ich die Deklaration "int" lese, weiß ich damit nicht auf den ersten Blick, dass sich dahinter 16Bit verbergen? In welcher Headerdatei steht die Erweiterung? Wüsste nicht, dass ich diese bewusst in mein Testprogramm eingefügt habe... Habe bisher io.h und delay.h als allgemeine Headerdateien drin...
Waldemar T. schrieb: > Wenn allerdings der Quellcode von jemandem > eingesehen wird, dem diese (ich denke speziell für den µC) > eingerichteten Bezeichnungen unbekannt sind bzw. er diese Headerdatei > nicht hat, ist der Code demnach nicht so leicht übertragbar...? Diese Bezeichnungen sind offizieller Bestandteil des C Standards. Also benutze sie ruhig, und zwar nicht nur bei µC-Programmen. > In welcher Headerdatei steht die Erweiterung? stdint.h
Waldemar T. schrieb: > ja, Richtig... Du meinst also, wenn ich die Deklaration "int" lese, weiß > ich damit nicht auf den ersten Blick, dass sich dahinter 16Bit > verbergen? Yep, kann auch mehr sein. int/unsigned sind die effizientesten Typen wenn es sich mindestens um eine 16-Bit Architektur handelt. Bei einer 8-Bit Architektur sind 8-Bit Typen naturgemäss effizienter.
Stefan Ernst schrieb: > Diese Bezeichnungen sind offizieller Bestandteil des C Standards. Also > benutze sie ruhig, und zwar nicht nur bei µC-Programmen. Du hast recht, hab es grad in einem anderen C programm ausprobiert... :) ok, wenn das so ist, ist mir das egal... Eine Frage habe ich noch: Habe gerade das Phänimen gehabt, dass ich einem unsigned char abc = 0 zugewiesen hab (vor der Main Schleife). Erwartungsgemäß wurde damit ein Byte in meinem RAM reserviert. Wenn ich allerdings abc = 1 oder irgendeinen anderen Werrt zuweise werden zwei Byte im RAM reserviert... Wieso das ganze? (Nicht das ich dem Byte hinterherweine, aber das muss doch einen Grund haben...)
Bei "char abc = 0" landet die Variable im bss-Segment, bei "char abc = 1" im data-Segment. Vermutlich macht das Linkerskript beim data-Segment ein Padding auf eine gerade Adresse, weil danach noch das bss-Segment kommt, beim bss-Segment aber nicht, weil danach nichts mehr kommt.
Gast
#1438907
> Diese Bezeichnungen sind offizieller Bestandteil des C Standards.
Und zwar mittlerweile seit 10 Jahren. stdint.h bietet dir da die
Typedefs intX_t, int_leastX_t und int_fastX_t, wobei du X durch die
Bitbreiten ersetzt. Dabei ist ersterer ein Typ mit exakt der angegebenen
Größe, das zweite ist ein möglichst kleiner Typ, der mindestens die
Größe hat, und der dritte ein möglichst schneller Typ, der mindestens
diese Größe hat.
ich habe mal eine ganz allgemeine Frage zu den uintX_t Datentypen. Wofür steht das "_t" am Ende des Types???
type Viele C-Programmierer hängen an Typnamen ein _t an, damit man sieht, daß dieser Name für einen Typ steht (so wie p... oder p_... für einen pointer, also Zeiger). PS: Das ist soweit durchaus sinnvoll, auch wenn das _t indzischen (bei C++ vor allem) ersetzt wird durch die Regel: - ein Kleinbuchstabe am Anfang kennzeichnet ein Objekt (Variable) - ein Großbuchstabe am Anfang eine Klasse, also einen Typ:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
PPS: Dann gibt es noch die "ungarische Notation". Da wird jeder Variablen ein Name gegeben, dessen Anfang den Typ in Kurzform kennzeichnet, also ui_bla für eine unsigned int-Variable, d_radius für eine double etc.. Das habe ich früher schon für Schwachsinn empfunden, aber es gibt Fans davon. Vor allem Microsoft hat das favorisiert. Inzwischen ist es vollkommen unsinnig, weil heutige Programme nicht mehr wie früher mit einer Handvoll Datentypen auskommen. Aber p vorweg bei Zeigern und _t am Ende bei Typen ist meistens sinnvoll.
wieder was gelernt. thx
Waldemar T. schrieb: > Habe gerade das Phänimen gehabt, dass ich einem unsigned char abc = 0 > zugewiesen hab (vor der Main Schleife). Erwartungsgemäß wurde damit ein > Byte in meinem RAM reserviert. Wenn ich allerdings abc = 1 oder > irgendeinen anderen Werrt zuweise werden zwei Byte im RAM reserviert... > > Wieso das ganze? Wenn die Variable mit 0 intialisiert wird landet sie wie oben bereits erwähnt im BSS Segment. Dieses wird vom Startup Code mit null vorbelegt egal wie gross es ist. Wird die Variable mit != 0 initialisiert landet Sie im Data Segment und wird intialisiert. Dazu hat nimmt Startup Code die Werte aus dem ROM und kopiert sie ins RAM. Daher ist der benötigte Speicher die eigentliche Varibale plus der Intialisierungswert. Gruß, Frank
A. K. schrieb: > unsigned wenn es mindestens 16 Bit sein sollen, es aber auf 32 Bit > Prozessoren der Effizienz halber auch mehr sein darf. Wobei das eher ein Fall für uint_fast16_t wäre. ;-)
Jörg Wunsch schrieb: > Wobei das eher ein Fall für uint_fast16_t wäre. ;-) Richtig. Aber hast du mal aufs Datum vom Beitrag geschaut?
A. K. schrieb: > Aber hast du mal aufs Datum vom Beitrag geschaut? Sorry, nein, hatte die Threadleiche nicht bemerkt. :-(
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.