avr-gcc 11.1.0 defekt?

Die SPI-Instanzen beim avr0 und dahaben unterschiedliche Basisadressen. 
Bist Du sicher, dass Du die richtigen verwendest?

gcc-11.1 kann ich nicht nachvollziehen, aber ich hatte bisher nie 
Probleme damit und gcc-12.0 geht definitiv.

Dein Klasse ist allerdings etwas merkwürdig: was sofort auffällt:

- warum Pin-Nummern angeben? Die liegen fest, auch bei Portmux sind sie 
nicht frei wählbar.
- Du verwendest immer SPI0, es gibt aber beim DA zwei Instanzen. DAs 
wird dann schon mal falsch.
- ...

Veit D. schrieb:
> Arduino IDE 1.8.15 + avr-gcc 11.1.0 + MCUdude MegaCoreX Package
> (ATmega4809)

> Es funktioniert nicht:
> Arduino IDE 1.8.15 + avr-gcc 11.1.0 + Arduino megaavr0 Package
> (ATmega4809)

Wie kommst Du dazu, dass es der Compiler sein sollte. Was sich hier 
unterscheidet sind diese Packages.

Hallo,

die SPI.h/cpp stammt nicht von mir. Das ist orignal Arduino Code.

> Wie kommst Du dazu, dass es der Compiler sein sollte. Was sich hier
> unterscheidet sind diese Packages.

Egal was ich verwende, sobald ich für den ATmega4809 (Nano Every) den 
avr-gcc 11.1.0 verwende funktioniert SPI nicht. Gleicher kurzer 
Testcode, gleiche Lib, nur anderer avr-gcc -> andere Adressen. Worauf 
lässt das schließen?

Veit D. schrieb:
> Egal was ich verwende, sobald ich für den ATmega4809 (Nano Every) den
> avr-gcc 11.1.0 verwende funktioniert SPI nicht. Gleicher kurzer
> Testcode, gleiche Lib, nur anderer avr-gcc -> andere Adressen. Worauf
> lässt das schließen?

Schau nochmal was Du oben geschrieben hast: da ist es derselbe Compiler. 
Aber vielleicht ist Deine Auflistung auch falsch.

Veit D. schrieb:
> die SPI.h/cpp stammt nicht von mir. Das ist orignal Arduino Code.

oh je ...

> warum Pin-Nummern angeben?
Weil die Lib auch Software SPI zulässt.

> Schau nochmal was Du oben geschrieben hast: da ist es derselbe Compiler.
> Aber vielleicht ist Deine Auflistung auch falsch.
Lies nochmal bitte genau was ich aufgelistet und geschrieben habe.

Veit D. schrieb:
> Es funktionieren folgende Kombinationen:
> Arduino IDE 1.8.15 + avr-gcc 11.1.0 + MCUdude MegaCoreX Package
> (ATmega4809)
> Es funktioniert nicht:
> Arduino IDE 1.8.15 + avr-gcc 11.1.0 + Arduino megaavr0 Package
> (ATmega4809)

Und nocheinmal ... worin unterscheiden die sich: richtig, nicht im 
Compiler.

Hallo,

Leute, der generierte Code hängt doch oben dran. Beide Dumpfiles mit
Arduino IDE 1.8.15 + Arduino megaavr0 Package (ATmega4809). Irgendwelche 
Adressen unterscheiden sich. Ich bin aber kein Compilerguru.

Gegenfrage. Warum funktioniert
Arduino IDE 1.8.15 + avr-gcc 10.3.0 + Arduino megaavr0 Package 
(ATmega4809)
und warum funktioniert nicht
Arduino IDE 1.8.15 + avr-gcc 11.1.0 + Arduino megaavr0 Package 
(ATmega4809)

Worauf lässt das als Erstes schließen? Der erzeugte Code unterscheidet 
sich jedenfalls.

Ganz schön starker Tobak. Ich verstehe dich so, du möchtest nur nörgeln 
und wolltest niemals helfen.

Hast Du denn jetzt wenigstens schon meinen ersten Kommentar gelesen bzw. 
Geprüft?

Welchen von den vielen meinst du? Falls du die Adressen von CTRLA/CTRLB 
meinst, die habe ich schon lange geprüft. Die stimmen.

Hallo,

da niemand gewillt ist dem Link zu folgen nochmal.
Dieser Code in der SPI.h wird nachweislich ausgeführt.

1

  private:

2

  void init_MightInline(uint32_t clock, BitOrder bitOrder, uint8_t dataMode) {

3

    init_AlwaysInline(clock, bitOrder, dataMode);

4

  }

5

6

  void init_AlwaysInline(uint32_t clock, BitOrder bitOrder, uint8_t dataMode) __attribute__((__always_inline__)) {

7

    // Clock settings are defined as follows. Note that this shows SPI2X

8

    // inverted, so the bits form increasing numbers. Also note that

9

    // fosc/64 appears twice.  If FOSC is 16 Mhz

10

    // PRESC[1:0]  ~SPI2X Freq

11

    //   0    0     0   fosc/2    8.00 MHz 

12

    //   0    0     1   fosc/4    4.00 MHz

13

    //   0    1     0   fosc/8    2.00 MHz

14

    //   0    1     1   fosc/16   1.00 MHz

15

    //   1    0     0   fosc/32   500  kHz

16

    //   1    0     1   fosc/64   250  kHz

17

    //   1    1     0   fosc/64   250  kHz

18

    //   1    1     1   fosc/128  125  kHz

19

20

    // We find the fastest clock that is less than or equal to the

21

    // given clock rate. The clock divider that results in clock_setting

22

    // is 2 ^^ (clock_div + 1). If nothing is slow enough, we'll use the

23

    // slowest (128 == 2 ^^ 7, so clock_div = 6).

24

    uint8_t clockDiv;

25

26

    // When the clock is known at compiletime, use this if-then-else

27

    // cascade, which the compiler knows how to completely optimize

28

    // away. When clock is not known, use a loop instead, which generates

29

    // shorter code.

30

31

    /*  This is no longer the case since, F_CPU_CORRECTED is variable */

32

    /*  set at run time.                                             */

33

34

    uint32_t clockSetting = 0; 

35

36

    clockSetting = F_CPU_CORRECTED / 2;

37

    clockDiv = 0;

38

    while ((clockDiv < 6) && (clock < clockSetting)) {

39

      clockSetting /= 2;

40

      clockDiv++;

41

    }

42

43

    // Compensate for the duplicate fosc/64,

44

    // should be fosc/128 if clockdiv 6.

45

    if (clockDiv == 6)

46

    {

47

      clockDiv++;

48

    }

49

50

    // Invert the SPI2X bit

51

    clockDiv ^= 0x1;

52

53

    /* Pack into the SPISettings::ctrlb class */

54

    /* Set mode, disable master slave select, and disable buffering. */

55

    /* dataMode is register correct, when using SPI_MODE defines     */

56

    ctrlb = (dataMode)            |

57

            (SPI_SSD_bm)          |

58

            (0 << SPI_BUFWR_bp)   |

59

            (0 << SPI_BUFEN_bp);

60

61

    /* Get Clock related values.*/

62

    uint8_t clockDiv_mult = (clockDiv & 0x1);

63

    uint8_t clockDiv_pres = (clockDiv >> 1);

64

65

    /* Pack into the SPISettings::ctrlb class     */

66

    /* Set Prescaler, x2, SPI to Master, and Bit Order. */

67

68

    ctrla = (clockDiv_pres  << SPI_PRESC_gp)        |

69

            (clockDiv_mult << SPI_CLK2X_bp)         |

70

            (SPI_ENABLE_bm)                         |

71

            (SPI_MASTER_bm)                         |

72

            ((bitOrder == LSBFIRST) << SPI_DORD_bp);

73

74

  }

