AVR64DD28 Clock Source ändern

[Max W. (crackerlino)]

Hallo liebes mikrocontroller.net-Forum,

ich versuche mich gerade durch den AVR64 zu fuchsen und es klappt mehr 
oder minder ganz okay. Ich versuche die Clockfrequenz zu ändern (von den 
urspr. 4 MHz auf 16 MHz) und muss dafür das ccp Register disablen. 
Jedoch finde ich leider nirgends, wie das funktioniert. In älteren Codes 
wird einfach CCP beschrieben. Das funktioniert leider nicht. Und CPU.CCP 
gibt es leider auch nicht, obwohl es in der "ioavr64dd28.h" erwähnt 
wird:

/* CPU.CCP  bit masks and bit positions */


Wo liegt mein Fehler? Und wieso gibt es verschiedene Versionen, von 
AVR-Code?


Liebe Grüße und lieben Dank im Voraus


MW

[S. L. (sldt)]

Also für einen AVR128Dx28 und in Assembler sieht es so aus:

 puti CPU_CCP,CPU_CCP_IOREG_gc
 puti CLKCTRL_OSCHFCTRLA,($6<<CLKCTRL_FREQSEL_gp) ; B:32, A:28, 9:24, 8:20, 7:16, 6:12, 5:8, 4:-, 3:4

In C müssen wohl die '_' in den Registernamen durch '.' ersetzt werden.

[S. L. (sldt)]

In C gibt es die Funktion '_PROTECTED_WRITE', siehe
Beitrag "Re: AVR ATtiny Stromaufnahme"

[Max W. (crackerlino)]

S. L. schrieb:
> Also für einen AVR128Dx28 und in Assembler sieht es so aus: puti
> CPU_CCP,CPU_CCP_IOREG_gc
>  puti CLKCTRL_OSCHFCTRLA,($6<<CLKCTRL_FREQSEL_gp) ; B:32, A:28, 9:24,
> 8:20, 7:16, 6:12, 5:8, 4:-, 3:4
> In C müssen wohl die '_' in den Registernamen durch '.' ersetzt werden.


Wie gesagt, CPU.CPP existiert bei mir zumindest nicht.

S. L. schrieb:
> In C gibt es die Funktion '_PROTECTED_WRITE', siehe
> Beitrag "Re: AVR ATtiny Stromaufnahme"


DANKE! Ich habe nur 'PROTECTED_WRITE' ausprobiert, aber nirgends 
gefunden. Woher weiß ich denn, dass diese Funktion existiert? Ich habe 
nichts im Datenblatt des AVR64DD28 gefunden.

Liebe Grüße und nochmals danke!

MW

[S. L. (sldt)]

> Woher weiß ich denn, dass diese Funktion existiert?

Kann ich auch nicht sagen, ich bekomme C-Spezifisches immer nur am Rande 
mit.

[Veit D. (devil-elec)]

Hallo,

Bsp.

CPU_CCP = CCP_IOREG_gc;        // write access for four CPU instructions
CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;  // select Source before prescaler set

[S. L. (sldt)]

Keine Ahnung, ob Ihnen das irgendetwas bringt, aber

