Forum: Mikrocontroller und Digitale Elektronik Dauerhaft FakeNews in allen AVR Series 0/1/2 Datenblättern

Wie schauts mit der FakeNews Quote bei anderen Herstellern und ihren 
Datenblättern aus?

Ron T. schrieb:
> Wie schauts mit der FakeNews Quote bei anderen Herstellern und ihren
> Datenblättern aus?

Das kommt so häufig vor das die Hersteller praktisch immer auch ein 
"Errata Sheet" in der Doku zum Dabla und Manual dazu packen.

Dort wird bekanntes Fehlverhalten dokumentiert.

KArl Fred M. schrieb:
> Wieso werden die ersten beiden Posts eigentlich negativ bewertet?

das wird gemacht um die Unsinnigkeit der Bewertung zu zeigen!

> Unter welcher geistigen Verirrung leiden hier eigentlich manche?

unter der der normalen Menschheit, die ja nichts lernt, nicht mal aus 
der Geschichte, immerhin haben wir nun 50% Abiquote um mal was Positives 
beizusteuern!
(Kann Ironie enthalten)

Ron T. schrieb:
> Wie schauts mit der FakeNews Quote bei anderen Herstellern und ihren
> Datenblättern aus?

Ich erinnere mich gerade an den Signetics 25120 „fully-encoded, 9046 x N 
Random Access, Write Only Memory“

https://de.wikipedia.org/wiki/Write-Only-Memory

Gruß
Jobst

A. S. schrieb:
> Jim M. schrieb:
>> Das kommt so häufig vor das die Hersteller praktisch immer auch ein
>> "Errata Sheet" in der Doku zum Dabla und Manual dazu packen.
>
> Ist der Fehler da aufgeführt? Falls ja, fühle ich mich veräppelt vom TO.
>
> Oder wird der Fehler in DBn neuer Typen nicht erwähnt und stattdessen
> gleich ein Errata nachgeschoben?
>
> Das man alte Datenblätter (oder auch generische Kapitel bei neuen) nur
> schwer korrigieren kann, sollte klar sein.

Unsinn. Hast Du solche Doku je in der Hand gehabt? Erstens betrifft das 
Errata Sheet die Hardware und nicht etwa Doku-Fehler im Datenblatt. Hier 
scheint mancher nicht zwischen Fehlern in der Hardware und Fehlern im 
Datenblatt unterscheiden zu können. Und warum sollten sich Datenblätter 
in Zeiten downloadbarer PDFs nicht korrigieren lassen?

c-hater schrieb:
> Das muß Absicht sein. Allein durch dramatische Inkompetenz ist das wohl
> nicht zu erklären.

Die Prioritäten scheinen woanders zu liegen als Produkte möglichst 
fehlerfrei zu dokumentieren. Mich hat der obige DB-Bug schon mehrfach 
Stunden sinnloser Fehlersuche gekostet. Daß es Microchip fertig bringt, 
solche Falschaussagen über Jahre und bei so vielen unterschiedlichen 
Typen unkorrigiert zu lassen wollte mir einfach nicht in den Sinn 
kommen. Da scheint öfter Copy&Paste aus früheren AVR-Datenblättern die 
schnelle Vorgehensweise der Wahl zu sein.

Ich kann mir auch nicht vorstellen, daß diesbezüglich noch niemand bei 
Microchip vorstellig wurde. Nachdem ich nun dort selbst aktiv und der 
Fehler bestätigt wurde (mein Support-Ticket ließ man mir offen) bin ich 
schon auf die nächsten neuen Datenblatt-Versionen betreffender 
Controller gespannt!
Sofern sie überhaupt kommen natürlich.

Jim M. schrieb:
> Ron T. schrieb:
>> Wie schauts mit der FakeNews Quote bei anderen Herstellern und ihren
>> Datenblättern aus?
>
> Das kommt so häufig vor das die Hersteller praktisch immer auch ein
> "Errata Sheet" in der Doku zum Dabla und Manual dazu packen.
>
> Dort wird bekanntes Fehlverhalten dokumentiert.

Naja, hier gibt's ja zwei mögliche Fehlerarten. Das eine sind Fehler im 
Silizium, wo etwas nicht so funktioniert, wie es gedacht war, das andere 
sind Fehler im Datenblatt, die das Verhalten falsch dokumentieren.

Fpgakuechle K. schrieb:
> KArl Fred M. schrieb:
>> Wieso werden die ersten beiden Posts eigentlich negativ bewertet?
>
> Weil rummeckern ohne exakte Beschreibung des konkreten Fehlerbildes eben
> negativ bewertet wird.

Das "Fehlerbild" wurde doch beschrieben. Nur ist eben die Frage, was es 
bringen soll, sich hier über einen Fehler in den AVR-Datenblättern zu 
beschweren. Das einzige wäre, dass andere, die in diese Falle tappen, 
hier diese Information finden können. Dafür ist aber die Überschrift 
nicht sonderlich gut gewählt.

c-hater schrieb:
> dass das Durchlaufen des
> Interruptvektors den Interrupt zurück setzen würde. Genau das passiert
> aber nachweislich nicht.

Und wir wissen ja auch, das es für viele Peripherie in den AVR8 
funktioniert. Ich vermute deswegen schlicht und einfach einen nie 
korrigierten Hardware Bug im SPI Block und ein Datenblatt, das die 
Wahrheit ignoriert.

c-hater schrieb:
> sondern auch diverse andere
> Interrupts.

Und welche sind das?

Fpgakuechle K. schrieb:
> Die fRage ist eben, was "executing the corrosponding vector" aus Sicht
> der Dokumentation bedeudet?! Mancherorts steht geschrieben, das man bei
> Abarbeitung der ISR auf das Datenregister zugreift und dann wird das
> Flag gelöscht. Genau so macht das aus Sicht eines IC-Entwicklers (BTW:
> meine Sicht) Sinn. Wenn man dagegen die Doku allein so versteht, das das
> reine Anspringen des Vectors genügen würde, unabhängif davon auf welche
> register der Code dort tatsächlich zugreift, dann hat man die Doku
> überinterpretiert.

„The IF is cleared by hardware when executing the corresponding 
interrupt vector. Alternatively, the IF can be cleared by first reading 
the SPIn.INTFLAGS register when IF is set and then accessing the 
SPIn.DATA register.“

Da gibts nichts zu interpretieren.

Oliver

Fpgakuechle K. schrieb:
> Oliver S. schrieb:
>
>> „The IF is cleared by hardware when executing the corresponding
>> interrupt vector. Alternatively, the IF can be cleared by first reading
>> the SPIn.INTFLAGS register when IF is set and then accessing the
>> SPIn.DATA register.“
>>
>> Da gibts nichts zu interpretieren.
>
> Doch. "executing the corresponding interrupt vector"
> vector ist ein synonym für Addresse.

Nein. Beim AVR ist ein Interrupt-Vektor eine Instruktion, die ausgeführt 
wird, wenn der Interrupt ausgelöst wird. In der Regel nimmt man dafür 
einen Sprungbefehl, der dann zum Anfang der ISR springt.
Und laut dem ersten Satz oben, wir bei Ausführung dieses Befehls 
gleichzeitig automatisch von der Hardware das Interrupt flag gelöscht. 
Auch da gibt's keinen Spielraum für Interpretation.

Ja und? Der Begriff "vector" gehört zum interrupt handling, nicht zu 
SPI.

Oliver

