aktuelle AVR µC - wdt.h - kein RAMPD / CTRL / Enable Bit

[Veit D. (devil-elec)]

Hallo,

irgendwie gibt es ein Problem mit der Unterstützung von neuen AVR 
Controllern im Zusammenhang mit dem Watchdog.
Probiert mit Atmega4809 und AVR128DB64, scheint ganze Familien zu 
betreffen.

in Microchip Studio

#include <avr/io.h>
#include <avr/wdt.h>

int main(void)
{
    wdt_disable();
    
    while (1) 
    {
    }
}

erzeugt

'RAMPD' was not declared in this scope; did you mean 'RAMPZ'?  
'WDT_CEN_bm' was not declared in this scope  
'WDT_CTRL' was not declared in this scope; did you mean 'WDT_CTRLA'?
'WDT_ENABLE_bm' was not declared in this scope; did you mean 'ADC_ENABLE_bm'?

Ich habe das Controller Headerfile und das Manual durchsucht. Es gibt 
kein Register namens RAMPD. Das Control Register lautet CTRLA und ein 
Enable Bit gibt es  nicht. Ich habe verschiedene Toolchains von mir 
probiert. Fehler bleiben.

Habe das mit der Arduino IDE probiert. Funktioniert, keine Fehler.
Habe das mit der Arduino IDE und meinen Toolchains probiert, wieder 
Fehler.

Also macht Arduino mit seinen mitgelieferten Toolchains irgendwas anders 
wie der Rest der Welt. In der wdt.h offenbart sich es, Arduino hat die 
wdt.h modifiziert. Die Datei hängt dran. Zu finden immer in der 
Toolchain  unter avr/include/avr. Wer unter Arduino nachschauen möchte
...\hardware\tools\avr\avr\include\avr

Kann jemand das Problem bestätigen? Kann das an zentraler Stelle 
korrigiert werden?

Edit:
In dem Atemzug könnte man gleich noch das fehlende "_PROTECTED_WRITE" 
Makro einbauen. Das steht für die Controller nicht zur Verfügung.

[Oliver S. (oliverso)]

Veit D. schrieb:
> erzeugt1'RAMPD' was not declared in this scope; did you mean 'RAMPZ'?
> …
> Ich habe das Controller Headerfile und das Manual durchsucht. Es gibt
> kein Register namens RAMPD.

Hm. Was genau erzeugt denn dann die Fehlermeldung?

Oliver

[Veit D. (devil-elec)]

Hallo,

na wenn der Code in wdt.h ein RAMPD usw. verlangt, aber es nicht 
existiert, erscheinen genau die Fehlermeldungen. Es passt alles 
zusammen.

[Oliver S. (oliverso)]

Veit D. schrieb:
> Hallo,
>
> na wenn der Code in wdt.h ein RAMPD usw. verlangt, aber es nicht
> existiert, erscheinen genau die Fehlermeldungen. Es passt alles
> zusammen.

Ich sags mal anders: Da die ganzen neuen AVRs ja nicht von der 
originalen avrlibc unterstützt werden, verwenden deine toolchains da 
eine abgewandelte Version. Genauso macht es Arduino, und auf github gibt 
es ja inzwischen einen gesamten Zoo davon.

Die Version, die du benutzt, ist kaputt.

RAMPD gibt es bei den XMegas, und die originale wdt.h berücksichtigt 
das.

Anscheinend laufen die neuen AVRs auch unter XMega, haben aber kein 
RAMPD, und damit das dann dann nicht knallt, gibt es die Ergänzung der 
wdt.h, die du oben zeigst (und die vermutlich nicht von Arduino ist, 
sondern von hier:
https://github.com/Florin-Popescu/avr-libc ).

Wer auch immer die neuen AVRs in die von dir verwendete avrlibc 
eingebaut hat, hat das ohne die notwendige Änderung in der wdt.h 
gemacht.

An denjenigen musst du dich wenden, damit das behoben wird.

Oliver
P.S. Früheren Beiträgen hier im Forum kann man entnehmen, daß du 
handgeklöpellte toolchains verwendest, weil die verfügbaren die neuen 
AVRs nicht unterstützten.

[Wilhelm M. (wimalopaan)]

Ein Blick in das Device-Pack von MicroChip offenbart:
die Mega0/Tiny1/Tiny2 sind xmega3, die da/db/dd sind xmega4.

[Wilhelm M. (wimalopaan)]

BTW: der NVM-Controller (wird ja auch oft geändert) wurde bis vor einige 
Zeit auch (noch) nicht von der avr-libc unterstützt. Wie es aktuell ist, 
weiß ich nicht, aber: be prepared ;-)

[Veit D. (devil-elec)]

Hallo,

nach Bau der Toolchain werden diverse fehlende Dateien aus den 
DevicePacks in die Toolchain kopiert. Das mit dem WDT fiel bisher nicht 
auf, weil ich WDT bis jetzt noch nie verwendet hatte bzw. ich musste 
damit noch nichts kompilieren. Erst dadurch fiel das jetzt erst auf. Ich 
dachte ja nun man könnte das zentral für alle "patchen". Wenn ich kurz 
überlege ... fällt mir Jörg ein.  :-)

Das Einfachste wäre aktuell für mich ich übernehme die Änderungen von 
Arduino bzw. Florin.

Wilhelm, wie hast du das gelöst? Auch so oder anders?

Übrigens, die Eingruppierung ob xmega2, 3 oder 4 hängt vom Flashspeicher 
ab. Das ist sehr individuell. Und bei 2 bis 8kB gibts noch die 
Unterscheidung in "short calls".