75

  /* member variables containing the desired SPI settings */

76

  uint8_t ctrla;

77

  uint8_t ctrlb;

78

  friend class SPIClassMegaAVR;

79

};

Demzufolge müßte den Membern ctrla und ctrlb ein Wert zugewiesen werden. 
Das funktioniert jedoch aus unbekannten Gründen nicht. Denn der Wert 
dieser Member sollte in der Methode config() in SPI.cpp den Registern 
SPI0.CTRLA und SPI0.CTRLB zugewiesen werden. Dort kommt jedoch kein Wert 
an. In der begin Methode wird vorher noch SPI enable usw. gesetzt usw. 
Auch das kommt nicht an. Die Register bleiben leer. Kommentiere ich den 
config() Aufruf in der begin() Methode aus, dann funktioniert 
komischerweise alles. Wenn das ansonsten funktioniert nur mit dem 
avr-gcc 11.1.0 nicht, woran soll es dann liegen? Minimale Code 
Änderungen führen zum funktionieren. Das ist aber für mich nicht 
logisch. Es gibt ja auch nie ein Gemecker vom Compiler.

Übrigens Wilhlem, ich rede die ganze Zeit vom ATmega4809, der hat nur 
eine SPI Hardwareeinheit.

Bei dem letzten Test ...

1

#include<utilities.h>

2

#include <SPI.h>

3

4

void setup()

5

{  

6

  Serial.begin(250000);

7

  Serial.println(F("\nµC Reset #### #### ####"));

8

9

  showRegister(); 

10

  SPI.begin();

11

  showRegister(); 

12

  SPI.beginTransaction(DEFAULT_SPI_SETTINGS);

13

  showRegister();

14

  SPI.endTransaction();

15

  showRegister(); 

16

}

17

18

void loop()

19

{ }

20

21

void showRegister (void)

22

{

23

  uint16_t reg16 = 0;

24

  Serial.print(F("SPI0 CTRLA:    ")); formatBIN(Serial, SPI0.CTRLA, true);    reg16 = (uint16_t)&SPI0.CTRLA;    Serial.print(" ");  formatHEXln(Serial, reg16, true);

25

  Serial.print(F("SPI0 CTRLB:    ")); formatBIN(Serial, SPI0.CTRLB, true);    reg16 = (uint16_t)&SPI0.CTRLB;    Serial.print(" ");  formatHEXln(Serial, reg16, true);

26

  Serial.println();

27

}

... kommt nur Müll raus.

1

SPI0 CTRLA:    0b0000'0000 0x08C0

2

SPI0 CTRLB:    0b0000'0000 0x08C1

3

4

SPI0 CTRLA:    0b0000'0000 0x08C0

5

SPI0 CTRLB:    0b0000'0001 0x08C1

6

7

SPI0 CTRLA:    0b0001'0000 0x08C0

8

SPI0 CTRLB:    0b0000'0000 0x08C1

9

10

SPI0 CTRLA:    0b0001'0000 0x08C0

11

SPI0 CTRLB:    0b0000'0000 0x08C1

Erwartet wird das was mit älteren Toolchains rauskommt.

1

avr-gcc 11.1.0: SPI0 CTRLA: 0b0000'0000, CTRLB: 0b0000'0001

2

avr-gcc 10.3.0: SPI0 CTRLA: 0b0010'0001, CTRLB: 0b0000'0100

3

avr-gcc  7.3.0: SPI0 CTRLA: 0b0010'0001, CTRLB: 0b0000'0100

Wo wird denn:

init_AlwaysInline(...)

aufgerufen? Das sieht man an Deinem Beispiel nicht.

Veit D. schrieb:
> Demzufolge müßte den Membern ctrla und ctrlb ein Wert zugewiesen werden.
> Das funktioniert jedoch aus unbekannten Gründen nicht.

Woher willst Du das wissen. Gibt die beiden doch mal aus.

Hallo,

init_AlwaysInline(...) wird in init_MightInline(...) aufgerufen.
init_MightInline(...) wird im Konstruktor SPISettingsMegaAVR(...) 
aufgerufen.
Die beiden Methoden werden jeweils nur einmal aufgerufen. Das habe ich 
mittels Pin Toggle geprüft.
Die Member ctrla und ctrlb direkt auszugeben ist nicht so einfach. Habe 
ich wegen dem Datentyp noch nicht geschafft. Würde ich eine eigene 
Instanz erzeugen hätte ich nicht mehr die "originalen Werte". Da ich 
aber weiß wann sie den Registern zugewiesen werden, habe ich immer 
zwischendurch die Register ausgelesen die diese Werte enthalten müssen. 
Tun sie aber nicht. Siehe meiner vorherigen Antwort.