Fpgakuechle K. schrieb:
> Also in dem oben genannten ausführlichen Dokument zu SPI (TB3215) kommt
> 'vector' oder 'vektor'  nicht vor :-(

Das ist ja auch nur eine Application Note, die sich mit den Interrupts 
nur im Bezug auf die entsprechenden Flags beschäftigt. Den Rest holt man 
eher aus dem Datenblatt des jeweiligen Prozessors.

Fpgakuechle K. schrieb:
> Meine Erfahrung zeigt, das man sich und anderen leichter tut, nicht von
> 'Fehler' zu reden und'Korrektur' einzufordern, stattdessen v.
> "Missverständnissen", "suboptimalen Formulierungen" sprechen

Was soll der Quatsch?
Die getroffene Aussage ist schlicht falsch und gehört korrigiert. In 
allen Series 0/1/2 Datenblättern und das seit Jahren. Warum versuchst Du 
das hier zu relativieren? Nachdem sich das Interruptverhalten aller 
neueren AVRs geändert hat dürfte es sich mit höchster Wahrscheinlichkeit 
auch um keinen Hardware-Bug handeln.

Vom 4808 etwa kann ich berichten, daß das SPI IF Flag ebenso mit dem 
Schreiben einer 1 an die Register- Position zu löschen ist. Nach eigenem 
Herumtesten. Das ist bei anderen Interruptregistern (richtig 
dokumentiert) genauso.

Fpgakuechle K. schrieb:
> der TO bezieht sich hier auf einen µC, der 2018 vorgestellt wurde

Wie kommst Du jetzt darauf?
Ich sprach von ALLEN Series 0/1/2 Typen. Bis zu den allerneuesten, noch 
nicht erhältlichen AVRxxDD.

Dieter schrieb:
> Fpgakuechle K. schrieb:
>> Diese Absicht ist sicher gerechtfertigt.
>
> Vermutlich in der Hoffnung, das ein Asiate beim Nachbau des Chips dabei
> sich genau an das Datenblatt hält. Dann funktioniert der Nachbauchip
> falsch gegenüber dem echten Chip.

Dann ist er quasi nicht Bugkompatibel.

Ron T. schrieb:
> Was soll der Quatsch?
> Die getroffene Aussage ist schlicht falsch und gehört korrigiert.

Bei Generation Snowflake gibt es kein "falsch". Alles ist per Definition 
richtig, und es gibt nur unterschiedlich viel Potenzial, um es noch 
besser zu machen.

Im übrigen brauchen wir hier nicht lange heruminterpretieren seitdem der 
Dokumentationsfehler von Microchip höchstselbst bestätigt ist.

Stefan ⛄ F. schrieb:
> Es wäre besser gewesen, den Series 0/1/2 Typen einen ganz anderen Namen
> zu geben.

Finde ich genauso.
Immerhin, die AVRxxDx pflegen ein neues Namens-Schema.

Fpgakuechle K. schrieb:
> Eigentlich geht es um eine Beschreibung wie man es richtig macht,

Eigentlich geht es hier um korrekte Datenblätter!

> Manchmal wird der Chip eben nie fertig

Bei Datenblättern besteht diese Möglichkeit aber. Zumal nach Jahren.

> Datasheet Preliminary

Die Series 0/1/2 hat durchaus Vertreter bei denen dieser Status 
überwunden ist. Z.B. beim schon erwähnten 4808.

Wühlhase schrieb:
> Was haben Fehler im Datenblatt mit bewußt lancierten Falschnachrichten
> zu tun?

FakeNews war so reißerisch überdreht wie der beschriebene Bug 
unverschämt lange unkorrigiert :) Ich nehm die FakeNews zurück.

c-hater schrieb:
>  Das ist insofern blöd, als dass die die Macht über
> die Datenblätter haben...

Nö, schreib doch einfach eigene. ;P

Ron T. schrieb:
> Ich nehm die FakeNews zurück.

Schade, das nimmt dem Thread die Rekursion.

Fpgakuechle K. schrieb:
> PS:
> Das Ganze wurde doch schon x-Mal diskutiert:
> Beitrag "ATtiny817, SPI ISR löscht IF nicht"
> Beitrag "Arduino 841 ISR SPI"
> Beitrag "ATmega809 - SPI empfängt 1 Byte und dann nie wieder"

Mir wär die Überwindung dieser Rekursion lieber. Solche fahrlässigen 
Datenblatt-Fehler dürften schon so einige Debugging-Stunden gekostet 
haben.

Fpgakuechle K. schrieb:
> falls sich also ein Ding nicht wie beschrieben verhält, dann analysiert
> man das

Etwas anderes bleibt auch nicht übrig. Aber muß das sein? Du kommst aus 
dem Relativierungs-Trip harter Datenblatt-Fehler einfach nicht raus...

> manche Produkte/Datenblätter sind erst mit
> 18 halbwegs reif.

dito.

Fpgakuechle K. schrieb:
> das erspart einem die Suche

Viel Erfahrung beim Auffinden von Datenblättern scheinst Du nicht zu 
haben.

Fpgakuechle K. schrieb:
> Sollte man aber dem Mephisto aus Faust zustimmen ?!?

Im Zusammenhang mit Datenblättern könnte man da glatt an "schwarz auf 
weiß" denken.

Fpgakuechle K. schrieb:
> wenn du weder Typ

Mit 4808 ist ein AtMega4808 gemeint. Falls Du daran gescheitert sein 
solltest...

> Eben konstruktiver Umgang um Technik, dein Berufswunsch im Kindergarten

Dein lockerer Umgang mit Datenblatt-Inhalten erinnert sicher nicht an 
professionelle Arbeitsweise sondern eher an... du hast es gesagt, 
Kindergarten!

> Aber darauf scheinst du es ja anzulegen, Leute in die Irre zu schicken
> und deren zeit zu stehlen.

Ich lege es sicher nicht drauf an daß Du hier Deine Zeit zur 
Relativierung vermeidbarer Fehler verschwendest.

Rolf M. schrieb:
> Bei Generation Snowflake gibt es kein "falsch". Alles ist per Definition
> richtig, und es gibt nur unterschiedlich viel Potenzial, um es noch
> besser zu machen.

Ist manchmal echt ne Herausforderung.

Rolf M. schrieb:
> Nein. Beim AVR ist ein Interrupt-Vektor eine Instruktion, die ausgeführt
> wird, wenn der Interrupt ausgelöst wird. In der Regel nimmt man dafür
> einen Sprungbefehl, der dann zum Anfang der ISR springt.

Und was, wenn nicht gesprungen wird, weil die ISR direkt dort beginnt?
Einfach, weil dort genug Platz ist? Oder weil man den Sprung sparen 
möchte?

Nein, der Vektor ist die feste(!) Adresse, ab der Code im Falle eines 
IRQs abgearbeitet wird. Wenn dort ein Sprung zu einer variablen Adresse 
Deiner ISR steht, dann gehört dies aus Prozessorsicht schon zur ISR.

Stefan ⛄ F. schrieb:
> Also nicht ATtiny 4808, sondern z.B. Xtiny 4808 oder neoAVR 4808. Dann
> wäre auch jedem Anfänger klar welche nun zu den klassischen AVR zählen,
> und welche nicht.

Die ganzen verPICkelten Controller müssten konsequenterweise MCtiny oder 
MCmega heißen. Kommen ja nun von MyCropChip, nicht mehr von Atmel.
Ich warte ja darauf, dass sie dort, wie beim PIC, primzahllange Register 
einbauen.


Gruß
Jobst

Jobst M. schrieb:
> Rolf M. schrieb:
>> Nein. Beim AVR ist ein Interrupt-Vektor eine Instruktion, die ausgeführt
>> wird, wenn der Interrupt ausgelöst wird. In der Regel nimmt man dafür
>> einen Sprungbefehl, der dann zum Anfang der ISR springt.
>
> Und was, wenn nicht gesprungen wird, weil die ISR direkt dort beginnt?
> Einfach, weil dort genug Platz ist? Oder weil man den Sprung sparen
> möchte?

