pgm_read_byte_far -> Invalid IValue in asm input

[Andi (Gast)]

Hallo,

leider finde ich trotz Recherche nicht die Lösung.
Ich lese aus dem Bootloder (ATMEGA128) das Flash mit pgm_read_byte_far 
aus.

IDE AS7 mit toolchain-3.6.2.1778 (gcc 5.4.0)

- uint32_t u32FlashAddr;
- uint8_t  u8data;
- u8data = pgm_read_byte_far(u32FlashAddr);

Es scheint auch zu funktionieren, allerdings bekomme ich die Meldung
-> Invalid IValue in asm input for constraint `I
Beim ATMEGA1281 mit gleichem Code und IDE erscheint keine Fehlermeldung.
Wer hat hier einen Rat?

Gruß Andi

[c-hater (Gast)]

Andi schrieb:

> - u8data = pgm_read_byte_far(u32FlashAddr);

> Wer hat hier einen Rat?

Das Problem steckt in dem Code, der den Inhalt von u32FlashAddr 
übergibt, er poppt hier nur auf, weil da die Parameterprüfung von 
pgm_read_byte_far zum Zuge kommt.

Irgendwas läuft da auf den 128 anders als auf dem 1281. Und zwar so 
anders, dass der Fehler schon zur Compilezeit über die Parameterprüfung 
erkennbar wird. Seltener Glücksfall übrigens. Hätte auch ein 
"unerkärlicher" Laufzeitfehler werden können...

[Oliver S. (oliverso)]

c-hater schrieb:
> Parameterprüfung von
> pgm_read_byte_far

Hm. Wer oder was soll denn da den Wert überprüfen?

Oliver

[c-hater (Gast)]

Oliver S. schrieb:

> Hm. Wer oder was soll denn da den Wert überprüfen?

Na der Scheiß, der letztlich dafür sorgt, dass diese Meldung erscheint:

-> Invalid IValue in asm input for constraint `I

Was sonst?

[Oliver S. (oliverso)]

"I" (_SFR_IO_ADDR(RAMPZ))

Wenn, dann ist da die io.h für den ATMega128 kaputt.

Oliver

[c-hater (Gast)]

Oliver S. schrieb:

> Wenn, dann ist da die io.h für den ATMega128 kaputt.

Das wäre wohl irgendwann in den vielen Jahren schonmal aufgefallen. Der 
AVR128 ist ja nun nicht gerade "bleeding edge"...

[Andi (Gast)]

Hmm ok und was bedeutet dies nun, verstehe es nicht ganz, wie gesagt es 
funktioniert ja oder ist dies nur Glück, muss ich mich um RAMPZ selbst 
kümmern?

[c-hater (Gast)]

c-hater schrieb:

> Das wäre wohl irgendwann in den vielen Jahren schonmal aufgefallen. Der
> AVR128 ist ja nun nicht gerade "bleeding edge"...

Sollte natürlich heißen: ATmega128. Aber dabei fällt mir was auf: geht 
es möglicherweise tatsächlich um einen AVR128D(irgendwas) und garnicht 
um einen ATmega128?

Das wäre natürlich ein game changer. Die sind recht neu, da wären Fehler 
im Support durch den Compiler durchaus noch zu erwarten.

[Rolf M. (rmagnus)]

c-hater schrieb:
> da wären Fehler im Support durch den Compiler durchaus noch zu erwarten.

Vor allem bei einem eher betagten  …

Andi schrieb:
> gcc 5.4.0

Allerdings wird das eher an der avr-libc liegen als am Compiler.

[Andi_T T. (andi_t)]

geht um den ATMEGA128A, beim ATMEGA1281 gib es keine Fehlermeldung, aber 
wie gesagt es scheint trotzdem zu funktionieren, bin mir nur unsicher ob 
dies auch immer gewährleistet ist.

[Oliver S. (oliverso)]

Irgend etwas stimmt an deinem Programm oder deiner Installation nicht.

Oliver

[HAL9000 (Gast)]

Hi !

Ich glaube da war doch mal irgendwas mit den Speicherzugriffen
beim MEGA128. Ich kann mich da gaanz dunkel dran erinnern.
Ich muß mal in meinen Laborbüchern baggern gehen....

[Andi_T T. (andi_t)]