Veit D. schrieb:
> Die Member ctrla und ctrlb direkt auszugeben ist nicht so einfach. Habe
> ich wegen dem Datentyp noch nicht geschafft.

Oh ha, ein uint8_t ist auch echt schwierig auszugeben ;-)
Oder meinst Du, Du hast keinen Zugriff, weil sie private sind?

Veit D. schrieb:
> Da ich
> aber weiß wann sie den Registern zugewiesen werden, habe ich immer
> zwischendurch die Register ausgelesen die diese Werte enthalten müssen.
> Tun sie aber nicht. Siehe meiner vorherigen Antwort.

Woher willst Du das wissen. Wo passiert das?

Mitleserin (a.b.) schrieb:
> Nur unter diesen Voraussetzungen können Foristen das Problem
> nachvollziehen und eventuell helfen heraus zu finden, was wo klemmt.

Das Problem ist halt, daß die Schnittmenge derjenigen, die was zur 
Problemlösung beitragen können und Arduino nutzen und das auch noch für 
diesen Prozessor genau eine Person enthält: den TO selber.

Daher sind die Anfragen zu diesen Themen selten von Erfolg gekrönt.

Oliver

Hallo,

das hast du nett zusammengefasst Oliver. Es kommt jedoch noch ein 
Problem hinzu was ich immer wieder feststelle. Das dem TO (in dem Fall 
mir) immer wieder etwas vor die Füße geworfen wird, aber die angeblichen 
Helfer selbst nicht lesen können. Anders kann ich mir die sinnfreien 
provozierenden Nachfragen nicht erklären. Alles was nachgefragt wird 
hatte ich schon geschrieben und zur Verfügung gestellt. Nachfragen wegen 
unklaren Formulierungen sehen anders aus.

Und was hat ein Timercode vom AVR128DB48 hier zu suchen? Dazu das Ding 
mit der Pin Lib. Das ist meine Lib. Wer die nicht hat kann nicht 
kompilieren. Das ist völlig logisch. Ich habe jetzt in dessen älteren 
Thread nicht nachgeschaut ob die bereit steht oder nicht. Aber selbst 
wenn nicht kann man ja danach ganz normal fragen ob man die Lib bekommen 
kann. Aber nein, wird gleich quer geschossen. Das Thema vom Thread hier 
wurde demnach überhaupt nicht verstanden. Dabei ist der Thread noch 
nicht lang sodass man alles lesen kann.

Auch der Vorwurf mit der Arduino IDE und dem avr-gcc kann ich nicht 
verstehen. Wer die Arduino IDE nicht verwendet und keine aktuelle 
Toolchain hinzufügen kann, der kann mir in dem konkreten Problem sowieso 
nicht helfen. Gewisse Dinge setze ich einfach voraus.

Auch das man sich an der Betreffzeile aufhängt finde ich unmöglich. 
Alles weitere steht im Text. Ein Betreff kann niemals alles 
wiederspiegeln. Man hätte bei allen irgendwas zu meckern.

Das Problem tritt nur mit dem "Atmega4809", der Arduino SPI Lib und dem 
avr-gcc 11.1.0 auf. Also eine spezielle Kombination. Der gcc 11 hat ein 
neues Frontend und ein neues Backend. Kann ja durch im Rahmen des 
Möglichen liegen das mit bestimmten Quellcode falsch kompiliert wird. 
Das liegt für mich jedenfalls nicht vom Tisch wischbar nachwievor auf 
der Hand.

Wenn jemand wirklich helfen möchte, dann klingen die Nachfragen 
sicherlich anders und dem würde ich sogar erklären wie er eine aktuelle 
Toolchain der IDE hinzufügt. Nur kamen dazu nie Nachfragen, sodass das 
nie ein Thema war.

Ich weiß nicht was ich zu dem Threadverlauf noch sagen soll. Hatte ich 
mir anders vorgestellt. Jedenfalls nicht so ein oberflächliches an der 
Nase herumführen. Wer nicht helfen möchte der muss nicht helfen. Das ist 
ganz einfach.

Nun ja, du bist lange genug dabei…

Bei solchen Problemen braucht es ein aufs wesentliche reduziertes 
compilierbares Beispiel, das den angeblichen Fehler reproduzierbar 
zeigt. Alles andere ist zwecklos.

Wenn das Problem halt nur bei mit völlig exotischen libs und völlig 
exotischen Prozessoren auftritt, und das daher eh niemand compilieren 
könnte, ist Hilfe kaum möglich.

Warum du dir allerdings die paar Zeilen Assembler, die da generiert 
werden, nicht selber anschaust, ist schon komisch.

Oliver

Wilhelm M. schrieb:
> Veit D. schrieb:
>> Demzufolge müßte den Membern ctrla und ctrlb ein Wert zugewiesen werden.
>> Das funktioniert jedoch aus unbekannten Gründen nicht.
>
> Woher willst Du das wissen. Gibt die beiden doch mal aus.

Veit D. schrieb:
> Die Member ctrla und ctrlb direkt auszugeben ist nicht so einfach. Habe
> ich wegen dem Datentyp noch nicht geschafft.

Wilhelm M. schrieb:
> Oh ha, ein uint8_t ist auch echt schwierig auszugeben ;-)
> Oder meinst Du, Du hast keinen Zugriff, weil sie private sind?

Darauf hast Du bisher gar nicht reagiert.

Hallo,

@ Wilhelm
Mit private und uint8_t habe ich kein Problem. Ich bekomme keinen 
Zugriff durch die Verzwickung der verschiedenen Klassen die im Spiel 
sind. Deswegen hatte ich erstmal den Umweg über die SPI Register 
gemacht.

Ich muss von SPIClass:: eine Methode bauen um auf ctrla/ctrlb von 
SPISettingsMegaAVR:: zuzugreifen. Ich meine die Klasse SPIClassMegaAVR 
hat doch mittels friend class SPIClassMegaAVR; vollen Zugriff auf die 
Member der Klasse SPISettingsMegaAVR. Klappt aber nicht. Alle 3 return 
Varianten führen  zur Meldung ctrla is not a member  of ...

1

uint8_t SPIClass::getCtrla (void)

2