#include <avr/io.h>
int main(void)
{
#include <avr/io.h>
int main(void)
{
  CPU_CCP = CCP_IOREG_gc;
  CLKCTRL.OSCHFCTRLA = (8<<CLKCTRL_FREQSEL_gp); // 9:24, 8:20, 7:16, 6:12, 5:8, 4:-, 3:4
  VPORTA_DIR = 0x80;
  while (1) VPORTA_IN = 0x80;
}
//  _PROTECTED_WRITE(CLKCTRL.OSCHFCTRLA, (8<<CLKCTRL_FREQSEL_gp));

wird bei mir für einen AVR128DB28 übersetzt und läuft, an PA7 messe ich 
3.33 MHz. Die Verwendung von '_PROTECTED_WRITE' ist natürlich bequemer 
und auch narrensicher.

[Veit D. (devil-elec)]

Hallo,

in meinen Notizen finde ich folgendes

CPU_CCP = CCP_IOREG_gc; // IO Register Protection
oder
CPU_CCP = CCP_SPM_gc;   // SPM Instruction Protection

Das Makro _PROTECTED_WRITE gibt es bei den AVR Dx nicht. Das wurde im 
Headerfile vergessen. Müßte man selbst nachrüsten.
Aus einem xmega Header rausgezogen.

#ifndef _PROTECTED_WRITE_SPM
#define _PROTECTED_WRITE_SPM(reg, value) \
  __asm__ __volatile__("out %[ccp], %[ccp_spm_mask]" "\n\t" \
                       "sts %[ioreg], %[val]"               \
                       :                                    \
                       : [ccp]          "I" (_SFR_IO_ADDR(CCP)), \
                         [ccp_spm_mask] "d" ((uint8_t)CCP_SPM_gc), \
                         [ioreg]        "n" (_SFR_MEM_ADDR(reg)), \
                         [val]          "r" ((uint8_t)value))
#endif

[S. L. (sldt)]

Ah, hallo Veit Devil!
  Können Sie mir vielleicht sagen, warum Registernamen in C mal mit '.' 
und mal mit '_' geschrieben werden?

Und eben fällt mir auf - auf welchem Controller läuft Ihr 
Beispielprogramm?

> Das Makro _PROTECTED_WRITE gibt es bei den AVR Dx nicht.
Also wie geschrieben, bei mir geht das, warum auch immer.

[Georg M. (g_m)]

> FREQSEL

1.9.119 (2021-07-20)
Renamed bitfield in CLKCTRL.OSCHFCTRLA from FREQSEL to FRQSEL.

https://packs.download.microchip.com/

[Veit D. (devil-elec)]

Hallo,

das '_' oder '.' hängt mit den Defines im Headefile zusammen.
So richtig sauber erklären kann ich es auch nicht aber ich versuche es. 
Es hängt mit dem Aufbau des Headerfiles zusammen ob es ein struct gibt 
oder nicht.

Bsp. AVR128DB48

#define DAC0_DATAH  _SFR_MEM8(0x06A3)

Hier ist DAC0_DATAH direkt als Registeradresse definiert.

Mit DAC0.DATAH läuft ein Makro ab der die Adresse aus Basis und Offset 
zusammensetzt.

Wie ich das anders erklären kann weiß ich im Moment leider nicht. Sonst 
müßte das Headerfile "zerlegen".

In dem Fall CPU_CPP hier liegt der Fall allerdings anders. Es gibt es 
kein Register namens CPU mit Basisadresse im Headerfile. Das heißt mit 
Namen wirklich CPU_CCP. Deswegen ist CPU.CPP nicht möglich.

AVR64DD28:

/* Ungrouped common registers */
#define CCP  _SFR_MEM8(0x0034)  /* Configuration Change Protection */
#define SP  _SFR_MEM16(0x003D)  /* Stack Pointer */
#define SPL  _SFR_MEM8(0x003D)  /* Stack Pointer Low */
#define SPH  _SFR_MEM8(0x003E)  /* Stack Pointer High */
#define SREG  _SFR_MEM8(0x003F)  /* Status Register */

Die sind im Headerfile sogar doppelt definiert  :-)

/* CPU - CPU */
#define CPU_CCP  _SFR_MEM8(0x0034)
#define CPU_SP  _SFR_MEM16(0x003D)
#define CPU_SPL  _SFR_MEM8(0x003D)
#define CPU_SPH  _SFR_MEM8(0x003E)
#define CPU_SREG  _SFR_MEM8(0x003F)

Wegen dem Protected Makro. Ich musste mir das einmal woher holen. :-)
Beitrag "xmega.h - _PROTECTED_WRITE_SPM"

Aktuell habe ich aus dem Thread hier oder für den Thread hier nichts 
getestet. Habe das aus meinem Projekten schnell rausgezogen.
Im AVR64DD28 Manual auf Seite 97 steht das für CPU_CPP der "Key" IOREG 
zuständig ist. Also die Gruppenbitmaske CCP_IOREG_gc wie du schon 
richtig geschrieben hast.

[S. L. (sldt)]

Danke, Veit Devil, für die Erklärung.

Übrigens: leichte Irritation hat, zumindest bei mir, der Betreff mit dem 
"Clock Source" verursacht - wenn ich es richtig verstanden habe, so 
möchte Max W. diese eben nicht ändern, so lediglich die Frequenz.

[Veit D. (devil-elec)]

Georg M. schrieb:
>> FREQSEL
>
> 1.9.119 (2021-07-20)
> Renamed bitfield in CLKCTRL.OSCHFCTRLA from FREQSEL to FRQSEL.
>
> https://packs.download.microchip.com/

Hallo,

solche Änderungen gab es öfters und hat sich langsam beruhigt. Manches 
war aus meiner Sicht Unsinnig und manches gut. Aktuell ist 2.2.253. Man 
könnte noch viel mehr Aufräumen und konsequenter mit den Namen sein. 
Beim Timer TCA bspw.. Ob die Unterscheidung SPLIT und SINGLE immer 
notwendig ist weiß ich nicht. Oder ob es schlau ist wie es ist. Die 
Prescaler Defines sind ja immer gleich. Aber das ist ein anderes Thema.