Hmm ok, vielen Dank, ist echt schräg :(

[Oliver S. (oliverso)]

Kannst du denn mal ein echten Code zeigen und auch die komplette echte 
Fehlermeldung (die heisst mit Sicherheit anders)?
Auch die Aussage "es scheint zu funktionieren" ist komisch. Bringt der 
Compiler die Meldung als Warnung?

Solch aus dem Gedächtnis eingetippter Kram ist meistens am Ende ganz 
anders.

Ich habe hier nur einen avr-gcc 10.1, der und die mir vorliegende 
avrlibc compilieren pgm_read_byte_far für dem Mega128 ohne Probleme.
Ob Microchip da was an deren Versionen verbastelt hat, keine Ahnung.

Oliver

[Oliver S. (oliverso)]

Oliver S. schrieb:
> Irgend etwas stimmt an deinem Programm oder deiner Installation
> nicht.

Für Mega128:

gcc version 5.4.0 (AVR_8_bit_GNU_Toolchain_3.6.2_1778)

warning: variable 'u8data' set but not used [-Wunused-but-set-variable]

Build succeeded.
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Oliver

[c-hater (Gast)]

Oliver S. schrieb:

> warning: variable 'u8data' set but not used [-Wunused-but-set-variable]

Ja, logisch, wird ja tatsächlich nicht benutzt, jedenfalls nicht in 
gezeigtem Codefragment.

Einfach volatile deklarieren, dann muss sie der Compiler setzen und darf 
sich auch nicht mehr über die Nichtnutzung beschweren.

[Rolf M. (rmagnus)]

c-hater schrieb:
> Einfach volatile deklarieren, dann muss sie der Compiler setzen und darf
> sich auch nicht mehr über die Nichtnutzung beschweren.

Dürfen darf er schon, aber tun tut er es nicht.

[c-hater (Gast)]

Rolf M. schrieb:

> Dürfen darf er schon

Klares nein. Volatile zeigt an, dass der Inhalt ausserhalb des lokalen 
scope geändert/benutzt werden könnte.

Da der strohdummen Compiler aber eben nur diesen lokalen scope hat, muss 
er logischerweise davon ausgehen, dass das auch tatsächlich passiert, 
denn der Programmierer sagte es ihm explizit.

Dementsprechend darf er nicht seinen stark beschränktes Wissen von der 
Welt zum Anlass nehmen, schwachsinnige und nicht nachweisbar begründete 
Warnungen zu generieren. Tut er es doch, ist er kaputt.

So einfach ist das eigentlich.

[Rolf M. (rmagnus)]

c-hater schrieb:
> Rolf M. schrieb:
>
>> Dürfen darf er schon
>
> Klares nein.

Dem Compiler wird weder vorgeschrieben, noch verboten, bei Variablen, 
die nach der Definition nie verwendet werden, zu warnen. Und das ist 
ganz unabhängig davon, ob sie volatile sind. Allerdings kann es bei 
volatile-Variablen sinnvoll sein, bei den anderen bringt es eher nichts, 
also entscheidet sich der Compiler (aus freien Stücken), bei denen, die 
volatile sind, nicht zu warnen.

> Volatile zeigt an, dass der Inhalt ausserhalb des lokalen
> scope geändert/benutzt werden könnte.

Ich weiß, wofür volatile steht. Das hat aber nichts mit Warnungen zu 
tun.

[Andi_T T. (andi_t)]

Vielen Dank für die bisherige Unterstützung, anbei ein Ausschnitt aus 
dem Source Code die Meldung wird durch IntelliSense verursacht.

[Oliver S. (oliverso)]

Die ersten beiden Zeilen der Fehlermeldungen sind echte Fehler. 
Vielleicht solltest du die erst einmal beheben.

Ansonsten bleibe ich dabei: deine Installation ist kaputt.

Oliver

[Andi_T T. (andi_t)]

Die ersten Fehlermeldungen sind klar, wollte nur die Darstellung der 
Fehlermeldung nach dem Compilieren sehen/vergleichen.

Der ATMEGA1281 mit der gleichen Aktion und Installation erzeugt 
weiterhin keine Fehlermeldung ☹.

Trotzdem vielen Dank für den bisherigen Support.

[Oliver S. (oliverso)]

Da das ja nur Meldungen von Intellisense sind, kannst du die getrost 
ignorieren. Solange die toolchain nicht meckert, ist alles in Ordnung.

Oliver

[Andi_T T. (andi_t)]

Ok super, herzlichen Dank.
Gruß Andreas

[Peter D. (peda)]

Andi_T T. schrieb:
> Die ersten Fehlermeldungen sind klar

Dann beseitige sie erstmal.
Entweder klären sich die weiteren Fehler damit auch oder sind 
Folgefehler, weil der Parser aus dem Tritt kommt.

[Peter D. (peda)]

Oliver S. schrieb:
> Da das ja nur Meldungen von Intellisense sind, kannst du die getrost
> ignorieren.

Nö, es sind 7 Errors, d.h. solange wird kein Binary erzeugt.

[Markus F. (mfro)]

Vielleicht erst mal richtig lesen:

5 der 7 geposteten Fehlermeldungen kommen von einem anderen Projekt 
(sind also hier irrelevant).

Die zwei verbleibenden kommen von IntelliSense 
("Tipphilfe"/Syntaxchecker) und nicht vom gcc, der das eigentliche 
Binary produziert.

IntelliSense ist - meine ich - clang- (und eben nicht gcc-) basiert. 
D.h. es ist nicht dieselbe Engine, die da läuft, und die macht eben 
nicht alles ganz genauso wie gcc - insbesondere, wenn man sich 
ausserhalb des x86-Universums bewegt.