[GELÖST] Sehr komischer Compiler-Fehler

Hallo Leute,

ich hab da mal ne Frage...

und zwar, im AVRStudio 4 hab ich folgenden Code:

Code:

---

#include <avr/io.h>
#define F_CPU 16000000
#include <util/delay.h>

int main(void)
{
DDRD |= (1 << PD6);
PORTD |= (1 << PD6);

 while(true)
 {
  PORTD  |= (1<<PD6);
  _delay_ms(500);
  PORTD  &= ~(1<<PD6);
  _delay_ms(500);
 }

 return 0;
}

---

beim kompilieren kommt diese Fehlermeldung:

Build started 26.8.2009 at 03:54:23
avr-gcc -mmcu=atmega128 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT MeinProjekt.o -MF dep/MeinProjekt.o.d -c ../MeinProjekt.c
../MeinProjekt.c: In function 'main':
../MeinProjekt.c:10: error: 'true' undeclared (first use in this function)
../MeinProjekt.c:10: error: (Each undeclared identifier is reported only once
../MeinProjekt.c:10: error: for each function it appears in.)
make: *** [MeinProjekt.o] Error 1
Build failed with 3 errors and 0 warnings...


Für mich bedeutet das, dass er die Variable true nicht kennt, ist das richtig?
Also es ging dann ohne Probleme als ich das true durch eine 1 ersetzt habe, aber es Verwundert mich schon stark

Ich hoffe ihr könnt mir da weiterhelfen

LG Pr0gm4n

versuchs mal mit einem #include <stdbool.h>, da drin sind true und false definiert

Es gibt in C die Schlüsselwörter "true" und "false" nicht. Und da du es auch selbst nirgendwo definiert hast, kennt der Compiler das dann natürlich nicht.

Wenn du ihm true vorher nicht definiert hast, dann kann er es auch nicht kennen. In C wird alles außer 0 als "wahr" angenommen. Dadurch ist es möglich Rückgabewerte von Funktionen ohne lästige extra Vergleiche auf 0 oder != 0 zu prüfen.

Ein
#define true 1 // und
#define false 0

könnte da bei dir Abhilfe schaffen. Aber wenn man das mit !=0 erstmal verinnerlicht hat, dann kommt man auch ohne true und false aus. Beachte bitte auch immer, dass C case sensitive ist.

sast

Hallo,

danke für die Antworten, ich war da von den RP6-Libraries etwas verwöhnt ja^^

Ok, werd ich mir wohl das 0 und 1 angewöhnen, auch wenn ich in der Schule mit java immer true hernehm^^

LG Pr0gm4n

Öh, ich würd mir 0 und eins nicht angewöhnen ...
Konvention ist wie schon geschrieben, dass alles was != 0 ist true ist.
Und anstelle selbst zu definieren bindet man dann besser stdbool.h ein, wie oben schon geschrieben wurde

mfG
Markus

Hi markus, ich meinte mit 0 und 1 angewöhnen dass ich in dem fall einfach immer while(1) schreibe anstatt wie früher while(true)

dass 2 und 3 genausosehr true sind ist eh klar...

LG Pr0gm4n

Naja, an true und false ist ja im Grunde nichts falsches. Im Gegenteil, meiner persönlichen Meinung nach tragen sie sehr zur Lesbarkeit des Sourcecodes bei, weshalb ich sie selbst ganz gerne verwende.

Und da stdbool.h Teil der C-Standardbibliothek ist, kann man davon ausgehen daß sie bei jedem halbwegs brauchbaren C-Compiler vorhanden ist.

Du musst dich also garnicht umgewöhnen ;-)


Sehr praktisch ist übrigens auch die Datei inttypes.h, da drin sind nämlich diverse Integer-Typen mit fester Größe definiert. Das ist sehr sinnvoll, da ein int auf verschiedenen Plattfomen auch unterschiedlich groß sein kann. Verwendet man die Integer-Typen aus inttypes.h hat man dieses Problem nicht, denn z.B. ein uint8_t ist auf jeder Plattform ein 8-Bit unsigned int, und ein int32_t entsprechend ein 32 Bit signed int.

Hallo Felix G,

ich hab da gleich noch ne Frage^^