{

3

  return SPISettingsMegaAVR::ctrla;

4

  return SPIClassMegaAVR::ctrla;

5

  return ctrla;

6

}

Veit D. schrieb:
> Hallo,
>
> @ Wilhelm
> Mit private und uint8_t habe ich kein Problem.

Ja, warum schreibst Du es denn?
Das hast Du gesagt hier:

Veit D. schrieb:
> Die Member ctrla und ctrlb direkt auszugeben ist nicht so einfach. Habe
> ich wegen dem Datentyp noch nicht geschafft.

> Ich bekomme keinen
> Zugriff durch die Verzwickung der verschiedenen Klassen die im Spiel
> sind. Deswegen hatte ich erstmal den Umweg über die SPI Register
> gemacht.

Was ist denn daran verzwickt?
Du übergibt Deiner Funktion config(...) eine Instanz von 
SPISettingsMegaAVR.
Dann für doch da zwei Beobachter-Funktionen ein oder mache testweise die 
Elemente grad public.

> Ich muss von SPIClass:: eine Methode bauen um auf ctrla/ctrlb von
> SPISettingsMegaAVR:: zuzugreifen. Ich meine die Klasse SPIClassMegaAVR
> hat doch mittels friend class SPIClassMegaAVR; vollen Zugriff auf die
> Member der Klasse SPISettingsMegaAVR. Klappt aber nicht. Alle 3 return
> Varianten führen  zur Meldung ctrla is not a member  of ...
>
>

1

> uint8_t SPIClass::getCtrla (void)

2

> {

3

>   return SPISettingsMegaAVR::ctrla;

4

>   return SPIClassMegaAVR::ctrla;

5

>   return ctrla;

6

> }

7

>

Das mit den Beobachtern hast Du immer noch nicht verstanden. Das hatten 
wir schon mal in einem anderen Thread. Das Nachvollziehen der 
Informationen anderer scheint für Dich schwierig zu sein bzw. Du gehst 
darüber einfach hinweg, weil Du meinst es sei völlig unwichtig.

Zu der Funktion: ctrla/ctrlb sind doch keine statischen Datenelemente! 
C++ lernt man nicht durch trial-n-error.

Mach Deine Debug-Ausgabe in der config(...)-Funktion. Dann siehst Du, ob 
die aufgerufen wird und welche Werte in die beiden Register geschrieben 
werden.

Hallo,

Danke Johannes für deine klaren Worte.



Die Klassennamen SPISettingsMegaAVR und SPIClassMegaAVR sind auch 
Datentypen. Nur eben "selbst" gebaute. Diese meinte ich. Im Nachgang 
betrachtet hätte ich das vielleicht näher beschreiben sollen. Gut. Warum 
die Member ctrla/ctrlb für eigene Zugriffe statisch sein sollen kann ich 
nicht nachvollziehen. Die Klassen haben doch mittels Vererbung Zugriff. 
In der Theorie jedenfalls. Ich wollte mir jedenfalls eine eigene 
Rückgabemethode bauen und bin daran gescheitert. Soweit so schlecht.

Jetzt lasse ich mir die Member in der config Methode direkt ausgeben. 
Wie du vorgeschlagen hast. Damit passiert genau das was ich befürchtet 
habe, jede Änderung führt zu anderen Ergebnissen. Vielleicht ist das 
auch nicht verkehrt sieht man doch das da Einiges passiert. Der 
komplette Testcode sieht so aus.

1

#include <utilities.h>

2

#include <SPI.h>

3

4

void setup()

5

{

6

  Serial.begin(250000);

7

  Serial.println(F("\nµC Reset #### #### ####"));

8

9

  showRegister(); 

10

  Serial.println(F("begin"));

11

  SPI.begin();

12

  showRegister(); 

13

  Serial.println(F("beginTransaction"));

14

  SPI.beginTransaction(DEFAULT_SPI_SETTINGS);

15

  showRegister();

16

  Serial.println(F("endTransaction"));

17

  SPI.endTransaction();

18

  showRegister(); 

19

}

20

21

void loop()

22

{ }

23

24

void showRegister (void)

25

{

26

  uint16_t reg16 = 0;

27

  Serial.print(F("SPI0 CTRLA: ")); formatBIN(Serial, SPI0.CTRLA, true); reg16 = (uint16_t)&SPI0.CTRLA; Serial.print(" "); formatHEXln(Serial, reg16, true);

28

  Serial.print(F("SPI0 CTRLB: ")); formatBIN(Serial, SPI0.CTRLB, true); reg16 = (uint16_t)&SPI0.CTRLB; Serial.print(" "); formatHEXln(Serial, reg16, true);

29

  Serial.println();

30

}

Dazu die Änderung in der SPI.cpp.

1

void SPIClass::config(SPISettingsMegaAVR settings)

2

{

3

  Serial.println(settings.ctrla, BIN);

4

  Serial.println(settings.ctrlb, BIN);

5

  SPI0.CTRLA = settings.ctrla;

6

  SPI0.CTRLB = settings.ctrlb;

7

  Serial.println(settings.ctrla, BIN);

8

  Serial.println(settings.ctrlb, BIN);

9

}

Die Ausgabe ist damit wie folgt. Mal abgesehen davon das die Werte nicht 
stimmen, gehen Bits vom Member zum Register verloren. Das Bit 3 in CTRLA 
fehlt.

1

µC Reset #### #### ####

2

SPI0 CTRLA:    0b0000'0000 0x08C0

3

SPI0 CTRLB:    0b0000'0000 0x08C1

4

5

begin

6

0

7

1

8

0

9

1

10

SPI0 CTRLA:    0b0000'0000 0x08C0

11

SPI0 CTRLB:    0b0000'0001 0x08C1

12

13

beginTransaction

14

1010

15

0

16

1010

17

0

18

SPI0 CTRLA:    0b0000'0010 0x08C0

19

SPI0 CTRLB:    0b0000'0000 0x08C1

20

21

endTransaction

22

SPI0 CTRLA:    0b0000'0010 0x08C0

23

SPI0 CTRLB:    0b0000'0000 0x08C1

Lässt man in der config() Methode die ersten beiden Ausgaben weg erhält 
man andere Werte. Bei CTRLB gehen keine Bits verloren.

1

