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
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.
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...
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.
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.
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.
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.
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.
Achim S. schrieb:> Keine Angst, wenn Du noch kein Tool zum durchsuchen von Dateien (in> Verzeichnissen) hast,
So etwas ist bei jedem Windows dabei.
1
findstr /s /c:"U8P" c:\*.h
durchsucht alle *.h-Dateien auf der gesamten Festplatte c:\ nach dem
Auftreten von "U8P".
1
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
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 ;-)
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.
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...
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.
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.
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:
1
#define U16P uint16_t *
2
3
U16Pu16ptr1,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.
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.