IAR Datentypen zu GCC Datentypen

[Dennis K. (scarfaceno1)]

Hi,

ich bin dabei ein älteres IAR Projekt in GCC (Atmel Studio 7) zu 
portieren.
Jetzt gibt es da ein paar Datentypen, die er nicht umsetzen kann.

BsP

U16P
U8
U16
I16P



und ich bin mir nicht sicher ob ich die einfach so umsetzen kann.

Gibt es dort eine Liste, die beschreibt, was welcher Datentyp genau ist?

Besten Dank schon mal

[Rufus Τ. F. (rufus)]

Das sind recht sicher keine "nativen" Datentypen des IAR-Compilers, das 
wird sich jemand selbst gebastelt haben.

Mach das Ding in der IAR-IDE auf, klick auf so einen Datenyp und lass 
Dir die Definition davon anzeigen.

Und stell' das ganze dann auf die in stdint.h definierten Typen (à la 
uint16_t etc.) um.

[Dennis K. (scarfaceno1)]

Mein Problem ist, dass ich nicht weiß, in welcher Version des IAR EW das 
geschrieben wurde.

Wie bekomme ich das raus? Ich habe es mit 4.20A probiert und bekomme 
gesagt, dass die IDE zu alt ist und das Projekt nicht geöffnet werden 
kann...

[Peter II (Gast)]

Dennis K. schrieb:
> Mein Problem ist, dass ich nicht weiß, in welcher Version des IAR EW das
> geschrieben wurde.

man braucht keine IDE um ein paar C-Dateien zu durchsuchen.

[Felix U. (ubfx)]

Ich lehne mich glaube ich nicht allzuweit aus dem Fenster wenn ich 
annehme, dass i = int, u = unsigned und p = pointer.

#include <stdint.h>

#define U8    uint8_t
#define U16   uint16_t

#define I8    int8_t
#define I16   int16_t

#define U8P   U8*
#define U16P  U16*

#define I8P   I8*
#define I16P  I16*

Ob das mit den Pointern Sinn ergibt, wäre wohl nochmal anhand des 
Kontextes zu prüfen, der Rest ist ja aber eindeutig.

[Rufus Τ. F. (rufus)]

Was aber ist "BsP"?

[Peter II (Gast)]

Rufus Τ. F. schrieb:
> Was aber ist "BsP"?

Beispiel? Er meinte vermutlich Bsp.

[Dennis K. (scarfaceno1)]

BSP sollte Beispiel heißen.

und ja, sogar das mit den Pointern gibt Sinn.

Ich werde es mal so ausprobieren, danke schonmal.

[A. S. (Gast)]

Dennis K. schrieb:
> Ich werde es mal so ausprobieren, danke schonmal.

??????????????

Nicht ausprobieren(!) sondern mit der IDE oder dem Editor Deiner Wahl 
die *.h files durchsuchen.

Keine Angst, wenn Du noch kein Tool zum durchsuchen von Dateien (in 
Verzeichnissen) hast, wird dies das erste sein, was Du sowieso brauchst.

[Dennis K. (scarfaceno1)]

Ich benutze wie gesagt das Atmel Studio 7.

Dort kann ich auch das ganze Projekt durchsuchen.

Nach Schlagwörtern wie IAR, Embedded, Workbench hab ich da auch schon 
gesucht, aber nichts gefunden.

Ich passe gerade die Include Pfade an und versuche die anderen Fehler 
weg zu bekommen.

[Dennis K. (scarfaceno1)]

Felix U. schrieb:
> Ich lehne mich glaube ich nicht allzuweit aus dem Fenster wenn ich
> annehme, dass i = int, u = unsigned und p = pointer.

> #define U8P   U8*
> #define U16P  U16*
>
> #define I8P   I8*
> #define I16P  I16*
> [/code]
>
> Ob das mit den Pointern Sinn ergibt, wäre wohl nochmal anhand des
> Kontextes zu prüfen, der Rest ist ja aber eindeutig.


Das hat fast geklappt aber U8*, I8* und die 16 bit Varianten kennt der 
compiler nicht.

[Rufus Τ. F. (rufus)]

Dennis K. schrieb:
> Das hat fast geklappt aber U8*, I8* und die 16 bit Varianten kennt der
> compiler nicht.

Sieh mal drei, vier Zeilen oberhalb des von Dir verstümmelten Zitats 
nach.

#include <stdint.h>

#define U8    uint8_t
#define U16   uint16_t

#define I8    int8_t
#define I16   int16_t

#define U8P   U8*
#define U16P  U16*

#define I8P   I8*
#define I16P  I16*

Da darfst Du natürlich nichts von weglassen.

[root (Gast)]

Dennis, da fehlt es doch schon an der Basis

[Rufus Τ. F. (rufus)]

Achim S. schrieb:
> Keine Angst, wenn Du noch kein Tool zum durchsuchen von Dateien (in
> Verzeichnissen) hast,

So etwas ist bei jedem Windows dabei.

findstr /s /c:"U8P" c:\*.h

durchsucht alle *.h-Dateien auf der gesamten Festplatte c:\ nach dem 
Auftreten von "U8P".

findstr /s /i /c:"U16P" c:\projekte\*.h

Durchsucht alle *.h-Dateien, die unterhalb von c:\projekte zu finden 
sind, nach dem Auftreten von "U16P", wertet aber keine 
Groß-/Kleinschreibung aus, so daß auch "u16p" und "U16p" gefunden 
werden.

Mehr Informationen über findstr gibt es mit

findstr /?

[Frank M. (ukw) (Moderator)]