Was soll dann sein? Dann wird von dort eben nicht gesprungen. Deshalb 
schrieb ich "in der Regel". Einen Zwang, dass da ein Sprungbefehl stehen 
muss, gibt es nicht.

> Nein, der Vektor ist die feste(!) Adresse, ab der Code im Falle eines
> IRQs abgearbeitet wird.

Der Interrupt-Vektor ist ein Element der Interrupt-Vektor-Tabelle. 
Elemente der Tabelle sind keine Adressen, sondern haben Adressen.
Aus dem Datenblatt des Atmega88/168:
"All interrupts have a separate interrupt vector in the interrupt vector 
table. The interrupts have priority in accordance with their interrupt 
vector position."

Die "interrupt vector position" ist die Adresse, von der du sprichst. 
Der "interrupt vector" ist das, was an dieser Adresse steht.

Rolf M. schrieb:
> Der "interrupt vector" ist das, was an dieser Adresse steht.

Sehe ich anders. So wie hier:
https://en.wikipedia.org/w/index.php?title=Interrupt_vector

Gruß
Jobst

Rolf M. schrieb:
> Elemente der Tabelle sind keine Adressen, sondern haben Adressen.

Das ist in diesem Fall gleichbedeutend. Das einzig Wesentliche an der 
Position in der Interruptvektortabelle ist ja gerade nur deren Adresse 
(= der Interruptvektor) der darin angesprungen wird. Was sollten die 
"Elemente der Tabelle" denn sonst sein außer fixe Adressen im Speicher?

Hmmm, interessant, bei den AVRs bin ich da nie drüber gestolpert da ich 
den SPI nie so langsam benutzt habe das ein Interrupt überhaupt Sinn 
gemacht hätte.

https://github.com/MicrochipTech/TB3215_Getting_Started_with_SPI

Ah, ok, in den Beispielen nutzen die den Interrupt im Slave-Mode.


Aber jetzt schaue ich gerade mal interessiert auf das 4809 Datenblatt 
und um das nochmal zu zitieren:

"Bit 7 – IF Interrupt Flag
This flag is set when a serial transfer is complete, and one byte is 
completely shifted in/out of the SPIn.DATA register.
If SS is configured as input and is driven low when the SPI is in Host 
mode, this will also set this flag. The IF is
cleared by hardware when executing the corresponding interrupt vector. 
Alternatively, the IF can be cleared by first
reading the SPIn.INTFLAGS register when IF is set and then accessing the 
SPIn.DATA register."

In der Application Note die oben verlinkt ist findet sich das hier:

1

ISR(SPI0_INT_vect)

2

{

3

receiveData = SPI0.DATA;

4

SPI0.DATA = writeData;

5

SPI0.INTFLAGS = SPI_IF_bm; /* Clear the Interrupt flag by writing 1 */

6

}

Ist jetzt nur ein Gedankenspiel da ich keinen 4809 habe um das 
auszuprobieren.
Und jetzt mal abgesehen davon das da steht, dass das Flag automatisch 
gelöscht wird, aber müsste dem Datenblatt nach die ISR nicht eher so 
aussehen?

1

ISR(SPI0_INT_vect)

2

{

3

(void) SPI0.INTFLAGS; /* prepare clearing the interrupt flags */

4

receiveData = SPI0.DATA; /* the flags should be cleared now */

5

SPI0.DATA = writeData;

6

}

Also die mit der Application Note vorgestellte alternative Version des 
Interrupt-Handling hat doch auch nichts mit dem Datenblatt zu tun?
Das ist ja jetzt nicht so ungewöhnlich das Flags gelöscht werden wenn 
man da eine 1 rein schreibt, nur steht das ja so auch nicht im 
Datenblatt.

Edit:
https://github.com/MicrochipTech/TB3215_Getting_Started_with_SPI/blob/master/ATmega4809_SPI_Examples/Receiving_Data_as_Slave/main.c

Das ist also schon direkt für den 4809.

Soviel unnütze Konfusion wegen Datenblatt-Fehlern. Echt ärgerlich.
Kann natürlich nicht Aufgabe des Entwicklers sein, sich die richtigen 
Informationen irgendwo zusammensuchen und Widersprüche aufdecken zu 
müssen.

Im Datenblatt eines AVR128DBxx findet sich in der Beschreibung des 
Interrupt-Controllers der richtige Satz "The interrupt flags are not 
automatically cleared after the interrupt is executed. The respective 
INTFLAGS register
descriptions provide information on how to clear specific flags." bloß 
um dann bei der Beschreibung des entsprechenden INTFLAGS das Gegenteil 
(siehe Eröffnungs-Posting) lesen zu müssen.

Also nochmal und speziell für den SPI-Interrupt meinen Stand der Dinge:
IF wird beim Eintritt NICHT gelöscht, INTFLAGS muß gelesen und dann aufs 
SPI_DATA zugegriffen werden (was man ja dort sowieso macht), alternativ 
zum Lesen von INTFLAGS kann auch eine 1 in die IF-Position geschrieben 
werden und somit sind neben der Register-Sicherung die Dinge im 
Interrupt formal erledigt. Ein nicht gelöschtes IF würde den Interrupt 
in hoher Frequenz neu aufrufen lassen- eine schöne Debugging Aufgabe.

Rudolph R. schrieb:
> da ich
> den SPI nie so langsam benutzt habe das ein Interrupt überhaupt Sinn
> gemacht hätte

Erstaunlich.
Interrupts machen die SPI-Abwicklung doch eher schnell :)

KArl Fred M. schrieb:
> Wieso werden die ersten beiden Posts eigentlich negativ bewertet?
> Unter welcher geistigen Verirrung leiden hier eigentlich manche?
> Ich finde das Thema interessant und da es kein Unsinn ist ist, verstehe
> ich diese Bewertungen einiger hier nicht

Die Leute bewerten nach hier individuellen Kriterien. Beispielsweise der 
Härte ihres Stuhlgangs.

Ron T. schrieb:
> Rudolph R. schrieb:
>> da ich
>> den SPI nie so langsam benutzt habe das ein Interrupt überhaupt Sinn
>> gemacht hätte
>
> Erstaunlich.
> Interrupts machen die SPI-Abwicklung doch eher schnell :)

Nicht notwendigerweise: eine direkte Abfrage der entsprechenden Flags 
kann schneller sein, da der push/pop-Overhead der ISR entfällt.

Ron T. schrieb:
> Soviel unnütze Konfusion wegen Datenblatt-Fehlern. Echt ärgerlich.
> Kann natürlich nicht Aufgabe des Entwicklers sein, sich die richtigen
> Informationen irgendwo zusammensuchen und Widersprüche aufdecken zu
> müssen.

Ein Datenblatt ist ein Artefakt wie ein Stück Software, leider ohne 
Compiler und Testenvironment.
Jetzt einfach mal selbst die Frage stellen, wie viele Zeilen Code ihr 
fehlerfrei ohne Compiler und ohne Tests hinschreiben könnt.
Und: wer von Euch hat den Fehler schon bei MicroChip gemeldet?

Stefan ⛄ F. schrieb:
> Rolf M. schrieb:
>> Der Interrupt-Vektor ist ein Element der Interrupt-Vektor-Tabelle.
>> Elemente der Tabelle sind keine Adressen, sondern haben Adressen.
>
> Das hat er bestimmt mit ARM verwechselt.

Eine Tabelle ist ein benanntes Objekt, damit hat es eine Adresse, und 
damit hat auch jedes Element darin eine Adresse. Egal welchen Inhalt ein 
Element hat. Da gibt es nichts zu verwechseln.

Wilhelm M. schrieb:
> Jetzt einfach mal selbst die Frage stellen, wie viele Zeilen Code ihr
> fehlerfrei ohne Compiler und ohne Tests hinschreiben könnt.
> Und: wer von Euch hat den Fehler schon bei MicroChip gemeldet?

