Compiler - Fehler

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;
}

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

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

Eigentlich sind Fehler rot.
Unten steht "compiled successfully".

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.

der screenshot ist wohl besser

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!

Aber Bildformate hast du dir immer noch nicht angeguckt!

bildformate?

Stefan Z. schrieb:
> bildformate?

Das ist ein Link, den du einfach verfolgen kannst.

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

okay