AVR128, CCP und Optimierung

[Cyblord -. (cyblord)]

Hallo Zusammen,
ich programmiere gerade für einen AVR128DA32.

Hier kann man die Clock Settings nur anpassen wenn vorher der CCP 
Register mit einem bestimmten Wert beschrieben wird, und danach 
innerhalb von 4 Clockzyklen kann dann die Clock Einstellung geschrieben 
werden.

Habe nun bemerkt dass dies mit Optimierung -O0 nicht funktioniert.
Das ASM listing zeigt auch warum. Es vergehen mehr als 4 Zyklen bevor 
CLKCTRL_OSCHFCTRLA geschrieben wird.

Meine Frage ist nun warum. Warum wird ohne Optimierung erst ein anderes 
Registerpaar mit der Adresse geladen und danach in Z kopiert.
Und d.h. mit O0 kann man die Clocksettings in C nicht umstellen und 
müsste evt. händisch ASM Befehle einfügen?

CCP=0xD8;
CLKCTRL_OSCHFCTRLA=0x24;

CCP=0xD8;
     a7e:  84 e3         ldi  r24, 0x34  ; 52
     a80:  90 e0         ldi  r25, 0x00  ; 0
     a82:  28 ed         ldi  r18, 0xD8  ; 216
     a84:  fc 01         movw  r30, r24
     a86:  20 83         st  Z, r18
  CLKCTRL_OSCHFCTRLA=0x24;
     a88:  88 e6         ldi  r24, 0x68  ; 104
     a8a:  90 e0         ldi  r25, 0x00  ; 0
     a8c:  24 e2         ldi  r18, 0x24  ; 36
     a8e:  fc 01         movw  r30, r24
     a90:  20 83         st  Z, r18

PS:
Mit Optimierung (Os) wird aus den 5 Zeilen vorher um eine Konstante zu 
schreiben ein 2 Zeiler:

198:  88 ed         ldi  r24, 0xD8  ; 216
19a:  84 bf         out  0x34, r24  ; 52

[Wilhelm M. (wimalopaan)]

Gute Frage, wobei ich selbst noch nie Probleme damit hatte. Vielleicht 
hat Johann ja recht, dass das AVR-Backend einfach mit der Zeit 
vergammelt.

Welchen gcc  nimmst Du denn?

[Wilhelm M. (wimalopaan)]

Cyblord -. schrieb:
> Hier kann man die Clock Settings nur anpassen wenn vorher der CCP
> Register mit einem bestimmten Wert beschrieben wird, und danach
> innerhalb von 4 Clockzyklen kann dann die Clock Einstellung geschrieben
> werden.

Stimmt nicht ganz: 4 Instruktionen.

[Wilhelm M. (wimalopaan)]

Cyblord -. schrieb:
> Habe nun bemerkt dass dies mit Optimierung -O0 nicht funktioniert.

Sorry, das habe ich jetzt erst gelesen: -O0 schaltet fast alle 
Optimierungen ab. Also, was willst Du erwarten. Ab -O oder -O1 ist alles 
so wie es sein soll.

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Cyblord -. schrieb:
>> Habe nun bemerkt dass dies mit Optimierung -O0 nicht funktioniert.
>
> Sorry, das habe ich jetzt erst gelesen: -O0 schaltet fast alle
> Optimierungen ab.

Das ist bekannt. Erklärt für mich aber nicht warum hier derart unnötige 
Operationen eingefügt werden.

> Also, was willst Du erwarten. Ab -O oder -O1 ist alles
> so wie es sein soll.

Ich hätte erwartet dass es für die Zuweisung einer Konstanten an eine 
Speicherstelle, auch ohne Optimierung, eine bessere Umsetzung gibt.
Hier ist ja kein Optimierungsbedarf im eigentlichen Sinne. Selbst wenn 
kein OUT verwendet werden würde, könnte man mit 3 Instruktionen (Z 
Pointer laden + STORE) jede Speicherstelle beschreiben.

[Wilhelm M. (wimalopaan)]

Bei mir wird aus

#include <cstdint>
#include <mcu/avr.h>
#include <mcu/internals/ccp.h>
#include <mcu/internals/clock.h>

using ccp = AVR::Cpu::Ccp<>;
using clock = AVR::Clock<>;

int main() {
    ccp::unlock([]{
        clock::prescale<2>();
    });
}

dann mit -O1 und gcc 10.3.0 oder 12.0.0