Schön und gut.
Doch hier liegt der Fehler im System.
Da werden offensichtlich Datenblattpassagen zwischen (in Details) 
inkompatiblen Controllern hin und her kopiert. Da werden Fehler *über 
Jahre* nicht korrigiert. Unmöglich, daß ich vor Wochen der Einzige war, 
der diesen schweren Bug in der Zwischenzeit gemeldet hat.

Ron T. schrieb:
> Da werden offensichtlich Datenblattpassagen zwischen (in Details)
> inkompatiblen Controllern hin und her kopiert.

In Software genauso.

Ron T. schrieb:
> Da werden Fehler *über
> Jahre* nicht korrigiert.

s.o.

Ron T. schrieb:
> Unmöglich, daß ich der vor Wochen der Einzige
> war, der diesen schweren Bug in der Zwischenzeit gemeldet hat.

Bei MicroChip gemeldet? Poste mal den Link dazu?

Nun, ich denke, alle anderen sind davon ausgegangen, dass die IF immer 
gleich behandelt werden, also i.a. explizit zurück gesetzt werden müssen 
(es sei denn, das Lesen eines anderen Registers erledigt das ggf.)

Wilhelm M. schrieb:
> In Software genauso.

Auch Du verharmlost.
Die Betonung lag auf 'inkompatibel'.
Das ist keine professionelle Verfahrensweise.
Und auf Bug-Meldungen über Jahre nicht zu reagieren sowieso.

Wilhelm M. schrieb:
> Bei MicroChip gemeldet? Poste mal den Link dazu?

Inwieweit der Fall ohne meine persönliche Anmeldung lesbar ist weiß ich 
nicht. Case-Nummer wäre die 00965546, Subject: "Wrong SPI-Interruptflag 
Reset Description (all AVR Series 0/1/2)", letzte Reaktion:

"We have reported the bug to the corresponding internal team and 
expecting a reply from them.
I will keep you posted once there is an update. Till then, keeping this 
case in ACR status"

Ron T. schrieb:
> Inwieweit der Fall ohne meine persönliche Anmeldung lesbar ist weiß ich
> nicht. Case-Nummer wäre die 00965546, Subject: "Wrong SPI-Interruptflag
> Reset Description (all AVR Series 0/1/2)", letzte Reaktion:

Die case Nummer wird nicht gefunden.

Ron T. schrieb:
> Wilhelm M. schrieb:
>> In Software genauso.
>
> Auch Du verharmlost.

Das soll keine Verharmlosung sein, denn in Software können Bugs auch 
sehr kritisch sein, wie Du weißt, und werden auch nicht behoben.

> Die Betonung lag auf 'inkompatibel'.

Ist mir entgangen, da ich den Thread nicht von Anfang an gelesen habe.

> Das ist keine professionelle Verfahrensweise.
> Und auf Bug-Meldungen über Jahre nicht zu reagieren sowieso.

Dann ist keine Firma auf dieser Welt professionell.

Wilhelm M. schrieb:
> Die case Nummer wird nicht gefunden.

Du hast sicher Verständnis dafür daß ich dem jetzt nicht auf den Grund 
gehe. Wenn es so wäre wär das auch kein gutes Zeichen -  für Microchip.

Wilhelm M. schrieb:
> Ist mir entgangen, da ich den Thread nicht von Anfang an gelesen habe.

Nö. Das 'inkompatibel' stand im Beitrag zuvor.

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Die case Nummer wird nicht gefunden.
>
> Du hast sicher Verständnis dafür daß ich dem jetzt nicht auf den Grund
> gehe. Wenn es so wäre wär das auch kein gutes Zeichen -  für Microchip.

Da steht: created 28.04.22 ...

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Ist mir entgangen, da ich den Thread nicht von Anfang an gelesen habe.
>
> Nö. Das 'inkompatibel' stand im Beitrag zuvor.

Textbausteine sind Textbausteine.

Wilhelm M. schrieb:
> Da steht: created 28.04.22 ...

Das Datum der letzten Reaktion, ja.

Wilhelm M. schrieb:
>> Das ist keine professionelle Verfahrensweise.
>> Und auf Bug-Meldungen über Jahre nicht zu reagieren sowieso.
>
> Dann ist keine Firma auf dieser Welt professionell.

Das ist in meinen Augen, bei diesen Firmen und in einer solchen simplen 
Doku-Sache grober Unfug. Wenn Du das so rechtfertigen willst...

Ron T. schrieb:
> Das ist in meinen Augen, bei diesen Firmen und in einer solchen simplem
> Doku-Sache grober Unfug. Wenn Du das so rechtfertigen willst...

Ich will gar nichts rechtfertigen. Ich sage nur, dass Du keine 100% 
korrekten Datenblätter erwarten kannst. Ebenso wie fehlerfreie Software.

Natürlich ist es ärgerlich, wenn einen das betrifft, genauso wie ein 
silicon-bug. Und es ist auch blöd, wenn das nicht in ein errata 
aufgenommen wird.
Do sorry, so ist die Welt. Und Dein Anspruch 100%-fehlerfreier 
Datenblätter ist absolut utopisch.

Wilhelm M. schrieb:
> Und Dein Anspruch 100%-fehlerfreier
> Datenblätter ist absolut utopisch.

Datenblätter trotz Bugmeldungen über Jahre unkorrigiert zu lassen ist 
eben NICHT utopisch. Das betrifft inzwischen eine Unmenge von 
Controllern. Würdest Du diesen Sachverhalt mal zur Kenntnis nehmen?

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Und Dein Anspruch 100%-fehlerfreier
>> Datenblätter ist absolut utopisch.
>
> Datenblätter trotz Bugmeldungen über Jahre unkorrigiert zu lassen ist
> eben NICHT utopisch.
> Das betrifft inzwischen eine Unmenge von
> Controllern. Würdest Du diesen Sachverhalt mal zur Kenntnis nehmen?

Habe ich doch ganz oben schon, und ich habe das doch gar nicht 
abgestritten.

Es ist nur so, dass ggf. Du der einzige bist, der diesen Fehler gemeldet 
hat. Alle anderen haben das ggf. intuitiv richtig gemacht. Da gerade 
eine Firma mit Ressourcen haushalten muss, kommt dieser Bug damit in 
seiner Prio ganz weit nach unten. Außerdem steht er ja noch auf ACR ...

Ron T. schrieb:
> Rudolph R. schrieb:
>> da ich
>> den SPI nie so langsam benutzt habe das ein Interrupt überhaupt Sinn
>> gemacht hätte
>
> Erstaunlich.
> Interrupts machen die SPI-Abwicklung doch eher schnell :)

Nun, bei 16MHz Core-Takt und 8MHz SPI-Takt ist 1 Byte auf dem SPI doch 
nur für 16 Takte untwerwegs.
Laut Datenblatt braucht der 4809 sogar mindestens 6 Zyklen um in die ISR 
zu kommen, also in die nackte ISR wenn sonst nichts gesichert werden 
muss.
Für die alten AVR galt mal die ISR braucht mindestens 4 Takte rein und 4 
Takte raus.
So dauert das verschicken von einigen Bytes über den SPI länger als mit 
Polling, weil die Pausen zwischen den Bytes länger werden und wirklich 
was machen kann der Core in den paar Takten ohne Interrupt auch nicht.

Das bringt also nur was wenn man einen niedrigen SPI Takt hat.

Wilhelm M. schrieb:
> Da gerade
> eine Firma mit Ressourcen haushalten muss, kommt dieser Bug damit in
> seiner Prio ganz weit nach unten.

Schön daß Du diese Ausrede "gerade" noch an den Haaren herbeiziehen 
konntest :)

