missing ; behind __flash -> Was übersehe ich?

[Max B. (theeye)]

Hallo!

Ich versuche mich gerade an der Nutzung von __flash. Dazu habe ich den 
entsprechenden Teil hier im Tutorial-Bereich gelesen. 
AVR-GCC-Tutorial Abschnitt 14.2 ff.

Vermutlich habe ich nun einen kleinen aber feinen Fehler. Bei diesem 
Code:

static const __flash char strHund[] = "Hund";

meckert mein Compiler, "Missing ;". Er hätte hinter dem __flash gerne 
ein ";".

Wieso ist das so, was mache ich falsch?

Gruß Max

[Peter II (Gast)]

Max B. schrieb:
> Wieso ist das so, was mache ich falsch?

hast du auch eine aktuellen GCC?

[Max B. (theeye)]

Ich nutze in meiner Eclipse-Umgebung die AVR-Toolchain mit 
avr-gcc-4.8.1. Ab 4.7 sollte das doch funktionieren. Im Anhang meine 
Einstellungen.

Gruß Max

edit: hatte ein "*.png" vergessen...

[Bastler (Gast)]

Sourcefile als .c oder .C. Letzteres führt zum C++-Compiler und der 
versteht __flash nicht.

[Max B. (theeye)]

Bastler schrieb:
> Sourcefile als .c oder .C. Letzteres führt zum C++-Compiler und der
> versteht __flash nicht.

Super Tipp, "leider" habe ich überall brav "*.c" geschrieben. Sollte 
also nicht zum C++-Compiler führen.

Gruß Max

[Bastler (Gast)]

gnu99 oder gnu11 enabled?

[Max B. (theeye)]

Bastler schrieb:
> gnu99 oder gnu11 enabled?

gnu99 sollte eingerichtet sein. Einstelung im Anhang.

Gruß Max

[Bastler (Gast)]

Zur Compiler-Version: lass den mal mit -v gesprächig sein. Ich war schon 
überrascht, was dann wirklich ausgeführt wird.

[Max B. (theeye)]

Bastler schrieb:
> Zur Compiler-Version: lass den mal mit -v gesprächig sein. Ich war schon
> überrascht, was dann wirklich ausgeführt wird.

Im Anhang mal der gesamte output (mit codespezifischem Gemecker ;-) )
Hier der "Anfang":