µC Reset #### #### ####

2

SPI0 CTRLA:    0b0000'0000 0x08C0

3

SPI0 CTRLB:    0b0000'0000 0x08C1

4

5

begin

6

0

7

1

8

SPI0 CTRLA:    0b0000'0000 0x08C0

9

SPI0 CTRLB:    0b0000'0001 0x08C1

10

11

beginTransaction

12

0

13

10000010

14

SPI0 CTRLA:    0b0000'0000 0x08C0

15

SPI0 CTRLB:    0b1000'0010 0x08C1

16

17

endTransaction

18

SPI0 CTRLA:    0b0000'0000 0x08C0

19

SPI0 CTRLB:    0b1000'0010 0x08C1

Lässt man in der config() Methode nur die letzten beiden Ausgaben weg 
erhält man wieder andere Werte.

1

µC Reset #### #### ####

2

SPI0 CTRLA:    0b0000'0000 0x08C0

3

SPI0 CTRLB:    0b0000'0000 0x08C1

4

5

begin

6

0

7

1

8

SPI0 CTRLA:    0b0000'0000 0x08C0

9

SPI0 CTRLB:    0b0000'0001 0x08C1

10

11

beginTransaction

12

10

13

0

14

SPI0 CTRLA:    0b0000'0010 0x08C0

15

SPI0 CTRLB:    0b0000'0000 0x08C1

16

17

endTransaction

18

SPI0 CTRLA:    0b0000'0010 0x08C0

19

SPI0 CTRLB:    0b0000'0000 0x08C1

Lässt man die Ausgaben in der config() Methode komplett drin und nimmt 
die "SPI Methoden" Textausgaben im setup() raus, erhält man wieder 
andere Werte.

1

µC Reset #### #### ####

2

SPI0 CTRLA:    0b0000'0000 0x08C0

3

SPI0 CTRLB:    0b0000'0000 0x08C1

4

5

0

6

1

7

0

8

1

9

SPI0 CTRLA:    0b0000'0000 0x08C0

10

SPI0 CTRLB:    0b0000'0001 0x08C1

11

12

11001

13

1010110

14

11001

15

1010110

16

SPI0 CTRLA:    0b0001'0001 0x08C0

17

SPI0 CTRLB:    0b0100'0110 0x08C1

18

19

SPI0 CTRLA:    0b0001'0001 0x08C0

20

SPI0 CTRLB:    0b0100'0110 0x08C1

Das Kombinationsspiel könnte man fortsetzen, aber ich denke das Problem 
ist erkennbar. Wenn ich das mit dem avr-gcc 10.3.0 mache erhalte ich 
immer die gleichen korrekten Daten.

1

µC Reset #### #### ####

2

SPI0 CTRLA:    0b0000'0000 0x08C0

3

SPI0 CTRLB:    0b0000'0000 0x08C1

4

5

begin

6

100001

7

100

8

SPI0 CTRLA:    0b0010'0001 0x08C0

9

SPI0 CTRLB:    0b0000'0100 0x08C1

10

11

beginTransaction

12

100001

13

100

14

SPI0 CTRLA:    0b0010'0001 0x08C0

15

SPI0 CTRLB:    0b0000'0100 0x08C1

16

17

endTransaction

18

SPI0 CTRLA:    0b0010'0001 0x08C0

19

SPI0 CTRLB:    0b0000'0100 0x08C1

Wie nun weiter?

Veit D. schrieb:
> Wie nun weiter?

Zunächst erst einmal alles Unnötige aus Deinem Beispiel heraus nehmen. 
Schritt für Schritt, bis zu dem Punkt, wo es dann Deines Erachtens 
wieder konsistent ist. Dann hast Du einen Ansatz gefunden. Könnte ja 
auch ein Stack-Overflow sein ...

Im Moment muss man sich ja alles zusammen suchen. Es wurde ja schon 
geschrieben, dass Du ein "minimum verifying complete example" erstellen 
sollst.

Veit D. schrieb:
> Warum
> die Member ctrla/ctrlb für eigene Zugriffe statisch sein sollen kann ich
> nicht nachvollziehen.

Ich auch nicht. Deswegen: warum versuchst Du auf ein nicht existierendes 
statisches Element zuzugreifen. Das hast Du ins Spiel gebracht:

Veit D. schrieb:
> uint8_t SPIClass::getCtrla (void)
> {
>   return SPISettingsMegaAVR::ctrla;
>   return SPIClassMegaAVR::ctrla;
>   return ctrla;
> }

Ich vermute, Du hast meine Bemerkung oben gar nicht verstanden.

Hallo,

aber soweit war ich doch schon einmal. Wie oft soll ich denn noch von 
vorn anfangen? Ich kann die ewigen Vorwürfe nicht mehr hören zeige was 
Komplettes. Wie kompletter als komplett soll es denn noch sein? Das 
Gezeigte ist doch komplett. Ich verstehe das Problem nicht. Für den 
Testcode liefere sich sogar frei Haus meine Lib mit. Damit ja niemand 
seine Maus vom zu vielen klicken kaputt macht. Kann aber jeder auch ohne 
machen wenn er auf die Formatierung verzichtet. Arduino IDE, ggf. mein 
Lib importieren, den Sketch kopieren und schon kann es los gehen. 
Einfacher gehts ja nun wirklich nicht. Was soll ich daran noch 
vereinfachen? Das hätte ich gern einmal gewusst.

Wenn ich config() Methodenaufruf weglasse, leere Methode, stimmen alle 
Registerwerte. Sobald die config aufgerufen wird kommt wieder Mist raus. 
Hatte ich aber alles schon mehrfach geschrieben. Das ist der Punkt ab 
der es schief läuft.

Warum sollte ein möglicher Stack Overflow ausgerechnet mit dem gcc 11 
auftreten? Fakt ist doch das gcc 11 irgendwie anders kompiliert was zum 
Fehler führt. Das kann man doch nicht ignorieren.

PS: Wegen Member ctrla/ctrlb. Ich vermute auch wir reden komplett 
aneinander vorbei.

Veit D. schrieb:
> Wenn ich config() Methodenaufruf weglasse, leere Methode, stimmen alle
> Registerwerte. Sobald die config aufgerufen wird kommt wieder Mist raus.
> Hatte ich aber alles schon mehrfach geschrieben. Das ist der Punkt ab
> der es schief läuft.