Doch ist auch sie nicht stimmig: Wir reden nicht von "gerade" sondern 
über einen Zeitraum von mindestens 3 Jahren, seit die Series 0/1/2 das 
Licht der Welt erblickte.

Meine Prognose wäre ja, auch meine Bug-Meldung wird im Nirgendwo 
verschallen.

Rudolph R. schrieb:
> So dauert das verschicken von einigen Bytes über den SPI länger als mit
> Polling,

Da hast Du Recht. Aber nur für relativ einfach gestrickte Programme.
Ein wenig Interrupt-Verarbeitung und Deine Rechnung ist beim Teufel.

Ron T. schrieb:
> Rudolph R. schrieb:
>> So dauert das verschicken von einigen Bytes über den SPI länger als mit
>> Polling,
>
> Da hast Du Recht. Aber nur für relativ einfach gestrickte Programme.
> Ein wenig Interrupt-Verarbeitung und Deine Rechnung ist beim Teufel.

Was meinst Du damit? Es wird noch schlimmer?
Es ist ja jetzt nicht so, als könnte die Hauptschleife die Daten in den 
paar Takten verarbeiten, erst recht nicht wenn man noch Flags setzen, 
löschen und auswerten muss.
Ich hatte jetzt nur an den einfachsten Fall gedacht das ein Puffer per 
SPI verschickt werden soll, selbst das wird mit einem Interrupt schon 
länger dauern. Und bei hohem SPI Takt kommt die Hauptschleife in der 
Zeit kaum vorwärts.

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Da gerade
>> eine Firma mit Ressourcen haushalten muss, kommt dieser Bug damit in
>> seiner Prio ganz weit nach unten.
>
> Schön daß Du diese Ausrede "gerade" noch an den Haaren herbeiziehen
> konntest :)
>
> Doch ist auch sie nicht stimmig: Wir reden nicht von "gerade" sondern
> über einen Zeitraum von mindestens 3 Jahren, seit die Series 0/1/2 das
> Licht der Welt erblickte.
>
> Meine Prognose wäre ja, auch meine Bug-Meldung wird im Nirgendwo
> verschallen.

Oh man, hast Du jetzt ein Problem damit, dass Du der letzte bist, der 
diesen Fehler im DB erkannt hat? Alle anderen haben erkannt, dass die 
Architektur der internen Peripherie umgestaltet wurde und freuten sich 
über die reguläre Struktur ...

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Da gerade
>> eine Firma mit Ressourcen haushalten muss, kommt dieser Bug damit in
>> seiner Prio ganz weit nach unten.
>
> Schön daß Du diese Ausrede "gerade" noch an den Haaren herbeiziehen
> konntest :)

Das ist keine Ausrede, sondern ökunomische Tatsache, wenngleich etwas 
traurig in Deinem Fall.

Wilhelm M. schrieb:
> Das ist keine Ausrede, sondern ökunomische Tatsache, wenngleich etwas
> traurig in Deinem Fall.

Ich finde es (für einen Entwickler?) traurig, Datenblätter mit Software 
gleichzusetzen und offensichtliche jahrelange Missstände nicht 
wahrhaben, ja entschuldigen zu wollen. Arbeitest Du in diesem Laden?

Euro schrieb:
> Will nicht heißen, dass bei fleißiger Rückmeldung der Anwender solche
> Bugs nicht behebbar sind,

Bevor auf irgendwelche Bugmeldungen überhaupt reagiert werden muß würde 
ich erst mal erwarten, daß Datenblätter bei offensichtlicher 
Hardware-Inkompatibilität nicht in Copy&Paste Manier erstellt werden und 
mehrere HW-Kundige (!) da mal drüberlesen. Und dann würde ich erwarten, 
daß auf Bugmeldungen dann tatsächlich und zeitnah reagiert wird- was 
gibt es hier besseres und schneller hilfreiches als zielgerichtete 
Hinweise aus der Anwenderschaft.
Hier krankt es bei Microchip an allen Fronten-  trotz viel 
Werbe-Blendwerk mit allerhand Qualitäts-Zertifizierungen.
Mach Dir mal eins klar: Jeder dieser billigen und nun wirklich 
vermeidbaren (nur Doku!) Fehler zieht weltweit eine Menge unnützen 
Ärgers und Entwicklerzeit nach sich.

Ich werde die Angelegenheit weiter verfolgen. Mal sehen wieviel Jahre es 
noch braucht, die dutzenden, an dieser Stelle immer gleich falschen 
Datenblätter neuerer AVRs zu korrigieren.

Rudolph R. schrieb:
> Was meinst Du damit?

Damit meine ich, daß die Effizienz von Programmen mit Polling-Methoden 
generell leidet. Wenn es sonst nichts zu tun gibt und Du es Dir 
eingleisig leisten kannst, im Hauptprogramm auf eine Puffer-Ausgabe zu 
warten mag das die schnellste Lösung sein.

Fpgakuechle K. schrieb:
> an einer schnellen Problemlösung höchstens am Rand interessiert

Das leitest Du woraus ab?
Und wolltest Du nicht eigentlich hier keine weitere Zeit verschwenden?

H. H. schrieb:
> Du kannst das ändern!
> https://careers.microchip.com/jobsearch

Analog die gekränkten Experten-Reaktionen etwa bei Kritik in 
Linux-Threads: "Immer nur meckern, warum arbeitest Du nicht selber am 
Kernel mit?"

Viele Leute werden den SPI Interrupt vektor nicht verwenden weil er 
redundant ist. Die meisten duemmlichen Compuiler pushen alle Register 
und popen sie nachher wieder. Da bin ich schneller, wenn ich auf's Ready 
flag warte, vorausgesetzt mal laesst den SPI mit maximaler 
Geschwindigkeit laufen

Purzel H. schrieb:
> Die meisten duemmlichen Compuiler pushen alle Register
> und popen sie nachher wieder.

Das trifft allerdings auf den GCC seit Jahren nicht mehr zu.

Fpgakuechle K. schrieb:
> Also die angebliche 'Bestätigung' deiner ominösen Fehlerbestätigung
> besteht darin das das Support-ticket offen blieb?

Um genau zu sein, scheint es ja noch auf "ACR" zu stehen (awaiting 
customer reaction).

Fpgakuechle K. schrieb:
> Die sind schon lange da und das von dir bemoserte Datenblatt ist vor
> Jahren offiziel gecanceled und ersetzt worden.
> Und natürlich musste auch prüfen ob das neue Datenblatt auch 'dein'
> Device  abdeckt.

Ja schon, jedoch hat er insofern Recht, dass der Doku-Bug immer noch 
drin ist ...

Fpgakuechle K. schrieb:
> Wilhelm M. schrieb:
>>> Die sind schon lange da und das von dir bemoserte Datenblatt ist vor
>>> Jahren offiziel gecanceled und ersetzt worden.
>
>> Ja schon, jedoch hat er insofern Recht, dass der Doku-Bug immer noch
>> drin ist ...
>
> Nun, das ist vergleichbar mit einer Beschwerde wie "Der Wetterbericht
> vom 18. Juli 1877 für Pressburg im "Tagesblatt" ist falsch".
>
> Eine beendete Doku wird nicht korregiert und wer auf Änderungen in nicht
> mehr supporteten Dokumenten besteht ist selber Schuld.

Was ich meinte, ist, dass dies in der gesamten, aktuellen Doku nicht 
drin steht, auch nicht in den Errata.

Fpgakuechle K. schrieb:
> Eben, es fehlen wohl entscheidende Informationen zur weiteren
> Bearbeitung wie konkreter Typ, link auf betroffenen aktuelle
> Dokumentation und Beschreibung die eine Reproduktion des Fehlers
> ermöglicht