Felix U. schrieb:
> #define U8    uint8_t

Ein typedef statt #define wäre hier eventuell sinnvoller.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Frank M. schrieb:
> Felix U. schrieb:
>> #define U8    uint8_t
>
> Ein typedef statt #define wäre hier eventuell sinnvoller.

Vor allem bei den Zeiger-Typen ;-)

[Felix U. (ubfx)]

Frank M. schrieb:
> Ein typedef statt #define wäre hier eventuell sinnvoller.

Stimmt, habe nur #defines verwendet weil ich persönlich in C nur 
Makros/defines großschreiben würde. Gefühlsmäßig hätte ich deshalb 
gesagt, dass es im Original auch ein #define ist. i8, i8p usw hätte ich 
auch per typedef gemacht.

[Frank M. (ukw) (Moderator)]

Dennis K. schrieb:
> Jetzt gibt es da ein paar Datentypen, die er nicht umsetzen kann.
>
> BsP
> U16P
> U8
> U16
> I16P

Da dies mit fast hundertprozentiger Wahrscheinlichkeit keine 
IAR-spezifischen Typen sind, muss der Programmierer des Projekts diese 
Typen selbst in einer H-Datei definiert haben.

Was andere hier schon mal versucht haben, Dir zu erklären und ich nicht 
sehe, dass Du das wirklich verstanden hast, schreibe ich es nochmal mit 
anderen Worten:

Da Dir der komplette Quellcode des Projekts vorliegt, musst Du auch die 
Definitionen dieser Typen vorliegen haben. Durchsuche also bitte alle 
H-Dateien des Projekts und Du wirst die Typ-Definitionen dazu auch 
finden.

Schleierhaft ist mir allerdings, warum Du das entsprechende #include 
dieser H-Datei aus dem Source herausgeworfen hast...

[Johann L. (gjlayde)]

Torsten R. schrieb:
> Frank M. schrieb:
>> Felix U. schrieb:
>>> #define U8    uint8_t
>>
>> Ein typedef statt #define wäre hier eventuell sinnvoller.
>
> Vor allem bei den Zeiger-Typen ;-)

Nicht unbedingt, denn dann braucht's einen extra Typen für const 
uint8_t* etc.

Anstatt dieser eigenartigen Typen würde ich einfach den ganzen Code 
überarbeiten und Standard-Typen verwenden.

[Rolf M. (rmagnus)]

Johann L. schrieb:
> Torsten R. schrieb:
>> Frank M. schrieb:
>>> Felix U. schrieb:
>>>> #define U8    uint8_t
>>>
>>> Ein typedef statt #define wäre hier eventuell sinnvoller.
>>
>> Vor allem bei den Zeiger-Typen ;-)
>
> Nicht unbedingt, denn dann braucht's einen extra Typen für const
> uint8_t* etc.

Doch, unbedingt. Gerade deshalb. Ich halte es für sehr irreführend, wenn 
ein const U8P nicht etwa ein konstanter Zeiger auf ein U8 ist, sondern 
ein nicht konstanter Zeiger auf einen konstanten U8. Allerdings würde 
ich eh nicht auf die Idee kommen, Zeigertypen auf so eine Art zu 
verstecken. Ich sehe keinen Mehrwert darin, das *, das ganz eindeutig 
für einen Zeiger steht, hinter einem Namen zu verbergen.
Wobei: Für den vorliegenden Code würde ich dieselbe Art der Definition 
(also typedef oder #define) verwenden, wie im ursprünglichen Code, denn 
es ist ja möglich, dass er darauf angewiesen ist, dass es genau so 
gehandhabt wird, wie im Original - mit allen Merkwürdigkeiten, die das 
ggf. mit sich bringt.

> Anstatt dieser eigenartigen Typen würde ich einfach den ganzen Code
> überarbeiten und Standard-Typen verwenden.

Wenn man das Programm später über eine gewisse Zeit weiterentwickeln und 
warten muss, auf jeden Fall. Wenn's nur darum geht, das einmalig zu 
portieren, lohnt sich der Aufwand meines Erachtens nicht.

[Yalu X. (yalu) (Moderator)]

Rolf M. schrieb:
>>>> Ein typedef statt #define wäre hier eventuell sinnvoller.
>>>
>>> Vor allem bei den Zeiger-Typen ;-)
>>
>> Nicht unbedingt, denn dann braucht's einen extra Typen für const
>> uint8_t* etc.
>
> Doch, unbedingt. Gerade deshalb. Ich halte es für sehr irreführend, wenn
> ein const U8P nicht etwa ein konstanter Zeiger auf ein U8 ist, sondern
> ein nicht konstanter Zeiger auf einen konstanten U8.

Sehe ich auch so. Anderes verwirrendes Beispiel:

#define U16P uint16_t *

U16P u16ptr1, u16ptr2; // nur die erste Variable ist ein Pointer

> Allerdings würde
> ich eh nicht auf die Idee kommen, Zeigertypen auf so eine Art zu
> verstecken. Ich sehe keinen Mehrwert darin, das *, das ganz eindeutig
> für einen Zeiger steht, hinter einem Namen zu verbergen.

Sehe ich auch so. Man spart mit dem P-Suffix meist nicht einmal
Tipparbeit.

[Dennis K. (scarfaceno1)]

Ok, ihr habt mich überzeugt.

Ich werde den Code neu schreiben und mich etwas tiefer darin 
einarbeiten. Ich dachte es ginge mit sehr wenig Einarbeitung und 
Aufwand. Das scheint aber nicht zu funktionieren.

Gerade da der Code abgeändert werden soll, schreibe ich ihn neu.