xmega.h - _PROTECTED_WRITE_SPM

Arduino bastelt schon lange sein eigenes Zeug zusammen. Die Schöpfer des 
Projekts sind erfahrungsgemäß, naja, etwas eigenwillig und wenig 
kooperativ.

Davon abgesehen, dass ich auch endlich mal wieder einen avr-libc-Release 
machen müsste, ich sehe auch nichts in der Richtung auf Anhieb in den 
Bugs oder Patches, die bei avr-libc eingereicht worden sind. (Erst ist 
aber AVRDUDE mit einem Release dran. Für avr-libc muss ich außerdem noch 
die Patches von Johann ein wenig in ihre Einzelteile zerlegen.)

Hallo Jörg,

okay, kein Problem.

Ich konnte bis jetzt nicht herausfinden seit wann das 
_PROTECTED_WRITE_SPM Makro in der xmega.h unter Arduino enthalten ist. 
Wenn es nicht von dir ist muss es ja von Arduino sein. Einen originalen 
Arduino mit XMega kenne ich nicht.
Möglicherweise kam das Makro wegen dem Arduino Nano Every in die xmega.h 
rein der einen ATmega4809 drauf hat. Der ist ja ähnlich zum AVRxDB den 
ich aktuell in der Mache habe.
Genau weiß ich es allerdings nicht, ist nur eine Vermutung. Ich binde 
das fehlende Makro erstmal zusätzlich ein damit ich weitermachen kann.

Danke für die Antwort.

Veit D. schrieb:
> Möglicherweise kam das Makro wegen dem Arduino Nano Every in die xmega.h
> rein der einen ATmega4809 drauf hat.

Wäre eine Erklärung.

Hallo Jörg,

ich bin bei der Toolchain von Zakkemble fündig gewurden.
https://blog.zakkemble.net/avr-gcc-builds/
In der xmega.h bei ihm ist das _PROTECTED_WRITE_SPM enthalten.
Klickt man auf den Link "SVN with extras" > include > avr und klickt 
dann auf den Kommentar zur xmega.h, dann lese ich etwas von:
Add _PROTECTED_WRITE_SPM in xmega.h (as per Atmel's upstream 3.6.1).
Also müßte das demzufolge von Atmel stammen?

In Johann L. avr-gcc 10.0.0 Toolchain die ich noch habe ist das SPM 
Makro in seiner xmega.h nicht drin. Da ich davon ausgehe das Johann weiß 
was er tut muss das SPM Makro was spezielles sein.

Allerdings bin ich zufällig auf diesen Link gestoßen, wo davon die Rede 
ist.
https://savannah.nongnu.org/patch/?9543#comment10

Für die AVR DA/DB Serie gehört jedoch scheinbar noch mehr dazu.
https://www.avrfreaks.net/forum/avr128dx-eeprom-writing

Ich muss das noch näher durchleuchten, was genau gehauen und gestochen 
ist.
Soviel vielleicht als wichtige Info.

Für eine neue Release der avr-libc fehlen noch 2 wichtige Patches:

https://savannah.nongnu.org/bugs/?49567

https://savannah.nongnu.org/bugs/?57071

Und Patch #9864 revert, dieses Patch war veraltet, und die 
Funktionalität ist im Code von Bug 57071.

...und falls es jemand interessiert, 64-Bit Floating-Point ist ab 
avr-gcc v10+ nutzbar:

https://gcc.gnu.org/gcc-10/changes.html#avr

https://gcc.gnu.org/wiki/avr-gcc#Using_64-bit_long_double_without_proper_avr-libc

Und dann gibt's noch die Unterstützung für Devices der xmega3 Familie, 
was der Grund für den avr-libc3 Fork auf Github war. Diese Erweiterung 
macht man am einfachsten nach den o.g. Patches.

Hallo Johann,

Danke für die Informationen.

Johann L. schrieb:
> was der Grund für den avr-libc3 Fork auf Github war

Da cyblord nun wohl gerade dabei ist, AVRDUDE nach Github zu migrieren 
(also insbesondere die Bug-Datenbasis), wenn du sowieso schon ein Repo 
auf Github hast, dann wäre das möglicherweise der sinnvollere Weg, 
gleich dort weiter zu machen. (Was auch immer er da scriptet, sollte 
sich ja für die Bugs von avr-libc recyceln lassen.)

Beim Integrieren deiner Patches auf Savannah bin ich letztens irgendwann 
abgestorben.

Erstmal gibt's aber einen AVRDUDE-Release, denn der ist schon genauso 
lange überfällig.

Ein Repo hab ich dort nicht, und der Fork war/ist auch nicht von mir.

Hmm.

Schade.

Jörg W. schrieb:
> Beim Integrieren deiner Patches auf Savannah bin ich letztens irgendwann
> abgestorben.

Zuerst Revert von Patch 9864,  dann passt der Code von Issues 57071 und 
49567 ohne Konflikte.

Und erst dann den Xmega3-Patch. Der gibt Konflikte, aber weil Devices 
nicht mehr in configure(.ac) eingetragen werden, ist der Support 
einfacher als vorher. Einfach die Konflikte in configure(.ac) 
ignorieren.