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
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. 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. 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"...
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 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.
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.
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.
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....
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. 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
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.
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.
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.
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.
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
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.
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.
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.
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.