19:53:25 **** Incremental Build of configuration Release for project lcdHM1 ****
make all 
Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -Wall -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -std=gnu99 -v -mmcu=atmega8 -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"
Using built-in specs.
COLLECT_GCC=avr-gcc
Target: avr
Configured with: /data2/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/src/gcc/configure LDFLAGS=-L/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86/lib CPPFLAGS= --target=avr --host=i686-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86 --libdir=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86/lib --enable-languages=c,c++ --with-dwarf2 --enable-doc --disable-shared --disable-libada --disable-libssp --disable-nls --with-avrlibc=yes --with-mpfr=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86 --with-gmp=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86 --with-mpc=/home/toolsbuild/jenkins-knuth/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86 --enable-fixed-point --with-pkgversion=AVR_8_bit_GNU_Toolchain_3.4.3_1072 --with-bugurl=http://www.atmel.com
Thread model: single
gcc version 4.8.1 (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 
COLLECT_GCC_OPTIONS='-Wall' '-Os' '-fpack-struct' '-fshort-enums' '-ffunction-sections' '-fdata-sections' '-std=gnu99' '-funsigned-char' '-funsigned-bitfields' '-std=gnu99' '-v' '-mmcu=atmega8' '-D' 'F_CPU=1000000UL' '-MMD' '-MP' '-MF' 'main.d' '-MT' 'main.d' '-c' '-o' 'main.o'
Finished building: ../main.c

Sieht für mich so aus, als hätte ich hier die gcc version 4.8.1 und, 
dass die Option -std=gnu99 auch ausgeführt wird.

Gruß Max

edit: Im Anhang mal ein Bild, wie die Meldung in der Realität aussieht.

[Stefan E. (sternst)]

Max B. schrieb:
> edit: Im Anhang mal ein Bild, wie die Meldung in der Realität aussieht.

Welche Rolle sollen die Zeilen hinter dem Fehler spielen?
Was bei Fehlern (insbesondere "Missing ;") von Interesse ist, sind die 
Zeilen DAVOR.

Edit:
> Im Anhang mal der gesamte output
Und da ist von dem Fehler nichts zu sehen.
Der wird doch sicher nur von der IDE generiert, weil dessen 
Syntax-Analyse mit dem __flash nichts anfangen kann.

[Bastler (Gast)]

Ja klar, schon wieder drauf rein gefallen. Eclipse fehlt leider der 
"versteh auch AVR GCC Extensions"-Schalter. Ich hab mir angewöhnt nur 
der Konsolenausgabe zu glauben. Wenn die sägt OK, dann Eclipse 
ignorieren.

[Max B. (theeye)]

Stefan Ernst schrieb:
> Welche Rolle sollen die Zeilen hinter dem Fehler spielen?
> Was bei Fehlern (insbesondere "Missing ;") von Interesse ist, sind die
> Zeilen DAVOR.
Da gebe ich dir recht. Allerdings macht hier nur der gezeigte Code 
etwas. Vorher befinden sich Funktionen für das Programm indem ich 
__flash nutzen möchte. Nur der gezeigte Code wird ausgeführt. Kann das 
sonst auch noch weiter herunterbrechen.

Bastler schrieb:
> Ja klar, schon wieder drauf rein gefallen. Eclipse fehlt leider der
> "versteh auch AVR GCC Extensions"-Schalter. Ich hab mir angewöhnt nur
> der Konsolenausgabe zu glauben. Wenn die sägt OK, dann Eclipse
> ignorieren.
Oh, na dann liegt der Fehler wohl bei mir. Vermutlich also in der 
Funktion für die Ausgabe (lcd_string). Ich schau mal rein und melde mich 
dann wieder.

Danke schonmal!

Gruß Max

[Bernd M. (bernd_m)]

Du hast die Möglochkeit unter project->properties->... das Symbol 
__flash zu definieren, und zwar zu nichts. Dann ersetzt eclipse das 
__flash mit "" und liefert kein Fehler mehr. ("" = nix, also wirklich 
leer).

Gruss,
Bernd

[Max B. (theeye)]

Bernd M. schrieb:
> Du hast die Möglochkeit unter project->properties->... das Symbol
> __flash zu definieren, und zwar zu nichts. Dann ersetzt eclipse das
> __flash mit "" und liefert kein Fehler mehr. ("" = nix, also wirklich
> leer).

Klingt gut! Werde ich die Tage mal testen :)

Gruß Max

[Panda (Gast)]

For each named address space supported by avr-gcc there is an equally 
named but uppercase built-in macro defined. The purpose is to facilitate 
testing if respective address space support is available or not:

Versuch mal:

#ifdef __FLASH
static const __flash char strHund[] = "Hund";
#endif

[Max B. (theeye)]

Panda schrieb:
> Versuch mal:#ifdef __FLASH
> static const __flash char strHund[] = "Hund";
> #endif

Kann ich auch mal machen. Bin aber zur Zeit nicht zu Hause.

Ich vermute den Fehler allerdings, wie gesagt, in der 
lcd_string-Funktion. Ich nutze die Bibliothek hier von 
mikrocontroller.net aus dem AVR-GCC-Tutorial/LCD-Ansteuerung.

Hier die Code-Ausschnitte:

//aus lcd-routines.h
[...]
// Ausgabe eines Strings an der aktuellen Cursorposition 
void lcd_string( const char *data );
[...]

//aus lcd-routines.c
// Schreibt einen String auf das LCD
 
void lcd_string( const char *data )
{
    while( *data != '\0' )
        lcd_data( *data++ );
}

Ich denke der Übergabeparameter der Funktion müsste so deklariert 
werden:

//aus lcd-routines.h
// Ausgabe eines Strings an der aktuellen Cursorposition 
void lcd_string( const char __flash *data );

Gruß Max

[Karl H. (kbuchegg)]

Max B. schrieb:

> Ich denke der Übergabeparameter der Funktion müsste so deklariert
> werden:

Nope.
Du wirst 2 Funktionen brauchen.
Die eine String Funktion wie bisher: Argument ist ein Pointer ins SRAM
Die andere Funktion ist codetechnisch fast identisch. Einziger 
UNterschied: Argument ist ein __flash Pointer.

