www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik stdint.h in Projekt einbinden


Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, die Fehlermeldung interessiert niemand. Gibt ja nur eine ...

Autor: Komischer Datentyp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
'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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie hast du die denn eingebuden? Auch im Quelltext mit
#include <stdint.h>
?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>'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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eventuell auch den richtigen Standard vom Compiler/Präprozessor fordern 
(--std=..., teilweise sind die Header ausgiebig mit Direktiven gespickt.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn das ganz nicht vordefiniert ist, dann kann man das auch 
selber,oder?

schaff mit einem ARM.

Wie würden denn solche definitionen aussehen?

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sven P.  Ja genau so hab ich das eingebunden.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar kann man sich das alles selbst zusammenbauen, aber ungewöhnlich 
ists schon, dass das so nicht funktioniert.
Kommen vorher noch andere Fehlermeldungen?

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prinzipiell schon, allerdings sollteste dann auch drauf achten, dass 
deine Typen stimmen. Gerade ein 'char' ist nämlich nicht zwangsläufig 
ein 'uint8_t'.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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*

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zeig doch mal alle Fehlermeldungen und häng deinen Quelltext an -- da 
ist wohl noch mehr im Argen :-)

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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);

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Komischer Datentyp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was wären denn dann die Standarttypen?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
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

Autor: Steff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.