Meine Güte, ist das so schwer zu verstehen? Koche das Beispiel so weit 
herunter, dass es jeder - auch ohne diesen Arduino-Kram - nachvollziehen 
kann. Du hast da mehrere Riesen-Klassen, von deren Inhalt 95% nicht 
benötigt wird. Entkerne das soweit, bis der Fehler ggf. gar nicht mehr 
auftritt, dann gehe einen Schritt zurück, und Du hast genau das, um 
Hilfe zu bekommen.

Wie kommen denn die Registerinhalte in CTRLA, wenn config() gar nicht 
aufgerufen wird? Oder meinst Du die Reset-Inhalte? Worher hast Du es 
genau anders herum gesagt, ohne config() nur 0x00 drin. Was denn nun?

Veit D. schrieb:
> PS: Wegen Member ctrla/ctrlb. Ich vermute auch wir reden komplett
> aneinander vorbei.

Dann mache es klar. Jedenfalls hast Du einen stat. Elementzugriff 
codiert, auf ein Element, das es nicht gibt. Das lese ich aus dem 
Code-Schnipsel. Den Rest musst Du erklären.

Falls Du aber mit diesen Antworten hier nicht zufrieden bist, dann poste 
das als gcc-bug (Du bist ja der Meinung, dass es einer ist) im 
gcc-bugzilla. Wenn Du da dann kein "minimal verifying complete example" 
lieferst, ist der Eintrag schneller zu, als Du ihn aufgemacht hast. 
Gleiches gilt für Stack-Overflow. Also, versuche es doch dort einmal.

Veit D. schrieb:
> aber soweit war ich doch schon einmal. Wie oft soll ich denn noch von
> vorn anfangen? Ich kann die ewigen Vorwürfe nicht mehr hören zeige was
> Komplettes. Wie kompletter als komplett soll es denn noch sein? Das
> Gezeigte ist doch komplett. Ich verstehe das Problem nicht.

Das Problem fängt mit A… an und endet auf ...ino.

Kaum jemand hat große Lust, in dem wilden Mischmasch von Bibliotheken 
und sonstigem Gedöns irgendwelche Fehler zu suchen.

Oliver

Johannes S. schrieb:
> Arduino ist nicht meine bevorzugte Umgebung, aber ich kann das Internet
> bedienen und kann dem Problem folgen.

Was niemandem einer Lösung näher bringt.

Johannes S. schrieb:
> Und dann bleibt schon die Frage, warum kommt eine ältere gcc damit klar
> und eine neuere nicht?

Selbst das ist doch eine reine Behauptung, die bisher noch gar nicht 
nachgewiesen wurde.

Und ohne dem TO allzu nahe treten zu wollen, ist der gezeigte Code in 
allen Belangen so weit weg von "solide" und "verstanden", daß es reiner 
Zufall ist, ob da was funktioniert oder nicht.

Oliver

Johannes S. schrieb:
> ich habe nicht gelabert und genörgelt wie die anderen hier, ich habe die
> Zeile mit dem Fehler lokalisiert.

Ok, dein Edit hatte ich übersehen. Da sollte dann jemand das Thema 
"delegating constructors" nochmals nachlesen.

Bedeutet das jetzt, daß alle Compiler vor gcc 11 fehlerhaft waren?

Oliver

Johannes S. schrieb:
> noch ein Edit:
> geht die Zeile im letzten Link nicht ins Leere? Im Konstruktor aus
> SPISettings& wird der SPISettingsMegaAVR(,,) aufgerufen, aber damit wird
> ja nix gemacht. Liegt auf dem Stack und wird wieder abgeräumt, und der
> Konstruktor liefert ein leeres Objekt, also genau das was der TO
> beobachtet.
> Damit hätten die älteren gcc eher zufällig den initialisierten Stack
> benutzt, bei anderem Speicherläyout geht es damit korrekterweise schief.

Oh wei, wieder eine Bestätigung dafür, dass die Code-Qualität der 
Arduino-Sachen nicht die beste ist.

Ich hatte da schon nach dieser Zeile aufgehört zu lesen:

https://github.com/arduino/ArduinoCore-megaavr/blob/5717c2a3ac8ecc6e5f382715b7f6225e1c809007/libraries/SPI/src/SPI.cpp#L27


Glückwunsch an Johannes.

Johannes S. schrieb:
> ich würde eher sagen es war Zufall das etwas funktioniert hat,

Oliver S. schrieb:
> Und ohne dem TO allzu nahe treten zu wollen, ist der gezeigte Code in
> allen Belangen so weit weg von "solide" und "verstanden", daß es reiner
> Zufall ist, ob da was funktioniert oder nicht.

Tja, ein Leben ohne Arduino ist nicht nur möglich, sondern tatsächlich 
sinnvoll.

Oliver

Hallo,

wenn ich die Antworten hier lese weiß ich nicht mehr was ich sagen soll. 
Das Beste ist, ich wundere mich einfach nur darüber. Alles andere führt 
zu nichts.

Ein Einziger hat es richtig gemacht. Das ist Johannes. Aus der Kalten 
heraus mitgemacht, umfangreichen fremden Code gelesen, ohne Theater 
Problem analysiert und auf den Punkt gezeigt. Vor solchen Leuten ziehe 
ich meinen Hut. Du hast meinen allertiefsten Respekt. Das kann ich dir 
sagen.

Jetzt machen meine Beobachtungen auch Sinn, wenn man die Member ctrla, 
cltrb selbst initialisiert, dann sieht man das genau die Werte in den 
Registern landen. Ohne Initialisierung landen Zufallswerte (non static 
Member) in den Registern, weil das mit dem Kontruktor selbst bzw. 
überladen schief läuft. Soweit mein Verständnis zum Problem im Nachgang.