Ein normaler Pointer und ein Pointer ins Flash sind nicht dasselbe.

[Max B. (theeye)]

Karl Heinz schrieb:
> Nope.
> Du wirst 2 Funktionen brauchen.
> Die eine String Funktion wie bisher: Argument ist ein Pointer ins SRAM
> Die andere Funktion ist codetechnisch fast identisch. Einziger
> UNterschied: Argument ist ein __flash Pointer.
>
> Ein normaler Pointer und ein Pointer ins Flash sind nicht dasselbe.

Entschuldigung, ich habe mich unklar ausgedrückt. Wie du schon sagtest, 
werde ich neben der bisherigen Funktion lcd_string noch die Funktion 
lcd_string_F brauchen:

void lcd_string_F( const char __flash *data );

Hier ist dann ein __flash-Pointer das Argument.

:-)

Gruß Max

[Stefan E. (sternst)]

Karl Heinz schrieb:
> Nope.
> Du wirst 2 Funktionen brauchen.

Nicht zwangsläufig.
Er kann es auch einfach so machen:

void lcd_string ( const char __memx *data )

[Max B. (theeye)]

Stefan Ernst schrieb:
> void lcd_string ( const char __memx *data )

Was sind hier Vor-/Nachteile (außer, dass ich keine extra-Funktion 
brauche)?

Hintergrundinfos:
> *__memx*
> This is a 24-bit address space that linearizes flash and RAM: If the
> high bit of the address is set, data is read from RAM using the lower
> two bytes as RAM address. If the high bit of the address is clear, data is read 
from flash with RAMPZ set according to the high byte of the
> address. See __builtin_avr_flash_segment.
>
> Objects in this address space are located in .progmemx.data.
Quelle: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html
Dort steht auch noch mehr zu __flash

Gruß Max

[Karl H. (kbuchegg)]

Max B. schrieb:
> Stefan Ernst schrieb:
>> void lcd_string ( const char __memx *data )
>
> Was sind hier Vor-/Nachteile (außer, dass ich keine extra-Funktion
> brauche)?

Theoretisch ist die Variante ein kleines bischen langsamer, was aber bei 
einer LCD Ausgabe so gut wie keine Rolle spielt.

[Max B. (theeye)]

Bernd M. schrieb:
> Du hast die Möglochkeit unter project->properties->... das Symbol
> __flash zu definieren, und zwar zu nichts. Dann ersetzt eclipse das
> __flash mit "" und liefert kein Fehler mehr. ("" = nix, also wirklich
> leer).

Wenn ich es richtig gemacht habe, dann hat es nicht geklappt. Eventuell 
habe ich etwas falsch gemacht? Näheres als Bilder im Anhang. Hätte es 
gerne so, dass Eclipse nicht (fälschlicherweise) meckert.

Panda schrieb:
> Versuch mal:#ifdef __FLASH
> static const __flash char strHund[] = "Hund";
> #endif

Habe ich jetzt nicht gemacht, weil:

Max B. schrieb:
> void lcd_string_F( const char __flash *data );

So funktioniert es blendend!

Stefan Ernst schrieb:
> void lcd_string ( const char __memx *data )

So auch!

Gruß Max

[Bastler (Gast)]

Das PerProcessorSymbol __FLASH ist wohl eher dazu da, zu prüfen ob der 
Compiler das auch unterstützt. Und ggf. mit #error zu melden, daß nicht.
Oder eben 2 Versionen SourceCode zu haben, nur dann kann man gleich beim 
alten bleiben, bis ein zukünftiger GCC diese mal nicht mehr unterstützt 
(-> nie?). Denn auf die Daten im Flash wird man ja kaum verzichten, 
oder?
Das Keyword __flash per -D an den Compiler "wegzudefinieren" ist auch 
nicht gut. Denn es wird ja gebraucht. Vermutlich (grad kein Eclipse aufm 
iPad) gibt's das speziell für die CDT Syntaxerkennung. Ich hatte mir mal 
angeschaut, wie man das offiziell machen kann, aber dazu muß man ein 
passendes Plugin schreiben, daß die zusätzliche Syntax richtig versteht. 
Sah nach viel Aufwand für etwas weniger unbequem aus, aber vielleicht 
kennt ja jemand eine Lösung. Oder verwenden hier alle MS-AVR-Studio?