AVR128, CCP und Optimierung

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?

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.

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.

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.

Bei mir wird aus

1

#include <cstdint>

2

#include <mcu/avr.h>

3

#include <mcu/internals/ccp.h>

4

#include <mcu/internals/clock.h>

5

6

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

7

using clock = AVR::Clock<>;

8

9

int main() {

10

    ccp::unlock([]{

11

        clock::prescale<2>();

12

    });

13

}

dann mit -O1 und gcc 10.3.0 oder 12.0.0

1

__CCP__ = 0x34

2

.text

3

.type   main, @function

4

main:

5

ldi r24,lo8(-40)         ;  tmp44,

6

out __CCP__,r24  ;  MEM[(volatile value_type &)48B + 4], tmp44

7

ldi r24,lo8(1)   ;  tmp46,

8

sts 97,r24       ;  MEM[(struct ControlRegister *)96B + 1B].hwRegister, tmp46

9

ldi r25,0                ;

10

ldi r24,0                ;

11

ret

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

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

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.

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.

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.

Wickel den Code-Abschnitt doch in Pragmas ein!

z.B. so:

1

#pragma GCC push_options

2

#pragma GCC optimize ("O1")

3

4

// critical code

5

6

#pragma GCC pop_options

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

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.

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

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

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

1

/*! \brief CCP write helper function written in assembly.

2

 *

3

 *  This function is written in assembly because of the timecritial

4

 *  operation of writing to the registers.

5

 *

6

 *  \param address A pointer to the address to write to.

7

 *  \param value   The value to put in to the register.

8

 */

9

void CCPWrite( volatile uint8_t * address, uint8_t value )

10

{

11

  volatile uint8_t * tmpAddr = address;

12

#ifdef RAMPZ

13

  RAMPZ = 0;

14

#endif

15

  asm volatile(

16

    "movw r30,  %0"        "\n\t"

17

    "ldi  r16,  %2"        "\n\t"

18

    "out   %3, r16"        "\n\t"

19

    "st     Z,  %1"       "\n\t"

20

    :

21

    : "r" (tmpAddr), "r" (value), "M" (CCP_IOREG_gc), "i" (&CCP)

22

    : "r16", "r30", "r31"

23

    );

24

}

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

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.

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

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.

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.

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.

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

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.

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.

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ß?

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

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

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.

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.