Einen konkreten Vorwurf an die Arduino Programmierer kann man auch nicht 
machen. Ich jedenfalls nicht. Erstens wird die IDE "nur" mit avr-gcc 
7.3.0 ausgeliefert und Zweitens kann man diesen Fehler ja nur finden 
wenn ihn auch entdeckt. Wenn der Fehler bis 10.3.0 nicht auftaucht, weil 
der gcc bis dahin scheinbar fehlertoleranter ist, tja dann kann man ihn 
nicht finden. Codefehler findet man sicherlich nicht nur bei Arduino. Es 
hat ja seinen Grund das gcc bzw. C++  weiterentwicklet wird und immer 
strenger wird. Hier in dem Fall hätte ich mir irgendeine Warnung seitens 
gcc gewünscht. Falls das überhaupt möglich ist. Wunschdenken.  :-)

Diese Erkenntnis nehme ich mit ins Arduino Forum und dann kann das 
sicherlich von "Arduino" gefixt werden. Ich werde auf den Thread 
verweisen, vielleicht können von denen auch paar Leute deutsch falls 
erforderlich.

Nochmals vielen Dank Johannes. Schön das es solche Menschen noch gibt.

Veit D. schrieb:
> Wenn der Fehler bis 10.3.0 nicht auftaucht, weil
> der gcc bis dahin scheinbar fehlertoleranter ist, tja dann kann man ihn
> nicht finden.

Das hat mit Fehlertoleranz im Compiler nichts zu tun (die gibt es acuh 
nicht). Das ist ein so grundlegender Fehler im Code, da müssen schon 
sehr viele Zufälle zusammenkommen, daß das so aussieht, als ob es 
funktioniert.

Das ist bisher nicht aufgefallen, weil es noch niemand ernsthaft benutzt 
hat.

Oliver

So schön ruhig schrieb:
> Nanu, wo sind denn die Maulhelden, allen voran "Wilhelm", abgeblieben?
> War wohl nichts -den TO für unfähig erklären, aber selbst nicht in der
> Lage sein, das Problem auch nur im Ansatz zu erfassen.

Dann habe ich wohl Deinen sachdienlichen Hinweis überlesen? Hätte ich 
gerne mal gesehen, "Gast".

So schön ruhig schrieb:
> Der TO hat beschrieben, was er daraus gelernt hat.

In der Tat: der TO hat wie ein kleines Kind gelernt, dass man seinen 
Mist nur anderen, sehr sehr netten Leuten vorwerfen muss, ohne sich auch 
nur ein kleines bisschen Mühe zu geben. Mehr hat er leider nicht 
gelernt!

In finde es auch toll, dass Johannes sich die Mühe gemacht hat - und 
finde es eben aus o.g. Grund gleichzeitig auch schade, dass er es 
gemacht hat.

Zu seiner Lösung habe ich ihm gratuliert, weil er sich durch diesen 
Misthaufen durchgelesen hat.
Ja, das habe ich nicht getan, und werde es in Zukunft auch nicht tun, 
wenn der Code bestimmte Merkmale aufweist und andere eben nicht 
aufweist.

Warum ich mir den Code nicht weiter angesehen habe, steht weiter oben. 
Wenn ich so etwas lese, ist es für mich nur Zeitverschwendung, die 
tatsächliche Problemstelle zu suchen.
Stattdessen habe ich ganz oben begonnen, den TO auf mögliche Ursachen 
hinzuweisen. Natürlich kann auch ein Compiler wie gcc oder clang Fehler 
aufweisen, doch auch habe ich ganz oben begründet meine Zweifel daran 
sofort geäußert. Stattdessen habe ich dem TO versucht Methodiken 
aufzuzeigen, mit denen er selbst zum Ziel kommt - etwas ein MCVE zu 
erstellen. Das ist übliche Praxis. Dazu war der TO nicht willens bzw. in 
der Lage.

Sorry, aber dieser TO neigt dazu, alles das, was er nicht versteht, erst 
einmal als unnötig oder falsch zu bezeichnen. Auch da haben wir hier ein 
Beispiel: seine Beobachterfunktion. In seinen Augen ist 
const-correctness unnötig. Das hatten wir in einem anderen Beitrag. Und 
siehe da: wieder nichts gelernt.
Das nächste Beispiel ist die Unfähigkeit, die beiden Elemente ctrla / 
ctrlb einfach mal auszugeben. Sorry, das ist C++ Grundschule. Kriegt er 
nicht hin. Stattdessen murkst er da irgendwas mit Zugriff auf 
nicht-existierende statische Elemente zurecht.

So nett Johannes auch war, es wird rein gar nichts helfen.

So schön ruhig schrieb:
> Was bin ich froh, auf solche "Helfer" wie Dich, Wilhelm nicht angewiesen
> zu sein. 3 Kreuze mache ich dafür...

Ja, dann ist es ja gut so.

BTW: was war nochmal Dein substantieller Beitrag für die Problemlösung 
hier. Oder gibt Du nur Allgemeinplätze ab?

Rechtsaussen als Linksabbieger schrieb:
> Ich sage doch: Du liest zwar, begreifst aber das Gelesene offensichtlich
> nicht. Ich zitiere mich deshalb selbst:
>
>> Ich halte mich von diesem Zeug so fern, wie nur irgend möglich, denn es
>> hat sich (nicht nur hier und jetzt) gezeigt, daß das Programmieren damit
>> einem Würfelspiel gleicht.
>
> Wie also sollte ich da einen "substanziellen Beitrag" leisten können,
> wenn das selbst solchen Spezialisten wie Dir in keiner Weise gelingt?

Jetzt auch von Versteckspiel??? Traurig!

Hallo,

naja Wilhelm. Du musst schon zugeben das du so getan hast den SPI Lib 
Code gelesen zu haben, mich von oben herab belehrend zu allen möglichen 
behandelt hast, also wie immer und dich dann aber mit der Frage zur 
config Methode blamiert hast. Denn in der begin Methode ist klar 
ersichtlich womit die Register beschrieben werden um dann von der 
Problem Methode config falsch überschrieben zu werden. Du hast demnach 
nicht einmal den Code gelesen, bist aber immer schön brav darauf 
rumgeritten. Mir aber keine angebliche Lesebereitschaft vorwerfen. Das 
ist mehr als nur arrogant. Wie gesagt drehst du dir alles zurecht damit 
alle anderen immer blöd aussehen. Das habe ich schon lange durchschaut. 
Lesekompetenz und Pädagogik sieht anders aus. Wie man dich auf Studenten 
loslassen kann verstehe ich bis heute nicht. Du magst in deiner eigenen 
Programmierwelt bestens zurecht kommen. Aber mit fremden Code tust du 
dich genauso schwer wie viele andere auch. Alles was nicht gefällt wird 
als inkompetent abgestempelt.