[Georg M. (g_m)]

Veit D. schrieb:
> Im AVR64DD28 Manual auf Seite 97 steht das für CPU_CPP

Ich kann das "CPU_CPP" nirgendwo finden.
Vielleicht muss ich zu Fielmann?

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR64DD32-28-Prelim-DataSheet-DS40002315B.pdf

[Veit D. (devil-elec)]

Hallo,

wenn Max nur den Prescaler abschalten möchte reicht

CPU_CCP = CCP_IOREG_gc;              
CLKCTRL_MCLKCTRLB = 0;  // no prescaler, disable prescaler

Danach hängt es nur von der Taktquelle ab die im OSCHFCTRLA Register 
konfiguriert wird. Seite 105. Defines im Headerfile Zeile 660.

Meine Zeile von 18:31 Uhr ist für den AVR DD falsch gewesen.

[Veit D. (devil-elec)]

Georg M. schrieb:
> Veit D. schrieb:
>> Im AVR64DD28 Manual auf Seite 97 steht das für CPU_CPP
>
> Ich kann das "CPU_CPP" nirgendwo finden.
> Vielleicht muss ich zu Fielmann?

Hallo,

nicht im Manual, im Headerfile. Nur was im Headerfile steht kann man 
nutzen. :-) Im Manual Seite 97 steht welche CPU Register Protected sind 
wofür man es erst "freischalten" muss.

Bei neuen uC muss man flexibel bleiben, weil manches im Manual noch 
nicht stimmt und deswegen auch "Preliminary" ist. Beim DD werden wohl 
auch noch paar Änderungen im Headerfile und irgendwann im Manual kommen. 
Das Update vom Manual vom DB hat ca. 2 Jahre gedauert.

[S. L. (sldt)]

> wenn Max nur den Prescaler abschalten möchte reicht ...

Dann hat er ja wieder die 4 MHz, von denen er aber wegwill.

Hier nochmals mein Programm (für einen AVR128DB28), diesmal ganz korrekt 
(ich bin heute abend etwas schwerfällig):

#include <avr/io.h>
int main(void)
{
  CPU_CCP = CCP_IOREG_gc;
  CLKCTRL.OSCHFCTRLA = 0b00011100;  // 16 MHz output

  VPORTA_DIR = 0x80;
  while (1) VPORTA_IN = 0x80;
}

Auf PA7 2.67 MHz, mal 6 ergibt die gewünschten 16 MHz.

[Veit D. (devil-elec)]

Hallo,

ist der TO noch da? Wenn du reinkommen möchtest empfehle ich dir die 
TBxxxx AppNotes, auch als Getting Startet bezeichnet. Da die Controller 
alle ähnlich aufgebaut sind kann man auch AppNotes der Verwandten nehmen 
und muss dann Kleinigkeiten ändern. Das Namenskaos wie hier im Thread 
ist nur am Anfang "Kaos", weil ggf. ungewohnt anders. Wenn man drin 
steckt wirkt es aufgeräumter. Da steckt wirklich eine Logik dahinter mit 
den Basisadressen und Offsets.

[Veit D. (devil-elec)]

S. L. schrieb:
>> wenn Max nur den Prescaler abschalten möchte reicht ...
>
> Dann hat er ja wieder die 4 MHz, von denen er aber wegwill.
>
> Hier nochmals mein Programm (für einen AVR128DB28), diesmal ganz korrekt
> (ich bin heute abend etwas schwerfällig):

Und ich springe "zu viel" zwischen den Manuals hin und her.  ;-)  Der 
AVRDD läuft also mit Default 4MHz. Wußte ich noch nicht. Hatte nur 
Prescaler im Kopf. Deine Konfig passt.  :-)

[S. L. (sldt)]

> Der AVRDD läuft also mit Default 4MHz.

Klar - beachten Sie den Reset-Wert von 0x0C, der schreibt eine 3 nach 
FRQSEL; und am Ende der Zeile steht es nochmal: 'default'.

Einen schönen Abend allerseits, mir langt's für heute.

[Veit D. (devil-elec)]

Hallo,

noch ein Tipp für die leidigen Microchip Manuals. Ein richtig guter PDF 
Konvertierer bzw. "Freischalter". Einstellungen können so bleiben. Nur 
wenn man mehrere pdf übergibt sollte man den Modus auf Einzeln ändern.
https://online2pdf.com/

[Randy B. (rbrecker)]

S. L. schrieb:
> Können Sie mir vielleicht sagen, warum Registernamen in C mal mit '.'
> und mal mit '_' geschrieben werden?

