Bascom - C Umstieg Teil 1 - IDE-Probleme

[Marie L. (lendl)]

Hallo Kolleginnen und Kollegen,

wie in der Überschrift beschrieben bin ich gerade dabei von Bascom auf 
C/C++ unzusteigen.
Leider tauchen die ersten Probleme schon bei der Einrichtung der IDE 
auf.

Dieser Code fürt in 3 Verschiedenen IDEs zu unterschiedlichen 
Ergebnissen:
(ist jedes mal die gleiche Platine mit einem Atxmega128a4u (ohne 
externem Quarz) und einem AVRispMK2-Progammer)

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

int main(void)
{
   PORTC.DIR = PIN0_bm | PIN1_bm;
    while (1) 
    {
      PORTC.OUTSET = PIN0_bm;
      _delay_ms(10000);
      PORTC.OUTCLR = PIN0_bm;
      _delay_ms(10000);  
    }
}

Version 1:

Im Amtel Studio 7 (Version: 7.0.2542 - ) funktioniert der Code und der 
Port ist im Wechsel immer 10 Sec. an und aus
Unter ->Project ->Properties ->AVR/GNU C Compiler -> Symbos ist 
F_CPU=2000000 eingetragen
Aber eigentlich wollte ich unter Linux arbeiten...

Version 2:

Unter Linux habe ich Geany im Einsatz und es nach der Anleitung aus dem 
Ubuntuusers AVR Wiki eingerichtet.
Ich habe das Makefile aus dem Wiki kopiert und diese Werte angepasst:
MCU = atxmega128a4u
F_OSC = 2000000
Funktioniert auch, allerdings wechselt jetzt der Port alle 5 Sekunden 
den Zustand.
Muss ich hier noch irgendwas einstellen?

Version 3:

Code::Blocks habe ich unter Linux zusätzlich noch eingerichtet, da 
bekomme ich aber schon beim Kopilieren folgende Fehler:

In file included from /usr/include/math.h:43:0,
                 from /usr/lib/avr/include/util/delay.h:46,
                 from main.c:6:
/usr/include/bits/floatn.h:75:1: Fehler: Unbekannter Maschinenzustand »__TC__«
 typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
 ^
/usr/include/bits/floatn.h:87:9: Fehler: unbekannter Typname: »__float128«
 typedef __float128 _Float128;
         ^
In file included from main.c:6:0:
/usr/lib/avr/include/util/delay.h:112:3: Warnung: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" [-Wcpp]

Bisher würde mir ja Geany reichen, muss nicht Code::Blocks sein.
Ich möchte nur ungern unter Windows was machen, da das nur als VM läuft.
Vielleicht könnt Ihr mir ja helfen damit ich Geany und/oder Code::Blocks 
zum laufen kriege.

Vielen Dank vorab!

[Jörg W. (dl8dtl) (Moderator)]

Marie L. schrieb:

> F_OSC = 2000000

Vielleicht solltest du ja das Symbol hier auch F_CPU benennen? ;-)

Du müsstest auch eine Warnung bekommen haben dafür.

> Funktioniert auch, allerdings wechselt jetzt der Port alle 5 Sekunden
> den Zustand.

Default F_CPU ist halt 1 MHz (da das bei vielen der älteren AVRs der 
Auslieferungszustand ist).

> Code::Blocks habe ich unter Linux zusätzlich noch eingerichtet, da
> bekomme ich aber schon beim Kopilieren folgende Fehler:
>
> [code]
> In file included from /usr/include/math.h:43:0,
>                  from /usr/lib/avr/include/util/delay.h:46,

Das passt irgendwie nicht zusammen. Da werden Include-Dateien aus dem 
System benutzt (/usr/include). Da ist irgendwas beim Einrichten der 
AVR-Umgebung schief gegangen. Er müsste /usr/lib/avr/include/math.h 
benutzen.

[Marie L. (lendl)]

> Vielleicht solltest du ja das Symbol hier auch F_CPU benennen? ;-)

Habe ich gemacht, brachte aber keine Verbesserung.
Es sind immer noch 5 Sekunden statt 10.
Kann ich noch irgendwas überprüfen?

[Dirk B. (dirkb2)]

Marie L. schrieb:
> /usr/lib/avr/include/util/delay.h:112:3: Warnung: #warning "Compiler
> optimizations disabled; functions from <util/delay.h> won't work as
> designed" [-Wcpp]

Und die Optimierung einschalten.

[Jörg W. (dl8dtl) (Moderator)]

Marie L. schrieb:
> Kann ich noch irgendwas überprüfen?

Ja: ob das auch als -D Option an den Compiler überreicht wird.

Oder du schreibst das

#define F_CPU 2E6

halt direkt über dein

#include <util/delay.h>

Wenn deine IDE aber dafür noch eine -D Option generiert, bekommst du 
ggf. eine Warnung über die Mehrfachdefinition des Makros.

[Jörg W. (dl8dtl) (Moderator)]

Dirk B. schrieb:

> Und die Optimierung einschalten.

Das war ja ihre Option #3, während der Fehler, dass die Delay nur halb 
so lang wie gewünscht sind, bei ihrer Option #2 auftritt.