Das "NVM" PROTECTED_WRITE füge ich per extra Headerfile hinzu. Muss ich 
bei Bedarf inkludieren. Das müßte irgendwann auch zentral eingebaut 
werden.

Wenn man so drüber nachgedenkt schleppt man schon ganz schön viele Dinge 
mit sich rum. Momentan ist das für mich noch beherrschbar.  ;-)

[Wilhelm M. (wimalopaan)]

Veit D. schrieb:
> Wilhelm, wie hast du das gelöst? Auch so oder anders?

Ich benutze von der avrlibc mittlerweile im wesentlichen nur noch 
<math.h>. Von den Routinen für die interne Peripherie benutze ich 
nichts.
Ich habe vor einigen Jahren angefangen, für eine begrenzte Anzahl von 
AVR-Typen eine eigene header-only template-C++-Bibliothek (mittlerweile 
komplett c++20) zu schreiben, die sowohl die interne/externe Peripherie 
abstrahiert also auch einige std-lib-cpp Anteile realisiert. Die 
moderneren Serien die DA/DB/DD (zukünftig Ex) machen das recht 
übersichtlich, weil die Komponenten regulär(er) sind. Die alten AVRs 
sind ein Katastrophe.

[Oliver S. (oliverso)]

Wilhelm M. schrieb:
> Veit D. schrieb:
>> Wilhelm, wie hast du das gelöst? Auch so oder anders?
>
> Ich benutze von der avrlibc mittlerweile im wesentlichen nur noch
> <math.h>.

Im wesentlichen?

Du hast ein eigenes Linker Script mit eigenem Startup Code, für alle 
Prozessorfamilien? Und alle Register-Adressen nochmal selbst erfasst?

Oliver

[Wilhelm M. (wimalopaan)]

Oliver S. schrieb:
> Wilhelm M. schrieb:
>> Veit D. schrieb:
>>> Wilhelm, wie hast du das gelöst? Auch so oder anders?
>>
>> Ich benutze von der avrlibc mittlerweile im wesentlichen nur noch
>> <math.h>.
>
> Im wesentlichen?

Ja ;-) Ich wollte es nicht so absolut schreiben, weil ich da nicht zu 
100% sicher bin, ob sich doch noch irgendwo was verbirgt ;-)

> Du hast ein eigenes Linker Script mit eigenem Startup Code, für alle
> Prozessorfamilien?

Nein, das ist das vom avr-gcc.

> Und alle Register-Adressen nochmal selbst erfasst?

Ja, weil mein Code zu 99,9% CPP-Macro frei ist.

Insgesamt mag es eine Menge Arbeit erscheinen, aber da das über Jahre 
entstanden ist und man bei den modernen AVRs nur die Basisadresse ändern 
muss (wenn überhaupt), ist es doch überschaubar. Früher war es mit den 
alten Mega/Tiny viel schlimmer.

[Wilhelm M. (wimalopaan)]

Normalerweise werden meine Beiträge ja immer negativ bewertet ... muss 
ich das jetzt schon selbst machen?

[Wilhelm M. (wimalopaan)]

Wilhelm M. schrieb:
> Nein, das ist das vom avr-gcc.

... bzw. aus den Device-Packs von MicroChip, weil der offizielle avr-gcc 
ja nicht alle beinhaltet.

[Oliver S. (oliverso)]

Wilhelm M. schrieb:
>> Du hast ein eigenes Linker Script mit eigenem Startup Code, für alle
>> Prozessorfamilien?
>
> Nein, das ist das vom avr-gcc.

Da sag ich mal, deine Ansicht ist diskutabel...

Oliver

[Hugo H. (hugo_hu)]

MC-Studio nicht korrekt installiert oder eine alte Version (oder Deine 
"Ergänzungen" sind nicht so ganz kompatibel).

Shit in - shit out :-)

[Wilhelm M. (wimalopaan)]

Oliver S. schrieb:
> Wilhelm M. schrieb:
>>> Du hast ein eigenes Linker Script mit eigenem Startup Code, für alle
>>> Prozessorfamilien?
>>
>> Nein, das ist das vom avr-gcc.
>
> Da sag ich mal, deine Ansicht ist diskutabel...

Sorry für die "unpräzise" Antwort, hatte binutils und gcc zusammen 
geworfen:.
Linker-Script kommt aus den avr-binutils, Startup-Code aus den 
Device-Packs.

[neuer PIC Freund (Gast)]

> Arduino hat die wdt.h modifiziert. Die Datei hängt dran.

Das bezweifel ich. Die o.a. "Arduino_wdt.h" ist binär identisch zur 
"avr/wdt.h" von xc8 v2.31.

Und dein Programm von oben kompiliert ohne Probleme für den AVR128DB64 
unter MPLABX.

Vielleicht mixt du verschiedene Compiler Versionen.

[Peter D. (peda)]

Ich würde mal den AVR-GCC auf der Kommandozeile aufrufen. Dann sollten 
keine kastrierten Fehlermeldungen kommen, sondern vollständige mit 
Filename und Zeilennummer.

[Oliver S. (oliverso)]

Das Problem ist doch schon seit dem ersten Beitrag klar, die Lösung hat 
Veit ja auch direkt mitgeliefert.

Er muß jetzt einfach in seine toolchain die aktuelle wdt.h (z.B. aus der 
bei Arduino mitgelieferten avrlibc) reinkopieren, und alles wird gut.

Oliver

[Veit D. (devil-elec)]

Hallo,

genau so sieht es aus. Danke für die Unterhaltung.
Vielleicht findet Jörg irgendwann mal Zeit für ein Update.