Hallo, hab folgendes Problem. Will adressfeld[0] = (uint8_t) (page >> 6) schreiben, aber beim compilieren kommt immer eine Fehlermeldung. Weiß jemand an was das liegen könnte? Ist uint8_t nicht schon in stdint.h vordefiniert oder muss man das selber machen? gruß
Nein, die Fehlermeldung interessiert niemand. Gibt ja nur eine ...
Mann mann, warum benutzt ihr AVR-Freaks auch immer diese komischen Datentypen? da blickt ja eh keine Sau durch, das ein "uint8_t" sein soll. Und wozu das _t am Schluss? Wenn man Datentypen wie byte, word, longword (oder meinetwegen dword) definieren würde, könnte ich das ja noch nachvollziehen. Dann ersetz halt mal alle deine tollen uint8_t durch "unsigned char".
Komischer Datentyp wrote: > Mann mann, warum benutzt ihr AVR-Freaks auch immer diese komischen > Datentypen? da blickt ja eh keine Sau durch, das ein "uint8_t" sein > soll. Und wozu das _t am Schluss? > > Wenn man Datentypen wie byte, word, longword (oder meinetwegen dword) > definieren würde, könnte ich das ja noch nachvollziehen. > > Dann ersetz halt mal alle deine tollen uint8_t durch "unsigned char". Man, son Schwachsinn kam lange nicht mehr. stdint.h ist Standard-C und ganz eindeutig der Weg der Wahl. Aber um dich zu beruhigen: - _t ist Konvention für 'Typ' - u ist 'unsigned' - int ist Ganzzahl - 8 ist 'genau 8 Bit breit' Wenn du alles besser kannst: Wie breit ist denn dein 'unsigned char' und wie bekommst du einen ganzzahligen Datentyp, der zwei Bytes lang ist? --- SCNR Zur Frage: Poste bitte mal die Fehlermeldung des Compilers.
'uint8_t' undeclared (first use in this function) Bin auf dem Gebiet noch nich so erfahren.Finde das mit 'uint8_t', 'uint16_t' und 'uint32_t viel übersichtlicher' die header stdint.h hab ich auch eingebunden
Wie hast du die denn eingebuden? Auch im Quelltext mit
1 | #include <stdint.h> |
?
>'uint8_t' undeclared (first use in this function) > >Bin auf dem Gebiet noch nich so erfahren.Finde das mit 'uint8_t', >'uint16_t' und 'uint32_t viel übersichtlicher' >die header stdint.h hab ich auch eingebunden Welchen Prozessor und Compiler benutzt du? Gut möglich das uint8_t bei deinem Compiler in stdint.h nicht definiert ist.
Eventuell auch den richtigen Standard vom Compiler/Präprozessor fordern (--std=..., teilweise sind die Header ausgiebig mit Direktiven gespickt.
wenn das ganz nicht vordefiniert ist, dann kann man das auch selber,oder? schaff mit einem ARM. Wie würden denn solche definitionen aussehen?
>schaff mit einem ARM.
Dachte ich es mir doch ;)
typedef unsigned char uint8_t; // Wertebereich: 0..255
unsigned char scheint zumindest bei WinARM 8 Bit breit zu sein.
Klar kann man sich das alles selbst zusammenbauen, aber ungewöhnlich ists schon, dass das so nicht funktioniert. Kommen vorher noch andere Fehlermeldungen?
Schreib ich dann also typedef unsigned char uint8_t; in irgendeine Header, ruf sie auf im Programm wo ich se brauch und dann gehts? Werd ich mal versuchen
Prinzipiell schon, allerdings sollteste dann auch drauf achten, dass deine Typen stimmen. Gerade ein 'char' ist nämlich nicht zwangsläufig ein 'uint8_t'.
>Sven P.
ja und zwar folgende:syntax error before 'volatile'
Die Meldung kommt immer in der Zeile, wo ich uint8_t geschreiben hab.
Hab grad gesehn dass schon paar so typedefs drinnen hab und auch grad
probiert, geht aber trotzdem nicht. Anfängerpech*g*
Zeig doch mal alle Fehlermeldungen und häng deinen Quelltext an -- da ist wohl noch mehr im Argen :-)
wenn ich #include <types.h> einbinde kommt folgende Fehlermeldung: types.h: No such file or directory Das waren was das Problem angeht alle Fehlermeldungen. Wieso das nicht geht, versteh ich jetzt ja mal garnicht. So schwer kann das ja nicht sein
Zeig trotzdem den Quelltext, oder bastle einen, der das Problem aufwirft und kompilierbar ist, so ist das nur Raterei. Aber gut: uint_... und Co. werden nicht in types.h, sondern in stdint.h festgelegt.
Nimm mal #include <sys/types.h> Bei WinARM steht das dann aber so drin. typedef unsigned char u_int8_t; >Aber gut: uint_... und Co. werden nicht in types.h, sondern in stdint.h >festgelegt. Quark. Das ist bei Winavr vieleicht so. Und uint8_t ist auch nur bei Winavr so definiert. unsigned char statt uint8_t zu benutzen scheint doch eine gute Idee zu sein ;)
oder werd es halt evtl so machen das ich halt einfach so wie gewohnt weiter mach und einfach anstatt uint8_t unsigned char schreib, dann muss ists komplett im Programm gleich. Wenn ich eine 8Bit Wert will dann muss ich eingach davor nur unsigned char scheiben oder halt mit 0x00ff ausmaskieren oder? z.B.wie hier im beispiel: page &= 0x01FF; adressfeld und page ist ein unsigned int adressfeld[0] = (uint8_t) (page >> 6); adressfeld[0] = (unsigned char) (page >> 6);
holger wrote: >>Aber gut: uint_... und Co. werden nicht in types.h, sondern in stdint.h >>festgelegt. > > Quark. Das ist bei Winavr vieleicht so. Ne, nicht Quark, sondern C-Standard (O'Reilly, C in a nutshell, Seite 239ff). Mag sein, dass die types.h dahinter steckt, aber Anlaufstelle nach Standard ist stdint.h. > Und uint8_t ist auch nur bei Winavr so definiert. Versteh ich nicht.
@ Sven P.: SCNR, aber: - ein Datentyp, der genau 2 Bytes lang ist, heisst "short int". Ein 2 Byte langer Datentyp, der kein Vorzeichen hat, ist ein "unsigned short int". Das ist Standard-C und funktioniert auch ohne irgendwelche kryptischen Header einzubinden. - ein Datentyp, der genau 4 Bytes lang ist, wäre ein "long int". Dasselbe ohne Vorzeichen: "unsigned long int". Ist ebenfalls Standard. - ein char ist immer 8 Bit, ausser bei der Verwendung eines Unicode-Zeichensatzes, den du aber auf einem Controller kaum verwenden wirst (dort wären es 16 Bit). Einen Vorteil von uint8_t kann ich beim besten Willen nicht erkennen. Das erschwert nur die Lesbarkeit von Code. Ich kam jedenfalls immer gut mit char, short int und long int aus.
Komischer Datentyp wrote: > @ Sven P.: > SCNR, aber: > > - ein Datentyp, der genau 2 Bytes lang ist, heisst "short int". Ein 2 > Byte langer Datentyp, der kein Vorzeichen hat, ist ein "unsigned short > int". Das ist Standard-C und funktioniert auch ohne irgendwelche > kryptischen Header einzubinden. Falsch, ein short oder short int muss laut C-Standard mindestens 16 Bit lang sein, darf auch mehr sein. > - ein Datentyp, der genau 4 Bytes lang ist, wäre ein "long int". > Dasselbe ohne Vorzeichen: "unsigned long int". Ist ebenfalls Standard. Falsch, ein long int muss laut C-Standard mindestens 32 Bit lang sein, kann aber auch mehr haben. Es wird noch festgelegt, dass short kleiner als oder gleichgroß wie int und int kleiner als oder gleichgroß wie long int sein soll. Es dürfen aber auch short int, int und long int allesamt 64 Bit breit sein. > - ein char ist immer 8 Bit, ausser bei der Verwendung eines > Unicode-Zeichensatzes, den du aber auf einem Controller kaum verwenden > wirst (dort wären es 16 Bit). Zumindest nicht ganz richtig, dort würde es vom Unicode abhängen, denn 16 Bit reichen nicht für vollständige Unicode-Darstellung. > Einen Vorteil von uint8_t kann ich beim besten Willen nicht erkennen. > Das erschwert nur die Lesbarkeit von Code. Ich kam jedenfalls immer gut > mit char, short int und long int aus. Ein uint8_t laut Standard ist immer genau 8 Bit breit und vorzeichenlos, dafür sorgt der entsprechende Header. Quelle: Kernighan & Ritchie, Programmieren in C, Zweite Ausgabe mit ANSI-C.
Ja dann schreib ich alles wohl lieber auf die herkömliche weiße. Von euch kennt nicht zuföllig noch jemand mit dem beschreiben und auslesen eines Flashs aus?
Wenn die stdint.h nicht dabei ist, mach dich doch mal ne Stunde schlau, was dein Compiler wie anlegt und schreibse eben selbst. Ich würde das ganz stark empfehlen, sollte sich am Compiler mal was ändern oder so (ja, das kommt auch mal vor).
Komischer Datentyp wrote: > Einen Vorteil von uint8_t kann ich beim besten Willen nicht erkennen. > Das erschwert nur die Lesbarkeit von Code. Ich kam jedenfalls immer gut > mit char, short int und long int aus. Du warst ganz offensichtlich noch in der Situation ein Programm von einem Compiler/Rechnerarchitektur zu einem anderen Compiler/Rechnerarchitektur zu übertragen. Jeder, aber auch wirklich jeder, der das schon mal gemacht hat, weiß das es dann genau an solchen Stellen hakt und verflucht den originalen Programmierer, der dämlich genug war unsigned char, int, short int und was weiß ich noch alles zu benutzen anstatt sich zumindest selbst ein paar typedefs für die Datentypen zu machen, so dass man relativ einfach an einer Stelle anpassen muss. Und nachdem der Wildwuchs an derartigen typedefs immer mehr zugenommen hat, hat sich das Normungsgremium irgendwann erbarmt und hat dafür Standardtypen geschaffen.
Steff wrote:
> was wären denn dann die Standarttypen?
Welche? Die, die in C verbaut sind oder die, die aus stdint.h kommen?
C bietet dir:
- short int, int, long int, jeweils signed oder unsigned
- unsigned char, char, signed char
- float
usw.
Bei denen ist die Breite so schwamming festgelegt, wie ich es oben
beschrieben hab.
Die aus stdint.h sind fast immer vorzuziehen:
- int8_t, uint8_t usw.
Es gibt auch noch Definitionen für den jeweils schnellsten Datentyp mit
einer Mindestbreite usw.
uint8_t uint16_t uint32_t uint64_t int8_t int16_t int32_t int64_t Und jetzt rate mal welcher dieser Typen welche Eigenschaften hat. Auf einem AVR mit gcc wären das dann typedef unsigned char uint8_t; typedef unsigned int uint16_t; typedef unsigned long uint32_t; typedef unsigned long long uint64_t; typedef signed char int8_t; typedef int int16_t; typedef long int32_t; typedef long long int64_t;
bei mir ist folgende header im programm: types.h und dort ist u.a.
folgendes definiert:typedef signed char int8_t;
typedef unsigned char u_int8_t;
typedef short int16_t;
typedef unsigned short u_int16_t;
usw.
wenn ich aber in meinem Quellcode die header einbinde und dann die neu
definierten datentypen verwende, dann kommt immer eine Fehlermeldung.
Eigentlich müsste es aber schon so gehn,oder?
Steff wrote: > bei mir ist folgende header im programm: types.h und dort ist u.a. > folgendes definiert:typedef signed char int8_t; > typedef unsigned char u_int8_t; > typedef short int16_t; > typedef unsigned short u_int16_t; > usw. > > wenn ich aber in meinem Quellcode die header einbinde und dann die neu > definierten datentypen verwende, dann kommt immer eine Fehlermeldung. > Eigentlich müsste es aber schon so gehn,oder? Ja, wobei hier u_int8_t typedef'd wird, und nicht uint8_t. Wer macht denn da den _ rein? Oder wird das später berwendet um einen uint8_t drauf zu definieren? Karl heinz Buchegger wrote: > Auf einem AVR mit gcc wären das dann > > typedef unsigned char uint8_t; > typedef unsigned int uint16_t; > typedef unsigned long uint32_t; > typedef unsigned long long uint64_t; > > typedef signed char int8_t; > typedef int int16_t; > typedef long int32_t; > typedef long long int64_t; Nur zur Information: Die GNU-Toolschain für AVR definiert einen uint8_t als
1 | typedef unsigned int uint8_t __attribute__((__mode__(__QI__))); |
binden den Typ also an einen bestimmten Maschinen-Mode (hier QImode). Grund dafür ist weil int nicht immer 16 Bit groß ist. Zusammen mit der Option -mint8 ist ein int nur 8 Bit groß und ein long int nur 2 Byte groß. Johann
weiß nicht wer das _ reingemacht hat. das ist schon hier so vorgegeben, aber wenn ich es einbind funktioniert nichts. wüsstest du sonst evtl an was das liegen könnte?
Steff wrote: > weiß nicht wer das _ reingemacht hat. das ist schon hier so vorgegeben, > aber wenn ich es einbind funktioniert nichts. wüsstest du sonst evtl an > was das liegen könnte? Die Anwort gab dir bereits Sven: Sven P. wrote: > Zeig trotzdem den Quelltext, oder bastle einen, der das Problem aufwirft > und kompilierbar ist, so ist das nur Raterei. > > Aber gut: uint_... und Co. werden nicht in types.h, sondern in stdint.h > festgelegt. Zu aussagekräftigen Antworten gehöret auch aussagekräftige Fragen. ZB welche Compilerschalter und -version da am Werk sind, Ausgabe (bei gcc mit -v), etc. Johann
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.