Unglaublich was sich manche Leute hier immer noch aus den Fingern saugen 
:)

Fpgakuechle K. schrieb:
> an einer schnellen Problemlösung höchstens am Rand interessiert

Eben. Anders sind Deine Beiträge auch nicht zu erklären.


Euro schrieb:
> Das von Dir genannte Prozedere ist Usus, aber kein Erfolgsgarant.

Jedem wirklich HW-Kundigen dürfte der genannte Doku-Fehler sofort 
auffallen. Ich meine, wir reden hier von den Experten des Herstellers 
die es am besten wissen müssen.
Hinweise dürfte es über die Jahre und bei irgendeinem der Dutzenden 
neuer AVRs längst gegeben haben. Also herzlich wenig überzeugend dieser 
Einwand.

Ron T. schrieb:
> Das ist keine professionelle Verfahrensweise.

professionel bedeutet GELD verdienen und das tun sie
weil sie

> Und auf Bug-Meldungen über Jahre nicht zu reagieren sowieso.

was ja Geld kostet wenn das einer bearbeitet!

Ist doch voll normal, wann immer ich Bugs gemeldet hatte, auch wenn sich 
im Netz schon lange darüber sinniert wurde! Stets hiess es: "sie sind 
der Erste der das meldet"

Auch wenn das sowas von unglaubwürdig ist!

c-hater schrieb:
> Aber er pusht bei vielen Projekten immer noch weit mehr, als tatsächlich
> nötig wäre.

Naja, ab avr-gcc-8 oder so emittiert der avr-gcc Compiler dort die 
Pseudo-Instruktionen __gcc_isr 1 zu Beginn der ISR und am Ende __gcc_isr 
2, und der avr-as scanned den Code dazwischen auf die benutzten 
Register, und dann fügt er die push/pop Sequenzen ein. Also, er macht 
nur das Notwendige in Bezug auf den generierten Code.
Dies kann natürlich in der Gesamtschau des Projektes immer noch 
ungünstig sein, weil es keine globale Allokationsstrategie gibt.

Die meisten kritisieren das hier ja sehr vehement, aber ich benutze 
header-only (Bibliotheken) C++-Code meistens ganz ohne ISR, und das 
Ergebnis ist damit meistens besser: der Compiler kann alles zusammen 
optimieren (ähnlich wie bei LTO, aber eben auch für alle Bibliotheken) 
und der Verzicht auf ISR bedeutet ein Verzicht auf Optimierungsschranken 
via volatile und eben überflüssige push/pop in (nicht vorhandenen) ISRs.

c-hater schrieb:
> Richtig. Bei 24MHz Takt und im Slavebetrieb sieht das aber schon ganz
> anders aus.

Und bei 32MHz noch anders ;-)

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> Und bei 32MHz noch anders ;-)
>
> Nunja. Wenn's schief geht, muss man halt erklären, warum man die vom DB
> gesetzten Grenzen verlassen hat. Solange es läuft, kräht sicher kein
> Hahn danach.

Naja, bei den AVR-DA/DB/DD sind es alles nicht-kommerzielle Projekte. 
Von daher alles gut. Ich glaube, Spence Konde hatte da mal eine 
ausführliche Testreihe gemacht.

https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Ref_Clocks.md

> Ich persönlich habe bisher allerdings tatsächlich auch in recht
> komplexen Anwendungen der AVR128Dx keine Anzeichen für Fehlfunktionen
> bei 32MHz Systemtakt feststellen können.

Hatte ich auch noch nie, und bin auch sehr froh über die ausreichende 
Genauigkeit des internen RC-Oszillators.

Bei 24MHz Core-Takt würde ich den SPI aber auch auf 12MHz laufen lassen. 
:-)
Richtig schick wäre ja, wenn die DMA könnten.

Joachim B. schrieb:
> Ist doch voll normal, wann immer ich Bugs gemeldet hatte, auch wenn sich
> im Netz schon lange darüber sinniert wurde! Stets hiess es: "sie sind
> der Erste der das meldet"

Das Schöne ist jetzt, daß der Erfolg (m)einer Bug-Meldung unmittelbar an 
den nächsten erscheinenden Datenblättern ablesbar ist. Wenn sie denn 
überhaupt mal kommen. AVRxDx Datenblätter etwa sind auch schon 
verdächtig lange im Preliminary Status. Ich bleibe dran.

Rudolph R. schrieb:
> Das bringt also nur was wenn man einen niedrigen SPI Takt hat.

Rudolph R. schrieb:
> SPI aber auch auf 12MHz

Für ein paar Sensoren und etwas Inter-Controller Kommunikation langen 
(mir) Frequenzen am unteren Ende der Skala völlig. Bei minimiertem 
Systemtakt soll das Hauptprogramm pollinglos maximal leisten, die 
Verlagerung vom SPI in seinen Interrupt ist daher nur folgerichtig für 
optimales Timing gerade bei interrupt-reichen Systemen, zumal ein 
Interrupt neuerdings priorisiert werden kann. Es strukturiert und 
kapselt Programm- Funktionalität auch viel besser.
Die hohen SPI-Frequenzen klingen mir hier eher nach Datenmengen, bei 
denen dem AVR schon ein ARM vorzuziehen wäre :)

Fpgakuechle K. schrieb:
> Also, wenn oben steht, eine Doku, in der lediglich steht, der
> IRQ-Request würde bei Abarbeitung per Hardware gecleared, falsch ist.,
> dann ist docch eine Fassung v, 21 in der Ergänzt wurde, das , wenn dies
> nicht zutrifft, das bit per lesezugriff auf das dataregister
> zurückgesetzt werden kann, eine berichtigte Version, oder?

Immer wieder erstaunlich wie Du Falschaussagen im letzten aktuellen 
Datenblatt zu relativieren versuchst und

Fpgakuechle K. schrieb:
> 
http://ww1.microchip.com/downloads/en/appnotes/an1982%20interrupt%20system%20in%20tinyavr%200-%20and%201-series%20and%20megaavr%200-series%2040001982a.pdf
> S.6.

einem Dokument von 2017 Priorität über viel aktuellere Datenblätter 
einräumst. Du pickst Dir immer das Richtige heraus und meinst es reicht, 
wenn es hier und dort doch richtig stünde. Doch Du kannst Dich hier 
kunstvoll drehen und wenden wie Du willst, Falschaussage bleibt im 
(letzten) Datenblatt Falschaussage- und die wurde eben bislang (und seit 
Jahren) auch nirgendwo explizit korrigiert.

Ron T. schrieb:
> AVRxDx Datenblätter etwa sind auch schon
> verdächtig lange im Preliminary Status. Ich bleibe dran.

Ich lese da: "AVR128DA final datasheet".
Was die Sache natürlich nicht besser macht.

Wie wir ja schon festgestellt haben, steht unter

14.3.2.1 Enabling, Disabling and Resetting

das man die IFlags zu Fuß zurücksetzen muss.

Wer also nun das DB aufmerksam gelesen hat, stellt also bei SPI fest, 
das da ein anderer Satz steht als bei allen anderen Flag-Registern.
Wer also nur ein klein wenig Gespür für die HW hat, wird sofort wissen, 
dass das nicht stimmen kann. Ggf. macht man zur Sicherheit einen Test. 
Fertig.

Das wird der Grund sein, dass bei MicroChip der case-Counter nicht 
übergelaufen ist (ich habe jetzt auch noch einen case eröffnet mit 
Referenz auf den von Ron T.). Wer also möchte, das MicroChip etwas 
Motivation verspürt, ein Errata dazu herauszubringen, kann das ja auch 
machen. Allerdings bezweifle ich aus den oben schon mal dargelegten 
Gründen, dass das je passieren wird. Und echt jetzt: ich finde das an 
dieser Steller eine lässliche Sünde ;-)