__CCP__ = 0x34
.text
.type   main, @function
main:
ldi r24,lo8(-40)         ;  tmp44,
out __CCP__,r24  ;  MEM[(volatile value_type &)48B + 4], tmp44
ldi r24,lo8(1)   ;  tmp46,
sts 97,r24       ;  MEM[(struct ControlRegister *)96B + 1B].hwRegister, tmp46
ldi r25,0                ;
ldi r24,0                ;
ret

Und bei -O0 willst Du es gar nicht wissen ;-) (s.a. Anlage)

Ich sehe überhaupt keinen Sinn darin, mit -O0 zu compilieren.

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Ich sehe überhaupt keinen Sinn darin, mit -O0 zu compilieren.

Macht ja nichts. Aber manchmal will oder muss man. Ich finde es nur 
interessant das dann die 4 zugebilligten Instruktionen des CCP gerissen 
werden.

[Wilhelm M. (wimalopaan)]

Cyblord -. schrieb:
> Wilhelm M. schrieb:
>> Ich sehe überhaupt keinen Sinn darin, mit -O0 zu compilieren.
>
> Macht ja nichts. Aber manchmal will oder muss man.

Ich will und musste es nie ...

> Ich finde es nur
> interessant das dann die 4 zugebilligten Instruktionen des CCP gerissen
> werden.

Dieses semantische Constraint ist im backend nicht drin. Wie schon 
gesagt: es gammelt vor sich hin und fliegt bald raus.

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Cyblord -. schrieb:
>> Wilhelm M. schrieb:
>>> Ich sehe überhaupt keinen Sinn darin, mit -O0 zu compilieren.
>>
>> Macht ja nichts. Aber manchmal will oder muss man.
>
> Ich will und musste es nie ...

Das ist sehr schön für dich.

[Harry L. (mysth)]

Wickel den Code-Abschnitt doch in Pragmas ein!

z.B. so:

#pragma GCC push_options
#pragma GCC optimize ("O1")

// critical code

#pragma GCC pop_options

[Oliver S. (oliverso)]

Cyblord -. schrieb:
> Macht ja nichts. Aber manchmal will oder muss man. Ich finde es nur
> interessant das dann die 4 zugebilligten Instruktionen des CCP gerissen
> werden.

Das dich das überrascht zeigt, daß du anscheinend das allerstemal mit 
einem AVR und dem gcc dazu zu tun hast.

Diese 4-Zyklen-Absicherung gibts bei allen AVRs für verschiedene 
Einstellungen, und das hat der gcc noch nie ohne Optimierung geschafft. 
Über das wieso, weshalb, warum zu sinnieren ist zweckfrei, wie alle 
solche Fragen darüber, warum ein Compiler etwas so macht, wie er es 
macht. Ist halt so.

Und weil das so ist, gibts in der avrlibc dafür Hilfsfunktionen (in 
Assembler), die einem diese Sorge abnehmen.

Für die nicht berücksichtigten Fälle muß man sich die dann halt selber 
schreiben.

Oliver

[Cyblord -. (cyblord)]

Oliver S. schrieb:
> Cyblord -. schrieb:
>> Macht ja nichts. Aber manchmal will oder muss man. Ich finde es nur
>> interessant das dann die 4 zugebilligten Instruktionen des CCP gerissen
>> werden.
>
> Das dich das überrascht zeigt, daß du anscheinend das allerstemal mit
> einem AVR und dem gcc dazu zu tun hast.

Beileibe nicht.

> Diese 4-Zyklen-Absicherung gibts bei allen AVRs für verschiedene
> Einstellungen, und das hat der gcc noch nie ohne Optimierung geschafft.

Nicht übertreiben. Lange nicht bei allen. Ich arbeite bisher vorwiegend 
mit dem ATTiny841. Dort gibts das noch nicht und auch bei keinen der 
Vorgänger. Auch nicht bei Megas der gleichen oder Vorgängergeneration. 
Das ist ein recht neues Feature der aktuelleren AVRs.
> Für die nicht berücksichtigten Fälle muß man sich die dann halt selber
> schreiben.

Was hier auch kein Problem darstellt. Das ist mit 3 Zeilen ASM erledigt.

[Wilhelm M. (wimalopaan)]

Cyblord -. schrieb:
> Nicht übertreiben. Lange nicht bei allen. Ich arbeite bisher vorwiegend
> mit dem ATTiny841. Dort gibts das noch nicht und auch bei keinen der
> Vorgänger.

Gibt es bei den xmega-Architekturen

[Oliver S. (oliverso)]

Cyblord -. schrieb:
> Auch nicht bei Megas der gleichen oder Vorgängergeneration.
> Das ist ein recht neues Feature der aktuelleren AVRs.

