mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Compiler - Fehler


Autor: Stefan Z. (derdespot)
Datum:

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

Autor: stive (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was hast du davor für ein code?

kannst du die ganze funktion posten?

Autor: Stefan Z. (derdespot)
Datum:

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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>void send_data(unsigned int *p , unsigned int len){
>  unsigned int send_data[len + 3];

Dynamische Arrays können C Compiler glaube ich nicht ;)

Autor: Justus Skorps (jussa)
Datum:

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

Autor: Stefan Z. (derdespot)
Datum:

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

Autor: 900ss D. (900ss)
Datum:

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

Autor: Stefan Z. (derdespot)
Datum:

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

Autor: gast (Gast)
Datum:

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

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

// ist ein Kommentar von C++.
Der C Standard erlaubt // als Kommentar erst ab ... (C99) ?
Versuch mal /*#include ...*/

Gruß

Olaf

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger schrieb:

> Dynamische Arrays können C Compiler glaube ich nicht ;)

C99 schon, und GCC auch im C89-Modus.

Autor: Stefan Z. (derdespot)
Datum:
Angehängte Dateien:

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

Autor: Stefan Z. (derdespot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
achja hab die header dateien wieder aus den kommentaren genommen, da es 
nix ändert

Autor: Maik Fox (sabuty) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich sind Fehler rot.
Unten steht "compiled successfully".

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

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

Autor: Random ... (thorstendb) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
void send_data(unsigned int *p , unsigned int len){
  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.

Autor: 900ss D. (900ss)
Datum:

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

Autor: Frank Bär (f-baer)
Datum:

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

Autor: Olaf Dreyer (Firma: O.D.I.S.) (dreyero)
Datum:

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

Autor: Bernhard R. (barnyhh)
Datum:

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

Autor: A. K. (prx)
Datum:

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

Autor: Klaus Wachtler (mfgkw)
Datum:

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

Autor: Stefan Z. (derdespot)
Datum:
Angehängte Dateien:

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

Autor: Stefan Z. (derdespot)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
der screenshot ist wohl besser

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Autor: Stefan Z. (derdespot)
Datum:

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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben, demnach ist was im Makefile oder im Compileraufruf vergurkt.

Autor: Stefan Z. (derdespot)
Datum:
Angehängte Dateien:

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber Bildformate hast du dir immer noch nicht angeguckt!

Autor: Stefan Z. (derdespot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bildformate?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Z. schrieb:
> bildformate?

Das ist ein Link, den du einfach verfolgen kannst.

Kurzfassung: JPEG für einen Screenshot ist Sche***e.

Autor: Stefan Z. (derdespot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
okay

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.