Hat zwar nicht direkt was damit zu tun, aber ich habe bei Oben genanntem Code jetzt keinen Fehler mehr, hab das in den µC geladen und die LEDs fangen auch schön das blinken an... nur leider VIEL ZU SCHNELL ;-)

ich hab auch versucht durch änderung von F_CPU was zu erreichen, es ändert sich, ja aber nicht so wie es soll^^
weder bei 1, 4, 8, 16 noch 32 MHz funktioniert es richtig

Hast du/ihr eine Ahnung was ich da schon wieder falsch mache?

LG Pr0gm4n

Felix: Du meinst nicht zufällig "stdint.h" ;)

Pr0gm4n spontan sehe ich nix, hast du evtl. ne Null vergessen?
Ich habe in den Projekt-Einstellungen von AVR-Studio aber eine Einstellung für die Frequenz gefunden, evtl. überschreibt die dir dein F_CPU

mfG
Markus

Hallo markusj,

kannst du mir sagen wo genau du diese Einstellung gefunden hast?
EDIT: --> ok habs gefunden^^
aber das Feld iss standardmässig leer...

ich schreib mal was rein und teste jetz n bissl :-D



LG Pr0gm4n

EDIT2:

also

Code:

---

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
DDRD |= (1 << PD5);
PORTD |= (1 << PD5);
DDRD |= (1 << PD6);
PORTD  |= (1<<PD6);

_delay_ms(4000);

  PORTD  &= ~(1<<PD5);
  PORTD  &= ~(1<<PD6);
 while(1)
 {
 for(int i = 1; i<60;i++)
 {
  PORTD  |= (1<<PD6);
  _delay_ms(5);
  PORTD  &= ~(1<<PD6);
  _delay_ms(995);
 }

  PORTD  |= (1<<PD5);
  PORTD  |= (1<<PD6);
  _delay_ms(5);
  PORTD  &= ~(1<<PD5);
  PORTD  &= ~(1<<PD6);
  _delay_ms(995);
  }

 return 0;
}

---

das hier auf den Controller gepackt, 16000000 (16 Millionen) Hz im AVRStudio eingestellt und jo, das ding blinkt viel zu schnell^^

Aber immerhin ändert das jetzt mal die Blinkgeschwindigkeit, aber ich kann ja nicht so tun als wärn es 64MHz oder?^^

Auf dem Funk-Evaluationsboard von pollin.de ist für den ATMega 32 bzw. auch den ATMega16 ein 16MHz Quarz drin

Ach so toll^^
ich hab die Fuses ja nicht auf externes Quarz gestellt
ja jetz nochmal testen^^

So,

also die Fuses für clock auf 1111 und den CKOPT auf 0, jetzt sollte er eigentlich über das 16MHz quarz gehen...

aber mit dem oben genannten code sieht man eine LED dauerhaft leuchten und die die eig. bloß jede Minute leuchten sollte blinkt immer wieder^^

LG Pr0gm4n

Zitat:

---

Zitat von markusj

Felix: Du meinst nicht zufällig "stdint.h" ;)

---

In inttypes.h steht ganz oben ein #include <stdint.h>, und sie enthält noch ein paar zusätzliche Makros. Ob man diese Makros nun braucht oder nicht sei mal dahingestellt, jedenfalls ist die Datei ebenfalls Teil der C-Standardbibliothek und kann statt der stdint.h verwendet werden.

@Pr0gm4n
Bei deinem Blinkproblem kann ich dir nicht weiterhelfen, da ich delay_ms() noch nie verwendet habe. Stattdessen erzeuge ich mir grundsätzlich immer einen globalen 1ms-Takt mit einem der Timer, den ich als Basis für sämtliche Wartezeiten etc. verwende.

Hallo,

also ich hab mein "Blinkproblem" jetzt zum Glück gelöst, die _delay_ms kann man irgendwie nicht mit so großen werten verwenden oder so...

für 18 ms delay funktionierts so:

int a = 18;
while(a--)_delay_ms(1);

naja werd das auch mal auf timer oder so umstellen^^

LG Pr0gm4n


EDIT: ach ja übrigens, in der util/delay.h ist diese zeile hier zu finden:
#include <inttypes.h>

;-)