Dieses 4 clock cycle Sicherheitsfeature gegen unbeabsichtigtes Setzen 
gibt es mindestens beim EEPROM schreiben, Watchdog en/-disablen, Flash 
programmieren über SPM, und wer weiß wo sonst noch

Das hat einfach jeder AVR irgendwo, seit dem allerersten Modell.

Oliver

[Falk B. (falk)]

Dafür gibt es ein Inline-ASM Macro, das funktioniert in ALLEN 
Optimierungsstufen. Das stammt aus einer application note.

/*! \brief CCP write helper function written in assembly.
 *
 *  This function is written in assembly because of the timecritial
 *  operation of writing to the registers.
 *
 *  \param address A pointer to the address to write to.
 *  \param value   The value to put in to the register.
 */
void CCPWrite( volatile uint8_t * address, uint8_t value )
{
  volatile uint8_t * tmpAddr = address;
#ifdef RAMPZ
  RAMPZ = 0;
#endif
  asm volatile(
    "movw r30,  %0"        "\n\t"
    "ldi  r16,  %2"        "\n\t"
    "out   %3, r16"        "\n\t"
    "st     Z,  %1"       "\n\t"
    :
    : "r" (tmpAddr), "r" (value), "M" (CCP_IOREG_gc), "i" (&CCP)
    : "r16", "r30", "r31"
    );
}

[Wilhelm M. (wimalopaan)]

Wie gesagt, das ist im xmaga-support der avrlibc drin: xmega.h

[Rolf M. (rmagnus)]

Cyblord -. schrieb:
>> Sorry, das habe ich jetzt erst gelesen: -O0 schaltet fast alle
>> Optimierungen ab.
>
> Das ist bekannt. Erklärt für mich aber nicht warum hier derart unnötige
> Operationen eingefügt werden.

Er fügt sie nicht zusätzlich ein, sondern optimiert sie nur eben nicht 
raus.

>> Also, was willst Du erwarten. Ab -O oder -O1 ist alles
>> so wie es sein soll.
>
> Ich hätte erwartet dass es für die Zuweisung einer Konstanten an eine
> Speicherstelle, auch ohne Optimierung, eine bessere Umsetzung gibt.

Was heißt für dich "auch ohne Optimierung eine bessere Umsetzung"? Wenn 
man es gegenüber einer direkten 1:1-Umsetzung aus dem C-Code verbessert, 
nennt man das "Optimierung".

> Hier ist ja kein Optimierungsbedarf im eigentlichen Sinne. Selbst wenn
> kein OUT verwendet werden würde, könnte man mit 3 Instruktionen (Z
> Pointer laden + STORE) jede Speicherstelle beschreiben.

CCP ist ein Makro, das einen Integer-Wert in einen Zeiger castet. Genau 
das macht der Compiler hier. Er lädt einen Integer-Wert und kopiert ihn 
in ein Zeiger-Registerpaar.

[Oliver S. (oliverso)]

Cyblord -. schrieb:
> Ich hätte erwartet dass es für die Zuweisung einer Konstanten an eine
> Speicherstelle, auch ohne Optimierung, eine bessere Umsetzung gibt.

Ganz einfach: nimm dir die gcc-Quellen, schreib einen Patch, reich den 
ein, sorge dafür, daß der angenommen wird, und alles wird gut.

Oliver

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Wie gesagt, das ist im xmaga-support der avrlibc drin: xmega.h

Ich nutze aber keinen xmega. Ich werde aber mal schauen ob für die 
avr128 ein solches Makro auch existiert.

Danke für den Tipp Falk.

[Wilhelm M. (wimalopaan)]

Cyblord -. schrieb:
> Ich nutze aber keinen xmega.

Doch. Der AVR128DAxxx ist eine xmega4 Architektur.

Benutze einfach das Makro was Du in dem header xmega.h findest, wie oben 
schon gesagt.

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Cyblord -. schrieb:
>> Ich nutze aber keinen xmega.
>
> Doch. Der AVR128DAxxx ist eine xmega4 Architektur.

Also der Hersteller bezeichnet das alles komplett anders.
Es gibt eine AVRxm Architektur (XMEGA). Die AVR128DA sind aber AVRxt 
welches der Nachfolger ist.
Hier steht sogar dabei die Anleihen an AVRe (attiny) sind größer.

[Wilhelm M. (wimalopaan)]

Schau in den specs des gcc nach: avrxmega4 (bezieht sich natürlich nur 
auf die CPU)

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Schau in den specs des gcc nach: avrxmega4 (bezieht sich natürlich nur
> auf die CPU)

