Hallo Leute, mein Tasking C - Compiler sagt mir, dass folgende Programmzeile einen Syntax Fehler aufweisen soll: void send_data(unsigned int *p , unsigned int len){ // Code } Irgendwie entdeck ich da keinen Fehler, könnt ihr mir weiterhelfen? Danke,Stefan...
hier mein vollständiger code... // display.c #include <math.h> //#include "display.h" void send_data(unsigned int *p , unsigned int len){ unsigned int send_data[len + 3]; unsigned int bcc = 0; send_data[0] = 0x11; send_data[1] = len; for(int i = 2 ; i < len + 2 ; i++){ send_data[i] = *(p + i - 2); } for(int i = 0 ; i < len + 2 ; i++){ bcc = bcc + send_data[i]; } bcc = fmod(bcc,256); send_data[len + 2] = bcc; }
>void send_data(unsigned int *p , unsigned int len){ > unsigned int send_data[len + 3]; Dynamische Arrays können C Compiler glaube ich nicht ;)
lässt sich bei mir ohne Warnung/Fehler mit WinAVR kompilieren... > Dynamische Arrays können C Compiler glaube ich nicht ;) hm dann scheint WinAVR das etwas laxer zu sehen...
also der compiler meckert speziell bei " unsigned int *p " , sieht so als ob er als Übergabewert den Poiner nicht akzeptiert, sehr merkwürdig... Keine ne Idee?
Hast du noch irgendeine Include-Datei oder weiter oben vor send_data() die Funktion send_data() anders deklariert? Wie sieht die Fehlermeldung genau aus? Ich kann das so auch kompilieren.
ja, ich hab darüber noch zwei include dateien, hab sie auch schon auskommentiert aber der fehler bleibt, hab mich auch falsch ausgedrückt, es ist wohl ehr ein parser error als ein compiler error. ich werd erstmal versuchen den parser plug-in zu aktuallisieren
hm vielleicht sind nicht sichtbare zeichen im code... tipp mal sie zeile neu... ausserdem funktionsnamen und lokale variablen mit dem selben namen... hm find ich nicht so gluecklich... keine ahnung ob das probleme macht...
Hallo, // ist ein Kommentar von C++. Der C Standard erlaubt // als Kommentar erst ab ... (C99) ? Versuch mal /*#include ...*/ Gruß Olaf
holger schrieb:
> Dynamische Arrays können C Compiler glaube ich nicht ;)
C99 schon, und GCC auch im C89-Modus.
also beim compiler ist c99 eingestellt, die kommentare hab ich jetzt auch in der Form " /* */ " und "funktionsnamen und lokale variablen mit dem selben namen" hab ich nun auch beseitigt --> immer noch der fehler: ich zeig euch mal nen screenshot:
achja hab die header dateien wieder aus den kommentaren genommen, da es nix ändert
Hi, also Du verwendest Eclipse ... Eclipse interpretiert die Include-Direktiven auch, unabhängig vom Compiler. Wenn der Compiler (wie z. B. der GCC) Standard-Includepfade hat, kann er das akzeptieren, die IDE (Eclipse) meckert aber. Das verschwindet, wenn Du in den Projekteinstellungen den Pfad auf die Compiler-Standard-Includepfade inzufügst. Leider ist ja bei Deinen Screenshot nicht zu sehen, ob es in Compiler- oder ein IDE-Fehler ist. Gruß Olaf
1 | void send_data(unsigned int *p , unsigned int len){ |
2 | unsigned int send_data[len + 3]; |
Das dürfte - wie bereits gesagt - zu Problemen führen. Dynamischen Speicher holt man sich mit malloc. Anders gehts nciht, da der C Compiler den verwendeten Speicherplatz hier zur Compilezeit festlegen muss. Selbst, wenn der Compiler nicht meckern sollte, wird das Programm wohl nicht laufen :-) VG, /th.
Nach dem kompilieren klicke mal unten in Eclipse auf den Console-Tab. Dann poste den gesamten Inhalt. Das ist dort der "echte" Compiler/Linker-Output. Der ist interessant. Eclipse checkt die Syntax nochmal extra, d.h. das muß kein Syntaxfehler vom Kompiler sein. Ist es meiner Meinung nach auch nicht. Das sieht mir eher nach einer Meldung vom Eclipseparser aus. Warum der nun meckert.... jaaaa gute Frage. @Random: das dynamisch Array ist OK so (C99 hat er eingestellt).
Es ist trotzdem unsinnig, das so zu machen, denn so ist es kein echtes dynamisches Array, sondern ein statisches mit dynamischer Deklaration, denn len wird ja zur Laufzeit erst festgelegt. Das ist unsicheres Programmieren der Extraklasse! Sauber ist nur malloc() bzw. calloc() mit anschliessendem free() oder ein echtes statisches Array mit statischer Deklaration! Deklarationen von statischen Feldern mit Variablen macht man nur, wenn man die Feldgröße einfach vor dem Kompilieren ändern will, alles andere sollte der Ordnung halber mit alloc-Befehlen passieren.
Also malloc ist ziemlich teuer. Ein Array auf dem Stack anzulegen wenn ich es nur lokal in der Funktion brauche, ist durchaus eine gangbare Methode. Gruß Olaf
Zurück zum Ausgangspunkt: Was ist mit dieser Compiler-Meldung? Ein mögliches systematisches Vorgehen sähe folgendermaßen aus: 1. Den gesamten Inhalt der Funktion auskommentieren 2. Statement für Statement die Funktion mit Leben füllen Nach jedem einzelnen Schritt kompilieren. Das faule Statement ist dann dasjenige, welches als letztes aktiviert wurde. Welches Problem dieses Statement enthält, das ist dann ein viel späterer Schritt. @OP: Bitte mach das einmal! Teile uns anschließend das Ergebnis mit! Bernhard
C99 kennt solche Arrays mit nicht-konstanter Länge als lokale Variablen, und das ist durchaus effizient. Es wird dafür kein malloc() verwendet, sondern die landen genauso auf dem Stack wie andere lokale Variablen und verschwinden bei Rückkehr aus der Funktion ganz von selbst. Dieses Prinzip wird schon sein langer Zeit von der nicht standardisierten aber ziemlich verbreiteten Funktion alloca() verwendet. Ob sowas bei Mikrocontroller-Programmierung jeweils sinnvoll ist, ist eine andere Frage, immerhin sind da die Stacks nicht selten von begrenzter Grösse.
Die Variante mit einem Feld variabler Länge auf dem Stack ist nicht nur irgendwie effizienter als malloc+free, sondern wesentlich effizienter. Auch keinesfalls unsicherer, nur leider nicht von Anfnag im Standard, und deswegen kennen einige veraltete Compiler es nicht. Und natürlich ist der Stack begrenzt, der Heap aber doch genauso. In beiden Fällen muss man wissen, was man tut.
hallo leute, danke für die vielen tipps und auch belehrungen, ich weiß das das alles noch nicht ganz professionell ist, aber ich hab mich immerhin schon von atmel verabschiedet und versuch mich zu verbessern: aber nun nochmal zum thema: @ Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero) ich hab deinen tip mal probiert, dass mit den include pfaden bei den projekt einstellungen die display.c und .h sind jetzt beide im standard include verzeichnis und zack der fehler ist weg, aber nun ist ein error dafür da, jemand ne idee?, hatte den schonmal... achja: das hat mit der support von altium dazu geschrieben: Hi Stefan, Your case # 00108000: ARM, Eclipse Umgebung zeigt ungerechtfertigten Syntaxfehler an has recently been updated with the following comment: Hallo Herr Wackwitz, hierbei handelt es sich wahrscheinlich um ein bekanntes Problem. Folgender Issue existiert diesbezueglich: ------------------------------------------------------ ECLPS-37294 undeserved Eclipse syntax errors DESCRIPTION Eclipse shows syntax errors when using c166 specific qualifiers in the C/C++ editor. E.g. for the ":" sign within the inline assembly part and for the cast with a TASKING specific qualifier like __bit, __far etc. Example: __bit b1; __noalign struct { int x; } foo; int __far x; // syntax error __far int x; // OK? int out; void addone( void ) { __asm( "ADDB %0,#1" : "=b" (out) ); } void main(void) { b1 = (__bit)out; } Workaround: The syntax errors can be safely ignored. Or a temporary define can be added to undefine the qualifier, like #define __noalign ofcourse this define should be disabled when actually building the module.
Nein, ist er nicht: Bildformate Das sind alles keine Syntaxfehler, sondern irgendwas ist da im Makefile vergurkt. Es wird irgendeine Datei benötigt, die es nicht gibt, und für die das Makefile keine Regel enthält, wie sie zu erzeugen wäre. Mit einem Compilerfehler hat das alles nicht (mehr) die Bohne zu tun.
doch, denk ich schon, wenn ich die .c und .h wieder direkt ins projekt verzeichnis schiebe comiliert er wieder fehlerfrei zuende, aktuell bricht er sofort ab
so, alles läuft --> Olaf Dreyer (Firma: O.D.I.S.) (dreyero) hatte recht! Es ging nur grade nicht, da ich in error_memory.c noch "#include h:\...\display.h" stehen hatte, hab es jetzt in #include <display.h> geändert, jetzt läufts: also kurz: include pfad, welcher im projekt angegeben ist nutzen und da die .h reinpacken oder weiteren pfad angeben... DANKE AN ALLE!
Stefan Z. schrieb:
> bildformate?
Das ist ein Link, den du einfach verfolgen kannst.
Kurzfassung: JPEG für einen Screenshot ist Sche***e.
Bitte 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.