Veit D. schrieb:
> das '_' oder '.' hängt mit den Defines im Headefile zusammen.
> So richtig sauber erklären kann ich es auch nicht aber ich versuche es.

Echt?

Einmal sind es volatile uint8_t (wie VPORTA_DIR) und einmal sind es 
Aggregate (struct) (wie VPORTA). In C ist es definiert, das die Elemente 
eines Aggregats aufsteigend im Speicher platziert werden. Daher reicht 
es aus, wenn man die Startadresse auf bspw. VPORT_t castet, dann sind 
alle Elemente automatisch an der richtigen Adresse. Das nennt sich 
structure-mapping.

Hier mal das Beispiel mit VPORT aus der entsprechenden Header-Datei.

/* Virtual Ports */
typedef struct VPORT_struct
{
    register8_t DIR;  /* Data Direction */
    register8_t OUT;  /* Output Value */
    register8_t IN;  /* Input Value */
    register8_t INTFLAGS;  /* Interrupt Flags */
} VPORT_t;

#define VPORTA              (*(VPORT_t *) 0x0000) /* Virtual Ports */

/* VPORT (VPORTA) - Virtual Ports */
#define VPORTA_DIR  _SFR_MEM8(0x0000)
#define VPORTA_OUT  _SFR_MEM8(0x0001)
#define VPORTA_IN  _SFR_MEM8(0x0002)
#define VPORTA_INTFLAGS  _SFR_MEM8(0x0003)

Man sieht hier schön die entsprechend aufsteigende Adressvergabe.

[C-hater (c-hater)]

Max W. schrieb:

> DANKE! Ich habe nur 'PROTECTED_WRITE' ausprobiert, aber nirgends
> gefunden. Woher weiß ich denn, dass diese Funktion existiert? Ich habe
> nichts im Datenblatt des AVR64DD28 gefunden.

Das steht auch nicht im Datenblatt. Es handelt sich um eine 
Support-Funktion, die im Rahmen der gcc-Toolchain mitgeliefert wird.

#include <avr/xmega.h"

macht sie verfügbar.

Übrigens gibt es dort auch noch eine zweite Funktion für den Zugriff auf 
"SPM"-geschützte IO-Register (_PROTECTED_WRITE_SPM).

Das ist leider nötig, weil es Atmel/MC nicht für nötig befunden haben, 
in den Device-Headern mitzuteilen, ob und wie der Zugriff auf ein 
IO-Register geschützt ist. So bleibt es dem Programmierer überlassen, 
dies anhand des DB selber herauszufinden und dann ggf. die passende 
Funktion zu verwenden.

[Randy B. (rbrecker)]

C-hater schrieb:
> Das ist leider nötig, weil es Atmel/MC nicht für nötig befunden haben,
> in den Device-Headern mitzuteilen, ob und wie der Zugriff auf ein
> IO-Register geschützt ist. So bleibt es dem Programmierer überlassen,
> dies anhand des DB selber herauszufinden und dann ggf. die passende
> Funktion zu verwenden.

Och. lieber C-hater: Du bist doch sonst immer derjenige, der auf das 
Studium der DBer hinweist. Dort steht es doch klar drin. Und die 
Supportfunktion braucht es gar nicht. Man, was ist mit Dir los???

[Max W. (crackerlino)]

S. L. schrieb:
> Danke, Veit Devil, für die Erklärung.
>
> Übrigens: leichte Irritation hat, zumindest bei mir, der Betreff mit dem
> "Clock Source" verursacht - wenn ich es richtig verstanden habe, so
> möchte Max W. diese eben nicht ändern, so lediglich die Frequenz.

Richtig, ich dachte, ich müsse zuerst auf eine neue Clock umstellen, um 
die alte zu konfigurieren, war offenbar nicht notwendig.

Veit D. schrieb:
> CP

S. L. schrieb:
>> wenn Max nur den Prescaler abschalten möchte reicht ...
>
> Dann hat er ja wieder die 4 MHz, von denen er aber wegwill.
>
> Hier nochmals mein Programm (für einen AVR128DB28), diesmal ganz korrekt
> (ich bin heute abend etwas schwerfällig):#include <avr/io.h>
> int main(void)
> {
>   CPU_CCP = CCP_IOREG_gc;
>   CLKCTRL.OSCHFCTRLA = 0b00011100;  // 16 MHz output
>   VPORTA_DIR = 0x80;
>   while (1) VPORTA_IN = 0x80;
> }
> Auf PA7 2.67 MHz, mal 6 ergibt die gewünschten 16 MHz.