Danke. Aber ich halte mich an die Specs des Herstellers. Es ist möglich 
dass innerhalb des gcc das alles etwas anders heißt oder anders 
zusammengefasst ist. Was es nicht unbedingt richtig macht.
Zu behaupten AVR128 wäre im Prinzip XMEGA stimmt aber eben nicht und ist 
irreführend.

[Wilhelm M. (wimalopaan)]

Cyblord -. schrieb:
> Danke. Aber ich halte mich an die Specs des Herstellers. Es ist möglich
> dass innerhalb des gcc das alles etwas anders heißt oder anders
> zusammengefasst ist. Was es nicht unbedingt richtig macht.

Dann benutzt Du den gcc nicht? Ok, was lamentierst Du dann herum.

[Cyblord -. (cyblord)]

Wilhelm M. schrieb:
> Cyblord -. schrieb:
>> Danke. Aber ich halte mich an die Specs des Herstellers. Es ist möglich
>> dass innerhalb des gcc das alles etwas anders heißt oder anders
>> zusammengefasst ist. Was es nicht unbedingt richtig macht.
>
> Dann benutzt Du den gcc nicht? Ok, was lamentierst Du dann herum.

Natürlich nutze ich den. Was mich aber nicht zu falschen Aussagen wie

> Der AVR128DAxxx ist eine xmega4 Architektur.

verleiten könnte.

Vielleicht wolltest du ja sagen:

Der gcc nennt die AVR128 Architektur xmega4.

Wer weiß?

[Wilhelm M. (wimalopaan)]

Na, wie Du meinst.
Die devices-specs stammen übrigens aus dem offiziellen DFP-Pack von 
MicroChip.

[Oliver S. (oliverso)]

Cyblord -. schrieb:
> Also der Hersteller bezeichnet das alles komplett anders.

Das liest sich so, wie eine Unterteilung der VW-Modelle in luftgekühlte 
Boxer und wassergekühlte Reihenvierzylinder.

Die Welt hat sich seit dem doch etwas weitergedreht, und die 
Modellvielfalt ist in der Realität deutlich komplexer.

Oliver

[foobar (Gast)]

In dem Zusammenhang (korrektes Timing zwischen zwei Befehlen) hab ich 
übrigens auch das umgekehrte Problem schon erlebt: "sei(); sleep();" 
müssen direkt aufeinander folgen um Race-Conditions zu vermeiden. 
Beides ASM-Statements und klappt ohne Optimierung auch.  Dann hatte ich 
aber so eine Konstellation[1]:

   if (...) {
      ...
      sei();
      sleep();
  } else {
      ...
      sleep();
  }

und der Compiler hat bei -Oirgendwas den "sleep", der in beiden Pfaden 
als letzter Befehl vorkommt, zusammengefasst und hinter das if-statement 
geschoben. Peng - dem sei() folgte ein Jump zum sleep und damit ist die 
Bedingung verletzt und führt irgendwann zu einem Lock-Up.



[1] nicht exakt diese, aber auch CSE basierend mit einem Jump hinter dem 
sei.

[Jörg W. (dl8dtl) (Moderator)]

Cyblord -. schrieb:
> Es gibt eine AVRxm Architektur (XMEGA). Die AVR128DA sind aber AVRxt
> welches der Nachfolger ist.

Da steht aber auch, dass sie von der Xmega-Architektur abgelitten sind, 
und die hatte halt schon immer ihr CCP.

Alternative zu den genannten Makros + Inline-Assembler: schreib dir für 
das, wo du CCP anfassen musst, Wrapper-Funktionen, die du in eine eigene 
Quelldatei packst und dann mit mehr als -O0 compilierst auch denn, wenn 
du für den Rest unbedingt -O0 haben willst.

[Cyblord -. (cyblord)]

Jörg W. schrieb:
> Da steht aber auch, dass sie von der Xmega-Architektur abgelitten sind,
> und die hatte halt schon immer ihr CCP.

In der Tat habe ich das CCP schon unterbewusst auf einem tiny841 benutzt 
um das Flash zu beschreiben für einen Bootloader. Für den Schutz 
bestimmter Register wird es hier aber noch nicht benutzt.

> Alternative zu den genannten Makros + Inline-Assembler: schreib dir für
> das, wo du CCP anfassen musst, Wrapper-Funktionen, die du in eine eigene
> Quelldatei packst und dann mit mehr als -O0 compilierst auch denn, wenn
> du für den Rest unbedingt -O0 haben willst.

ccp_write_io gibt es ohne Klimmzüge auch für den avr128, somit ich nutze 
ich das. Danke für diesen Tipp.