Forum: Compiler & IDEs Fehler beim Compilieren DMX Artnet AvrArtNode


von Thomas (powertools)


Lesenswert?

Hallo,
beim Compilieren des AvrArtNode 
(https://wiki-de.dmxcontrol-projects.org/index.php?title=Art-Net-Node_f%C3%BCr_25_Euro) 
mit avrdude unter Linux erhalte ich die folgende Fehlermeldung:
1
networkcard/enc28j60.h:165:23: Fehler: Variable »enc28j60_config« muss konstant sein, um mit »__attribute__((progmem))« in Nur-Lese-Abschnitt gelegt zu werden extern unsigned char enc28j60_config[] PROGMEM;

Kann mir jemand weiterhelfen, wie ich den Fehler beheben kann? Ich habe 
bereits versucht die Variable als const zu deklarieren, allerdings 
werden die Werte im eeprom gespeichert und können dort verändert werden, 
soweit ich das richtig nachvollzogen habe.

von Harald K. (kirnbichler)


Lesenswert?

Thomas schrieb:
> allerdings
> werden die Werte im eeprom gespeichert

"PROGMEM" sagt was anderes. Das ist das Flash-ROM, in dem auch der 
Programmcode steht.

von C-hater (c-hater)


Lesenswert?

Harald K. schrieb:

> "PROGMEM" sagt was anderes. Das ist das Flash-ROM, in dem auch der
> Programmcode steht.

So ist es. Allerdings ist die Erzwingung dieses "const" in neueren 
Compilerversionen IMHO sowieso grenzdebiler Schwachssinn. Denn natürlich 
ist auch der Flash zur Laufzeit schreibbar. Sobald diese Möglichkeit 
genutzt wird, könnte (zumindest theoretisch) der Code in Schwierigkeiten 
geraten. Die (erzwungene!) Deklaration sagt: const, der Compiler kann 
also von wirklich konstanten Daten ausgehen. Die sind aber halt u.U. 
nicht wirklich konstant...

Tja, gefühlt 100 Jahre alte Compiler-Konzepte sind halt ein wenig 
"unflexibel". Um das mal vorsichtig auszudrücken. Und die dauernde 
Flickschusterei rund um diese grundsätzlichen konzeptionellen Schwächen 
hat der inneren Logik der Sache natürlich auch nicht wirklich gut 
getan...

von Harald K. (kirnbichler)


Lesenswert?

C-hater schrieb:
> Allerdings ist die Erzwingung dieses "const" in neueren
> Compilerversionen IMHO sowieso grenzdebiler Schwachssinn.

Aber nur in Deiner kleinen Welt.

> Denn natürlich ist auch der Flash zur Laufzeit schreibbar.

Aber nicht mit einer simplen Zuweisung. Und daher ist "const" hier kein 
Schwachsinn, sondern sinnvoll.

> Und die dauernde
> Flickschusterei rund um diese grundsätzlichen konzeptionellen Schwächen
> hat der inneren Logik der Sache natürlich auch nicht wirklich gut
> getan...

Hast Du Dich in den letzten Tagen intensiv mit "moby" ausgetauscht, oder 
warum bist Du so drauf?

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

Thomas schrieb:
>
1
> networkcard/enc28j60.h:165:23: Fehler: Variable »enc28j60_config« muss 
2
> konstant sein, um mit »__attribute__((progmem))« in Nur-Lese-Abschnitt 
3
> gelegt zu werden extern unsigned char enc28j60_config[] PROGMEM;
4
>

Objekte mit Attribut "progmem" müssen als "const" deklariert werden.

Offenbar verwendest du Code, der für avr-gcc Version 4.7 (Release 2012) 
oder älter geschrieben wurde.


C-hater schrieb:
> Denn natürlich ist auch der Flash zur Laufzeit schreibbar.

Aber nicht über normale Zuweisungen.  Flash Schreiben geht nur über SFRs 
und evtl. spezielle Puffer.

> Sobald diese Möglichkeit genutzt wird, könnte (zumindest theoretisch)
> der Code in Schwierigkeiten geraten.

Nein. Noch nicht einmal theoretisch.

von Thomas (powertools)


Lesenswert?

Vielen Dank für alle Antworten und die Erklärung zu PROGMEM. Nachdem ich 
den Hinweis von Johann L.

>Objekte mit Attribut "progmem" müssen als "const" deklariert werden

überall angepasst habe, kann der Code kompiliert werden.

von C-hater (c-hater)


Lesenswert?

Johann L. schrieb:

> C-hater schrieb:
>> Denn natürlich ist auch der Flash zur Laufzeit schreibbar.
>
> Aber nicht über normale Zuweisungen.  Flash Schreiben geht nur über SFRs
> und evtl. spezielle Puffer.

[ ] Du kennst die neueren AVR8

Hinweis: Bei einigen davon ist der Flash sogar nur ausschließlich über 
ganz normale Schreiboperationen im SRAM-Bereich beschreibbar, bei 
etlichen anderen zumindest optional, zusätzlich zu der klassischen 
SPM-Methode.

Und generell gibt's den page buffer der klassischen AVR8 hier nicht 
mehr.

Ja, ist lösbar, aber erfordert halt schon wieder eine neue Windung in 
der unendlichen Spirale dieser unsäglichen C-Frickelei.

von C-hater (c-hater)


Lesenswert?

C-hater schrieb:
> Johann L. schrieb:
>
>> C-hater schrieb:
>>> Denn natürlich ist auch der Flash zur Laufzeit schreibbar.
>>
>> Aber nicht über normale Zuweisungen.  Flash Schreiben geht nur über SFRs
>> und evtl. spezielle Puffer.
>
> [ ] Du kennst die neueren AVR8
>
> Hinweis: Bei einigen davon ist der Flash sogar nur ausschließlich über
> ganz normale Schreiboperationen im SRAM-Bereich beschreibbar, bei
> etlichen anderen zumindest optional, zusätzlich zu der klassischen
> SPM-Methode.
>
> Und generell gibt's den page buffer der klassischen AVR8 hier nicht
> mehr.
>
> Ja, ist lösbar, aber erfordert halt schon wieder eine neue Windung in
> der unendlichen Spirale dieser unsäglichen C-Frickelei.

Nachdem im Thread

Beitrag "Re: Was ist mit dem avr-gcc 12.x passiert? Internal Compiler Errors"

wiederum die objektive Realität gnadenlos abgewürgt wurde, muß dazu kaum 
kaum noch etwas gesagt werden (der TO als williger Erfüllungsgehilfe der 
gleichgeschalteten Moderation). Oder auch: Moderation als williger 
Erfüllungsgehilfe des TO... Who knows...

Es gibt halt Leute, die die Realität nicht wahrhaben wollen oder können. 
Ist halt so, muß man mit leben, dass es auch sowas gibt...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.