Aber ansonsten natürlich ein berechtigter Einwand.

[MWS (Gast)]

Marie L. schrieb:
> Unter Linux habe ich Geany im Einsatz

Evtl. als Alternative:
http://www.eclipse.org/downloads/packages/release/2021-03/r/eclipse-ide-cc-developers

[Marie L. (lendl)]

Jörg W. schrieb:
> Oder du schreibst das
> #define F_CPU 2E6
>
> halt direkt über dein
> #include <util/delay.h>

Hallo Jörg,

das hat funktioniert. Der Zustand wechselt jetzt im 10 Sekunden Takt.
Vielen Dank!

Somit habe ich mit Geany eine funktionierende Variante!

[Jörg W. (dl8dtl) (Moderator)]

Nur als Randbemerkung: das Design von <util/delay.h> ist vorsätzlich so 
gewählt worden, dass intern alles mit Gleitkommazahlen gerechnet wird 
(die zur Compilezeit dann völlig weg optimiert werden), sodass man bspw. 
halt Dinge schreiben kann wie

#define F_CPU 3.579e6 // Quarz mit 3,579 MHz

// ...

   _delay_us(23.5);

ausgehend von der Annahme, dass dies besser/einfacher lesbar ist als 
wenn du schreiben musst

#define F_CPU 3579000 // zähle die Nullen ;-)

  _delay_ns(23500);

Leider wurde beim Design von <util/setbaud.h> nicht darauf geachtet: 
dort muss F_CPU zu einem Integer-Argument auflösen. Falls du jemals 
diesen Header benutzen möchtest, musst du entsprechend darauf achten.

[Marie L. (lendl)]

Bleibt noch die Option mit Code::Blocks:

Dirk B. schrieb:
> Und die Optimierung einschalten.

Ich habe die Optimierung eingeschaltet und der Fehler:

Marie L. schrieb:
> /usr/lib/avr/include/util/delay.h:112:3: Warnung: #warning "Compiler
> optimizations disabled; functions from <util/delay.h> won't work as
> designed" [-Wcpp]

ist weg.

Allerdings bleiben die beiden anderen Fehler bestehen:

-------------- Build: Debug in test3 (compiler: GNU GCC Compiler for AVR)---------------

avr-gcc -Wall -mmcu=atxmega128a1u -DF_CPU=2000000UL -g -Os -I/usr/include -c main.c -o obj/Debug/main.o
avr-gcc -L/usr/lib -o bin/Debug/test3.elf obj/Debug/fuse.o obj/Debug/main.o  -mmcu=atxmega128a1u -Wl,-Map=bin/Debug/test3.map,--cref  
In file included from /usr/include/math.h:43:0,
                 from /usr/lib/avr/include/util/delay.h:46,
                 from main.c:5:
/usr/include/bits/floatn.h:75:1: Fehler: Unbekannter Maschinenzustand »__TC__«
 typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__)));
 ^
/usr/include/bits/floatn.h:87:9: Fehler: unbekannter Typname: »__float128«
 typedef __float128 _Float128;
         ^
Process terminated with status 1 (0 minute(s), 0 second(s))
2 error(s), 0 warning(s) (0 minute(s), 0 second(s))

Ich habe an einem Ersatz-Linux PC auch Code::Blocks installiert, dort 
tritt dieser Fehler nicht auf.
Wo könnte ich noch suchen?

[Jörg W. (dl8dtl) (Moderator)]

Marie L. schrieb:
> Wo könnte ich noch suchen?

Da musst du Leute fragen, die sich mit Code::Blocks auskennen, warum 
dort Anwendungs- und System-Header-Dateien in den (von Code::Blocks 
generierten) -I Optionen vermischt werden (-I/usr/include; auch 
-L/usr/lib ist Unfug, wenn man für einen AVR compiliert).

Vielleicht findest du solche Leute auch hier im Forum, aber 
möglicherweise nicht unter der von dir jetzt benutzten Überschrift.

[Marie L. (lendl)]

Hallo Jörg,

vielen Dank für den Hinweis. Ich werde bei Gelegenheit einen neuen 
Thread aufmachen.
Aber Du hast mir ja jetzt mit Geany schon sehr weitergeholfen und ich 
habe somit eine funktionierende IDE und kann anfangen C und C++ zu 
lernen.

ich denke da wird noch die ein oder andere Frage aufkommen... :-)

[Dirk B. (dirkb2)]

Marie L. schrieb:
> Ich habe die Optimierung eingeschaltet und der Fehler:
>
> Marie L. schrieb:
>> /usr/lib/avr/include/util/delay.h:112:3: Warnung:

Beachte bitte, das dies eine Warnung ist.
Das bedeutet, der Compiler versucht nocht etwas lauffähiges zu 
generieren.
Das Ergebnis kann aber falsch sein.

Behandele Warnungen wie Fehler - beseitige deren Ursache und setze den 
Warnlevel auf Maximum.

[Jörg W. (dl8dtl) (Moderator)]

Dirk B. schrieb:
> setze den Warnlevel auf Maximum

Ist hier egal, da die Warnung ja durch den Code selbst erzeugt wird 
(#warning).

Aber ansonsten natürlich generell ein guter Ratschlag.