Stefan ⛄ F. schrieb:
> Sebastian schrieb:
>> Gibt es irgendwo zentral Community-Errata?
>
> Warum hat er dafür -2 bekommen? Ich finde den Vorschlag sinnvoll. Bei
> Wikipedia funktioniert das immerhin auch. Es müsste nur jemand
> moderieren, sinnvollerweise der Hersteller. Schließlich will er seine
> Produkte auch verkaufen.
>
> Oder fürchten die Hersteller, dass dabei zu viele Bugs/Probleme
> aufgedeckt werden?

Diejenigen, die sich hier echauffieren, könnten diese Liste erweitern:

https://github.com/SpenceKonde/DxCore/blob/master/megaavr/extras/Errata.md

Wilhelm M. schrieb:
> Ich lese da: "AVR128DA final datasheet".

OK und danke fürs Update, wobei ich hier gerade das aktuelle DB-DB im 
beschriebenen Status offen habe. Die AVR-DB Version steht ja auch im 
Ruf, eine fehlerkorrigierte Version der DA Hardware zu sein :)

Wilhelm M. schrieb:
> Allerdings bezweifle ich aus den oben schon mal dargelegten Gründen,
> dass das je passieren wird.

Das wär doch wirklich lächerlich.

Wilhelm M. schrieb:
> ich habe jetzt auch noch einen case eröffnet mit Referenz auf den von
> Ron T.). Wer also möchte, das MicroChip etwas Motivation verspürt...

Das ist lobenswert und zeugt doch von einem Rest Hoffnung. Danke. 
Grundsätzlich geht es hier und mir ja nicht um Details sondern um mehr 
Engagement bei der DB-Qualität.

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Allerdings bezweifle ich aus den oben schon mal dargelegten Gründen,
>> dass das je passieren wird.
>
> Das wär doch wirklich lächerlich.

Nein, das ist Business!

S. Landolt schrieb:
> Und das steht nicht nur im Datenblatt, sondern ist tatsächlich so, auch
> bei z.B. einem AVR128DB28.

Hatte das jemand bestritten?

Ron T. schrieb:
> S. Landolt schrieb:
>> Und das steht nicht nur im Datenblatt, sondern ist tatsächlich so, auch
>> bei z.B. einem AVR128DB28.
>
> Hatte das jemand bestritten?

Nein.
Ich denke, das sollte ein Positivbeispiel sein, wo das DB eben nicht 
durch copy-n-paste zusammen geklickt worden ist, sondern der Inhalt 
erfolgreich der neuen DA/DB/DD/EA Serie angepasst wurde.

Fpgakuechle K. schrieb:
> Das Problem ist eher das zusammengestückelte Wissen beim Anwender

Na klar. Der Anwender ist schuld an falschen Datenblättern.

> Da verwundert es nicht, das einer vergeblich auf ein Verhalten setzt,
> was er aus anderen Datenblättern oder aus anderen Modi kennt.

Jetz sag mal ehrlich: Hast Du beruflich (un)mittelbar mit Dokumentation 
zu tun und fühlst Dich hier angegriffen und genötigt zur Rechtfertigung?
Was Du offensichtlich nicht kennst ist Entwicklung nach tunlichst 
richtigem Datenblatt. Wonach auch sonst? Nach zusammengestückelten Infos 
von irgendwem aus dem Internet? Ist das Deine Arbeitsweise?

Wilhelm M. schrieb:
> Nein, das ist Business!

Nein, das ist nach Jahren einfach nur peinlich, unprofessionell, 
unzuverlässig, dumm ...

Aber wir werden ja weiter sehen. Die allerneueste Mai 
Datasheet-"Clarification" des AVR-DD

https://onlinedocs.microchip.com/pr/GUID-BDAF999A-F5AD-443E-A2A9-F85BC8240551-en-US-2/index.html

weiß dessen gleich-falsches Datenblatt jedenfalls immer noch nicht zu 
berichtigen. Und da war mal mindestens meine Bug-Meldung seit Wochen 
bekannt.

Reden wir hier eigentlich von einer kleinen Halbleiter-Klitsche nebenan 
oder von einer der größten Chip-Firmen der Welt?

H. H. schrieb:
> Du erzählst von deinen Träumen.

Daß Hinz & Kunz meist nichts Qualifiziertes zum Thema beitragen hast Du 
nun ausreichend nachgewiesen. Insofern alles gut :)

Ron T. schrieb:
> Wilhelm M. schrieb:
>> Nein, das ist Business!
>
> Nein, das ist nach Jahren einfach nur peinlich, unprofessionell,
> unzuverlässig, dumm ...

Peinlich: Du in der Rolle von µChip würdest das als peinlich empfinden.
Unprofessionell: Du stufst das als unprofessionell ein.
Unzuverlässig: Du erwartest zu 100% fehlerfreie Produkte.
Dumm: Du stufst das aus Deiner Sicht als dumm ein.

Aus µChip-Sicht:

Peinlich: von einer großen Zahl von Nutzern meldet einer ein Fehler; 
warum soll uns das peinlich sein. Wir haben zugesagt es zu prüfen.

Unprofessionell: wir müssen mit unseren Ressourcen haushalten, das ist 
professionell, das erwarten die Anteilseigner von uns. Problemchen 
einzelner Nutzer mit den DB stellen wir hinten an.

Unzuverlässig: Haben wir zugesagt, unsere Produkte und ihre DB seien 
fehlerfrei? Nein.

Dumm: Es spart Ressourcen, meldet eine einzelne Person, alle anderen 
wissen Bescheid, die Community kompensiert teilweise, was soll daran 
dumm sein?

Ron T. schrieb:
> H. H. schrieb:
>> Du erzählst von deinen Träumen.
>
> Daß Hinz & Kunz meist nichts Qualifiziertes zum Thema beitragen hast Du
> nun ausreichend nachgewiesen. Insofern alles gut :)

In Deinem 50ten Post schwenkst Du schon auf dieses unqualifizierte 
Verhalten um? Das ist sportlich, Du hast Deine Lektion dieses Forums 
schnell gelernt ;-)

Wilhelm M. schrieb:
> Peinlich: von einer großen Zahl von Nutzern meldet einer ein Fehler;
> warum soll uns das peinlich sein. Wir haben zugesagt es zu prüfen.

Peinlich: Der Fehler besteht mindestens seit 2018 in allen betreffenden 
Datenblättern und wurde in dieser Zeit sicher ettliche Male gemeldet. 
Trotzdem sind wir so ignorant.

Wilhelm M. schrieb:
> Unprofessionell: wir müssen mit unseren Ressourcen haushalten, das ist
> professionell, das erwarten die Anteilseigner von uns. Problemchen
> einzelner Nutzer mit den DB stellen wir hinten an.

Unprofessionell: Als großes Unternehmen haben wir keine Ressourcen 
ordentliche Datenblätter zu erstellen und behelfen uns mit Copy&Paste 
Methoden.

Wilhelm M. schrieb:
> Unzuverlässig: Haben wir zugesagt, unsere Produkte und ihre DB seien
> fehlerfrei? Nein.

Unzuverlässig: Sind unsere Datenblätter selbst nach Jahren und 
zielgerichteten Hinweisen.

Wilhelm M. schrieb:
> Dumm: Es spart Ressourcen, meldet eine einzelne Person, alle anderen
> wissen Bescheid, die Community kompensiert teilweise, was soll daran
> dumm sein?

Dumm: Weil das sicher keine Werbung für unsere Produkte ist.

Wilhelm M. schrieb:
> In Deinem 50ten Post schwenkst Du schon auf dieses unqualifizierte
> Verhalten um?

Ich glaube da verwechselst Du was.