Ganz lieben dank! Hat sofort funktioniert. Und dass man das CCP Register 
mit CPU_CCP beschreiben kann ist sehr gut zu wissen. Ich habe leider 
gedacht, dass ich "CPU.CCP" wie es in der Header oder im Datenblatt 
beschreiben müsste.

C-hater schrieb:
> Max W. schrieb:
>
>> DANKE! Ich habe nur 'PROTECTED_WRITE' ausprobiert, aber nirgends
>> gefunden. Woher weiß ich denn, dass diese Funktion existiert? Ich habe
>> nichts im Datenblatt des AVR64DD28 gefunden.
>
> Das steht auch nicht im Datenblatt. Es handelt sich um eine
> Support-Funktion, die im Rahmen der gcc-Toolchain mitgeliefert wird.
>
> #include <avr/xmega.h"
>
> macht sie verfügbar.
>
> Übrigens gibt es dort auch noch eine zweite Funktion für den Zugriff auf
> "SPM"-geschützte IO-Register (_PROTECTED_WRITE_SPM).
>
> Das ist leider nötig, weil es Atmel/MC nicht für nötig befunden haben,
> in den Device-Headern mitzuteilen, ob und wie der Zugriff auf ein
> IO-Register geschützt ist. So bleibt es dem Programmierer überlassen,
> dies anhand des DB selber herauszufinden und dann ggf. die passende
> Funktion zu verwenden.

Also mein größeres Problem war, dass "CPU.CCP" im Datenblatt und im 
Header erwähnt werden, aber nicht existieren. Klar gibt es das CPU_CCP 
Register als #define, aber ich hatte ehrlich gesagt nicht auf dem 
Schirm, diese dafür zu benutzen. Wieder was gelernt.

Ganz lieben Dank für die ganzen Infos hier in dem Post. Hab' viel über 
den AVR gelernt!

[Georg M. (g_m)]

> CPU.CCP

"In the Datasheet "CPU.CCP" has to be set to "IOREG", respectevely to 
"0xD8" before enabling the Watchdog. For me just "CPU_CCP" worked. So 
instead of the dot, I had to use the underscore. Is that a mistake in 
the Datasheet?"
https://forum.arduino.cc/t/arduino-uno-wifi-rev-2-atmega4809-watchdog-always-restarts-whole-system/563521

"It seems like they forgot to add it into .h file."
https://electronics.stackexchange.com/questions/666241/why-is-nothing-happening-on-my-clkout-pin-despite-the-rtc-working-fine

[Randy B. (rbrecker)]

Georg M. schrieb:
> "It seems like they forgot to add it into .h file."

Es gibt im Header kein CPU_t, keine Struktur. Daher kann auch der 
member-access-operator nicht angewendet werden.

Es gibt einfach einen/zwei Schreibfehler in einem Kommentar des Headers:

/* CPU - CPU */
/* CPU.CCP  bit masks and bit positions */

/* CPU.SREG  bit masks and bit positions */

Kommentare sind halt Scheiße!

[C-hater (c-hater)]

Randy B. schrieb:

> Och. lieber C-hater: Du bist doch sonst immer derjenige, der auf das
> Studium der DBer hinweist.

Natürlich. Muss ich mich dafür schämen oder was?

> Und die
> Supportfunktion braucht es gar nicht.

Natürlich braucht man die nicht. Macht die Sache nur ein wenig 
komfortabler. Richtig komfortabel würde es aber eben nur dadurch werden, 
dass man sich überhaupt nicht darum kümmern müßte. Wenn also der 
Compiler automagisch alle diese write-protections adäquat behandeln 
würde.

Das wäre machbar, wenn halt in den Device-Headern des Herstellers die 
entsprechenden Informationen hinterlegt wären. Sind sie aber halt leider 
nicht. Die stehen nur im DB.

Im Übrigen würde ich es auch als Asm-Programmierer zu schätzen wissen, 
wenn ich das den Headern entnehmen könnte. Würde ich meine UIN- und 
UOUT-Macros ein wenig aufpeppen können und denselben Komfort 
erreichen...

[Georg M. (g_m)]

> Clock Source ändern

Apropos Clock Source ändern: nach dem Source-Wechsel - abwarten bevor es 
weiter gehen kann.

 _PROTECTED_WRITE(CLKCTRL.MCLKCTRLA, CLKCTRL_CLKSEL_OSC32K_gc);   // select
 while(CLKCTRL.MCLKSTATUS & CLKCTRL_SOSC_bm){}                    // wait

SOSC: Main Clock Oscillator Changing
The clock source for CLK_MAIN is undergoing a switch and will change as 
soon as the new source is stable.