Bei allen anderen Vorwürfen gegen mich kann ich nur sagen. Steck ich 
weg. Ich weiß was ich kann und ich weiß was ich nicht kann. Und es 
sollte sich jeder einmal Fragen wofür ein Forum da ist wenn man keine 
Fragen zu Problemen stellen darf? Auch wenn es im nachhinein zu einem 
unerwartenden Ergebnis führt. Das ist eben so. Die Vorarbeit habe ich 
geleistet, Johannes hat es aufgegriffen und verstanden und wie gesagt 
dankend das eigentliche Problem gezeigt. Hat von allen anderen ja auch 
niemand fertig gebracht. Für seine Hilfsbereitschaft und unkomplizierte 
Hilfe wird er jetzt noch angegangen. Also das kann es ja nun auch nicht 
sein. Wirklich nicht.

Der Rest hier folgt wie immer dem gleichen Schema. Wenn das Problem 
geklärt ist melden sich plötzlich alle zu Wort die es schon immer 
gewusst haben.

Auch das Arduino Programmierer hier generell für blöd gehalten werden 
darüber kann ich nur lachen. Da sind durchaus fähige Leute dabei. 
Vorallendingen haben "wir" nicht das große Maul. Das muss ich auch 
einmal klar sagen. Außerdem will ich mal jemanden sehen der so ein 
Gesamtbauwerk wie Arduino programmiert ohne in Probleme zugeraten. Das 
ist ein ständiges abwägen zwischen Kompatibilität zu alten Code und 
Unterstützung für neue Controller. Wenn man eine gewisse Kompatibilität 
über Board wirft und paar neue Features einbaut, dann kommen von fähigen 
Arduino Programmiereren wie MCUdude und SpenceKonde (um mal 2 zu nennen) 
Boarderweiterungen heraus. Sowas würde doch hier niemand freiwillig 
machen und für alle bereit stellen. Das nennt sich Community. Wenn sich 
hier alle auf ihre Kernkompetenz konzentrieren und nicht immer blind 
austeilen würden, dann wäre das hier auch ganz dufte.

Damit beende ich den Thread für mich.

Fpgakuechle K. schrieb:
> IMHO wird hier auch ein konzeptuelles Problem sichtbar, das
> SPI-Peripheral wird nicht übern einen Treiber angesprochen (als mit dem
> Treiberfunktionen Config, read,write) sondern wie ein Speicherobjekt
> über Con- und Destruktoren.

Das Problem liegt m.E. auch an anderer Stelle wie schon oft hier gesagt: 
werden Laufzeitobjekte benutzt für HW-Abstraktionen, müssten sie alle 
als Monostate geschrieben werden. Fehler können erst zur Laufzeit 
entdeckt werden.

Fast alle Abstraktionen von Peripherie sollte m.E. durch statische 
Instanziierung (in C++ aka template-Instanziierung) durchgeführt werden. 
So können alle Prüfungen bzgl. der HW schon zur Compilezeit ausgeführt 
werden. Dies ist m.E. beim Arduino-SW-Framework im Ansatz falsch.

> Ein sauber geschriebener Treiber testet beim config ab, ob überhaupt die
> kompatible Hardware vorliegt (HardwareID o.ä. auslesen) und meldet das
> Ergebnis der Prüfung mit einem Returnwert zurück.

Genau, und das bitte zur Compilezeit. Das geht in C++ durch 
Meta-Funktionen bzw. durch immediate-functions zur Compilezeit. Damit 
spart man sich sehr(!) viel Debugging auf der Zielplattform.

Ich frag mich ja auch, wie das geforderte Minimalbeispiel hätte aussehen 
sollen. Problem war ja, dass bestimmte SFRs nicht initialisiert 
wurden, und egal wieviel und welchen Code man auch entfernt, wird sich 
daran nix ändern. Das Minimalbeispiel wäre also einfach ein leeres 
Programm gewesen...

Nicht ganz. Das Problem ist, daß die älteren Compiler Code erzeugen, der 
nicht ganz zufälligen Werten in die Register schreibt, der aktuelle aber 
nicht.

Oliver

Was aber nix dran ändert, dass es kein sinnvolles Minimalbeispiel gibt.

Man muss den Fehler also schon kennen, um das "Minimalbeispiel" zu 
konstruieren.

Hallo,

ich melde mich doch nochmal zu Wort.

> Der erste Schritt sollte also sein alles rauszuwerfen, was nicht "Register
> setzen" ist. In diesem Fall ist dazu wohl der Aufruf dieses Konstruktors
> nötig.

Genau das hatte ich gemacht indem ich die config() Methode nicht 
aufgerufen habe innerhalb der begin() Methode. Ohne config() passte 
alles. Das Problem hatte also mit der config() Methode und der Klasse 
SPISettingsMegaAVR zu tun. Hatte ich beschrieben. Und genau ab dem Punkt 
kam ich nicht weiter. Tja und dann muss es ja erlaubt sein im Forum zu 
fragen.

Hätte ich einfach geschrieben "Geht nicht, wer kümmert sich darum?" 
hätte ich die Aufregung verstanden. Aber so war es ja nicht.

mh ich empfehle dir einfach mal weniger aufplustern. Man muss nicht 
immer perfekt sein.

Hallo,

ne ne, dass ist schon zur Compilezeit möglich, da muss ich Wilhelm und 
Fpgakuechle schon recht geben. Nur muss man das für sich selbst 
schreiben. Arduino wird das nicht mehr bei sich ändern. Dafür ist das 
Gesamtbauwerk schon zu weit fortgeschritten über die Jahre. Das würde 
einer kompletten Neuprogrammierung gleichkommen. Mit dem Rattenschwanz 
der da dranhängt.

Hallo,

okay, ich hatte beim lesen HardwareID schon mit Controller define für 
mich korrigiert. Das wäre zur Compilezeit möglich. Eine echte HardwareID 
Auswertung ist natürlich nur zur Laufzeit möglich. Da muss ich dir 
wiederum zustimmen.