Kurzes Update 8 Wochen nach Meldung: Null Reaktion
Letzter Status im "Case 00965546":
"We have reported the bug to the corresponding internal team and 
expecting a reply from them"

DerEinzigeBernd schrieb im Beitrag #7100953:
> Könnte es sein, daß hier von zwei unterschiedlichen Interrupt-Flags die
> Rede ist?

Nein Bernd. Es geht um die Interrupt-Flags der Peripherals, hier im 
speziellen des SPI-Moduls (INTFLAGS Register/Normal Mode).

Wenn man den Hinweis schon hat sollte es doch ein Leichtes sein, sich 
das Dutzend Datenblätter zusammenzusuchen, die immergleiche Stelle (und 
weitere Bugs) zu korrigieren und sie dann wieder online zu stellen. Eine 
Sache von 20 Minuten. Sollte man meinen. Statt dessen vergehen Jahre in 
denen Entwickler völlig sinnlos herumdebuggen und sich die Infos auch 
noch aus mehreren Quellen zusammensuchen sollen ("Datasheet 
Clarifications"- wie dämlich ist das denn).

Mich erinnert das irgendwie an die pikierte Reaktion, eines Fehlers 
überführt zu werden bzw. an eine elitäre, sich nicht vom Pöbel auf der 
Straße zu einer Reaktion drängen zu lassen.

Das Unglaubliche ist nach Jahren der Desinformation geschehen.
Wenn auch nur bei einem allerersten Vertreter der Series0/1/AVRxDx.
Wenn auch erstmal zaghaft nur in der Online-Doku.
Ein Fehler im Datenblatt wurde korrigiert (siehe erster Beitrag).

https://onlinedocs.microchip.com/pr/GUID-7A426C50-A481-452C-9888-A56EDDDD2EC5-en-US-4/index.html

Wer verwendet denn SPI mit interrupt ? Das macht ja gar keinen Sinn. Bis 
die interupt Routine alle Register gepusht und gepopt hat, hat man die 
Bit auch so rausgehaemmert. Naja, so etwa. Oft halten sid die Chip 
hersteller auch nicht an die spezifikationen, heisst kein SPI passt.

Purzel H. schrieb:
> Bis die interupt Routine alle Register gepusht und gepopt hat

In C vielleicht.
In Assembler sicherst Du nur was wirklich gebraucht wird.

> Wer verwendet denn SPI mit interrupt ? Das macht ja gar keinen Sinn

Bei wenigen Bytes geb ich Dir Recht.
Wird's mehr gibts Ruckler im Hauptprogramm. Die verträgt nicht jedes.
Interrupts strukturieren ein Programm, tarieren Belastungen aus, 
priorisieren Aufgaben.

Ron T. schrieb:
> Purzel H. schrieb:
>> Bis die interupt Routine alle Register gepusht und gepopt hat
>
> In C vielleicht.
> In Assembler sicherst Du nur was wirklich gebraucht wird.
>
>> Wer verwendet denn SPI mit interrupt ? Das macht ja gar keinen Sinn
>
> Bei wenigen Bytes geb ich Dir Recht.
> Wird's mehr gibts Ruckler im Hauptprogramm. Die verträgt nicht jedes.
> Interrupts strukturieren ein Programm, tarieren Belastungen aus,
> priorisieren Aufgaben.

Und die Verwendung von Interrupts zusammen mit der notwendigen 
volatile-Qualifizierung (C/C++) verhindert oft eine geeignete 
Optimierung durch den Compiler. Manchmal ist das Polling der Statusflags 
ohne ISR mit weniger Gesamtaufwand verbunden.

Purzel H. schrieb:
> Wer verwendet denn SPI mit interrupt ? Das macht ja gar keinen Sinn.

Bei 8 MHz SPI and 16 MHz Core Takt macht das keinen Sinn, bei z.B. 250 
kHz SPI und 16 MHz Core Takt sieht das schon anders aus.
Aber auch dann kommt es auf die Anwendung an was besser passt.

Rudolph R. schrieb:
> Bei 8 MHz SPI and 16 MHz Core Takt macht das keinen Sinn

Was mich zu der Frage führt bei welcher gewöhnlichen AVR Anwendung 
dieses SPI Tempo überhaupt Sinn macht?

Ron T. schrieb:
> Rudolph R. schrieb:
>> Bei 8 MHz SPI and 16 MHz Core Takt macht das keinen Sinn
>
> Was mich zu der Frage führt bei welcher gewöhnlichen AVR Anwendung
> dieses SPI Tempo überhaupt Sinn macht?

Jede Anwendung bei der man nicht nur ein paar Bytes über den SPI schickt 
und auch noch Zeit für was anderes haben möchte.

3D Drucker haben zum Beispiel ein Grafik-Display mit 128x64 Pixeln und 
die meisten dürften immer noch mit AVR Controllern laufen, so von der 
Menge her, die ersten CR-10 und Ender-3 zum Beispiel.
Da ist das Display eher ein notwendiges Übel und je weniger Zeit dafür 
drauf geht, desto besser.

Ich habe EVE Displays mit 8MHz SPI benutzt, damit dauert ein 
Display-Update immer noch so 1ms oder länger. In der restlichen Zeit 
zwischen den Updates kann der Controller dann seine eigentliche Aufgabe 
machen.

Aktuell benutze ich keine AVRs und kann SPI über DMA machen, das macht 
viel mehr Sinn als Interrupts und man kann auch noch den Takt 
reduzieren.

Reden wir nochmal über den Interrupt-ungünstigsten Maximalfall am 
Beispiel eines modernen AVRxDx.

Rudolph R. schrieb:
> Bei 8 MHz SPI and 16 MHz Core Takt macht das

wenn ich das richtig sehe gut 1000 ns für ein SPI-Byte / 62 ns für einen 
Clock = 16 Clocks/SPI-Byte.

Rudolph R. schrieb:
> Ich habe EVE Displays mit 8MHz SPI benutzt, damit dauert ein
> Display-Update immer noch so 1ms oder länger. In der restlichen Zeit
> zwischen den Updates kann der Controller dann seine eigentliche Aufgabe
> machen.

Erwähnte 16 Clocks für ein SPI-Byte langen dann um

a- Interruptflag abzufragen
b- Interruptflag durch Lesen von SPI INTFLAGS+DATA rückzusetzen
c- das nächste Byte zu laden
d- das nächste Byte auszugeben
e- in der Schleife zurückzuspringen ?

Eher nicht. Maximale 8MHz SPI Speed- Ausgabe vieler Daten sind hier also 
auch ohne Interrupt kaum erreichbar. Die Interrupt-Lösung (spart a ein) 
kommt durch 6 Clocks Interrupt-Eintritt, 6 Clocks Interrupt-Return, 2 
Clocks SREG Sicherung und beispielsweise 4 Clocks MOVW Sicherung von 
zwei Register-Pärchen = 18 Clocks bürokratischen Mindestaufwands + b/c/d 
definitiv auf ein paar Clocks mehr. Das hat aber den Vorteil daß die 
Ausgabe vom Hauptprogramm entkoppelt ist und dieses wenigstens mit einer 
Instruktion zwischen jedem Interrupt weiterläuft (bei 1000 Ausgabe-Bytes 
also immerhin 1000 weiteren Instruktionen). Das etwas hinausgezogene 
Display-Update sollte doch hier eigentlich zu verschmerzen sein.

> Aktuell benutze ich keine AVRs und kann SPI über DMA machen

verweist schon drauf wie es wirklich sinnvoll ist und warum ein AVR für 
Grafik-Ausgaben sowieso nicht die Idealbesetzung ist. Das dürfte auch 
für

S. Landolt schrieb:
> ich
> kopiere bei 12 MHz mit einem leicht übertakteten ATmega1284 zwischen
> zwei SDCards.

gelten.