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


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ron T. (rontem)


Lesenswert?

"The (SPI) IF is cleared by hardware when executing the corresponding 
interrupt vector"

Falsch seit Jahren.
In allen AVR Series 0/1/2 Controller Dokus.
Microchip macht selbst nach offizieller Bestätigung dieses Fehlers keine 
Anstalten, seine Datenblätter endlich entsprechend zu korrigieren.

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Ron T. schrieb:

> "The (SPI) IF is cleared by hardware when executing the corresponding
> interrupt vector"
>
> Falsch seit Jahren.
> In allen AVR Series 0/1/2 Controller Dokus.
> Microchip macht selbst nach offizieller Bestätigung dieses Fehlers keine
> Anstalten, seine Datenblätter endlich entsprechend zu korrigieren.

Jepp und das betrifft nicht nur die genannten Baureihen, sondern auch 
AVR128Dx und es betrifft nicht nur SPI, sondern auch diverse andere 
Interrupts.

Ja die Zeiten, als man sich auf AVR8-Datenblätter wenigstens meistens 
verlassen konnte, sind seit der Machtübernahme durch MC definitiv 
vorbei. Neue Devices werden gleich fehlerhaft und stark unvollständig 
dokumentiert. Und die alten Datenblätter werden nur optisch 
aufgehübscht, dafür aber mit vielen neuen Doku-Fehlern angereichert.

Das muß Absicht sein. Allein durch dramatische Inkompetenz ist das wohl 
nicht zu erklären.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ich habe mir deswegen alle Atmel Datenblätter archiviert, die für mich 
relevant sind.

Beitrag #7063882 wurde von einem Moderator gelöscht.
von c-hater (Gast)


Lesenswert?

Haftungsbeschränkter schrieb im Beitrag #7063882:

> Da kann man nur hoffen, daß möglichst viel der
> "Was-sagt-denn-das-Datenblatt?"
> Nölärsche in diese Schlaglöcher fallen und tagelang mit der Suche nach
> scheinbar nicht vorhandenen Fehlern zu tun haben.

Das passiert nicht. Die sog. "Nölärsche" haben die Kompetenz, sowas 
innerhalb kürzester Zeit zu detektieren...

Wie glaubst du, könnte man sonst ernsthaft zu der Aussage kommen, dass 
im DB Mist steht?

Wobei diese Sache eher simpel ist, das kann man wirklich schnell und 
einfach detektieren, dazu braucht man noch nichtmal irgendwas in der 
Nähe von Profi zu sein.
Es gibt aber leider DB-Fehler, die noch viel fieser sind und auch die 
Profis vor echte deduktive Herausforderungen stellen...

Die einzige Partei, die das alles absolut nicht zu interessieren 
scheint, ist MC... Das ist insofern blöd, als dass die die Macht über 
die Datenblätter haben...

von Ron T. (rontem)


Lesenswert?

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

von Jim M. (turboj)


Lesenswert?

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.

von KArl Fred M. (karl_fred)


Lesenswert?

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

von Joachim B. (jar)


Lesenswert?

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)

Beitrag #7063962 wurde von einem Moderator gelöscht.
von Sebastian (Gast)


Lesenswert?

Gibt es irgendwo zentral Community-Errata?

LG, Sebastian

von Jobst M. (jobstens-de)


Lesenswert?

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

von A. S. (achs)


Lesenswert?

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.

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

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?

von Stefan ⛄ F. (stefanus)


Lesenswert?

Ron T. schrieb:
> 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.

Der Stil des Eröffnungsbeitrages gefällt mir gar nicht. Spontan wollte 
ich ihn dafür gestern kritisieren, aber in der Sache hat er doch Recht. 
Was Microchip da abliefert lässt sich nach so vielen Jahren nicht mehr 
entschuldigen. Es ist eine Unverschämtheit.

von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

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.

> Microchip macht selbst nach offizieller Bestätigung dieses Fehlers keine
> Anstalten, seine Datenblätter endlich entsprechend zu korrigieren.

Vielleicht weil die Erratas also die Fehlerbestätigung auch zur 
Dokumentation gehören?! Ein Datenblatt gibt halt auch die Spezifikation 
wieder, das reale Verhalten ist dann eben andere Stelle im Konvolut 
festgehalten (user guide), oder steckt quasi in den mitgelieferten 
Treibern etc..

von Rolf M. (rmagnus)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

Fpgakuechle K. schrieb:

> Weil rummeckern ohne exakte Beschreibung des konkreten Fehlerbildes eben
> negativ bewertet wird.

Was fehlt dann deiner Meinung nach an der Exaktheit der 
Fehlerbeschreibung? Im Datenblatt steht, dass das Durchlaufen des 
Interruptvektors den Interrupt zurück setzen würde. Genau das passiert 
aber nachweislich nicht. Was soll man da noch weiter rumschwafeln?

Man könnte darüber streiten, ob es nun ein Bug der Hardware oder ein 
Fehler in der Dokumentation ist. Das kann nur MC wissen. Aber wie auch 
immer: Wenn's ein Hardwarebug ist, hat's als Erratum aufzutauchen, 
wenn's ein Fehler der Dokumentation ist, hat's korrigiert zu werden und 
die Korrektur in der Versionshistorie des Dokuments verzeichnet zu 
werden.

Ende der Geschichte.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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?

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

c-hater schrieb:
> Fpgakuechle K. schrieb:
>
>> Weil rummeckern ohne exakte Beschreibung des konkreten Fehlerbildes eben
>> negativ bewertet wird.
>
> Was fehlt dann deiner Meinung nach an der Exaktheit der
> Fehlerbeschreibung? Im Datenblatt steht, dass das Durchlaufen des
> Interruptvektors den Interrupt zurück setzen würde. Genau das passiert
> aber nachweislich nicht.

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.

> Genau das passiert
> aber nachweislich nicht.
Bitte Nachweis nachvollziehbar beschreiben.


> Was soll man da noch weiter rumschwafeln?

Eine Fehlerbeschreibung, die eine Eingrenzung und Reproduzierbarkeit des 
Fehlers gestattet ist kein Geschwafel. Nicht selten stellt sich dabei 
heraus, das kein Produkt- sondern ein Verständnisfehler ist.

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"

: Bearbeitet durch User
Beitrag #7064356 wurde von einem Moderator gelöscht.
Beitrag #7064359 wurde von einem Moderator gelöscht.
von Oliver S. (oliverso)


Lesenswert?

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

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

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. Eine Addresse kann nicht ausgeführt 
werden, sondern nur der Code auf dieser Adresse. Also was ist das für 
ein Code, der da ausgeführt wird?!

Und sind mglw. weitere Voraussetzungen zu erfüllen, das der ISR als 
solcher ausgeführt wird ?! gelegentlich muss bei multi-purpose Pins, die 
entsprechende Funktion wie bspw. SPI in einem Register freigeschaltet 
werden (TWISPIROUTEA, CTRLA). Sonst funktioniert SPI-mäßig garnichts.

http://ww1.microchip.com/downloads/en/AppNotes/TB3215-Getting-Started-with-SPI-90003215A.pdf

Hilfreich wäre es, den Test dafür zu gehen.
Eine Hinweis beim Schreiben von Requiremts/Spec ist  "Überleg dir 
gleichzeitig, wie du dieses Feature prüfen willst" Also muss es auch 
Prüfcode geben wit dem dieses feature gestestet wird. Der kann natürlich 
fehlerhaft hast, ist auch schon intel passiert (FDIV-Bug).

Und natürlich kann man das problem auch als gelöst betrachten, wenn ein 
workaround veröffentlicht wurde: "3. Clearing the Interrupt flag, if it 
is not cleared automatically by the hardware." auch wenn dies nicht 
explicit als workaround deklariert wurde.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Unter "executing the corresponding interrupt vector" verstehe ich den 
Moment, wo die CPU den Interrupt Vektor anspringt.

Das dies bei AVR diverse Flags außerhalb der CPU (und IRQ Controller) 
zurück setzt ist nicht neu. Bei STM32 wäre es hingegen überraschend.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Unter "executing the corresponding interrupt vector" verstehe ich den
> Moment, wo die CPU den Interrupt Vektor anspringt.

Und ein IC-Designer versteht das eben als 'True' am Ausgang eines 
Comparatores mit den Eingängen Instruction-decoderegister und Konstante 
"start SPI-ISR "(IRQ- vector table). und dann noch ein AND über das 
Enable vom SPI-Module.
Wenn teile diese Logik noch in anderen Takt-domainen liegen, wird es 
knifflig (einsynchronisieren). Und was ist mit der Fordeung nach 
code-relocation ? (Speichermanagment).

Mancher IC-Designer ist dann geneigt, dieses Requirement streichen zu 
lassen, weil man sich auf diese Weise Problem einhandelt als gelöst 
werden (Vermeidung des expliziten Löschens durch einen Bit-befehl im 
IRQ-Handler). Oder als Nebeneffekt beim Lesen des Datenregister.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Fpgakuechle K. schrieb:
> Wenn teile diese Logik noch in anderen Takt-domainen liegen, wird es
> knifflig (einsynchronisieren). Und was ist mit der Forderung nach
> code-relocation ?

Beides gibt es bei den klassischen AVR nicht.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Rolf M. schrieb:

> Nein. Beim AVR ist ein Interrupt-Vektor eine Instruktion, die ausgeführt
> wird, wenn der Interrupt ausgelöst wird.

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

http://ww1.microchip.com/downloads/en/AppNotes/TB3215-Getting-Started-with-SPI-90003215A.pdf

von Stefan ⛄ F. (stefanus)


Lesenswert?

Fpgakuechle K. schrieb:
> 
http://ww1.microchip.com/downloads/en/AppNotes/TB3215-Getting-Started-with-SPI-90003215A.pdf

Das ist kein Datenblatt. Es geht hier ums Datenblatt. Und zwar das 
Datenblatt eines AVR Serie 0/1/2. Anscheinend kennst du sie nicht, also 
auch nicht die hier relevanten Unterschiede zu klassischen AVR von deren 
Datenblätter offenbar abgeschrieben wurde.

: Bearbeitet durch User
von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Fpgakuechle K. schrieb:
>> Wenn teile diese Logik noch in anderen Takt-domainen liegen, wird es
>> knifflig (einsynchronisieren). Und was ist mit der Forderung nach
>> code-relocation ?
>
> Beides gibt es bei den klassischen AVR nicht.

Zählst du die hier vom TO refenrenzierten tinyAVR® 0-series zu den 
klassischen AVR?

von Stefan ⛄ F. (stefanus)


Lesenswert?

Fpgakuechle K. schrieb:
> Zählst du die hier vom TO refenrenzierten tinyAVR® 0-series zu den
> klassischen AVR?

Nein. Und eben da könnte der Knackpunkt liegen. Die haben von alten 
Modellen abgeschrieben, die anders ausgebaut sind.

von Oliver S. (oliverso)


Lesenswert?

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

Oliver

von Rolf M. (rmagnus)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Oliver S. schrieb:
> Ja und? Der Begriff "vector" gehört zum interrupt handling, nicht zu
> SPI.

Bei klassischen AVR sind die Funktionseinheiten nicht so stark 
voneinander getrennt. Im Gegensatz zu moderneren Mikrocontrollern wurden 
sie nicht aus unabhängigen "Legosteinen" zusammen gesetzt, sondern da 
gibt es wirklich eine Menge Quer-Verbindungen.

Unter anderem Deswegen braucht man dort für die gleiche Aufgabe oft 
wesentlich weniger Befehle, als bei moderneren Mikrocontrollern.

Die vom TO monierten, gehören zu den "moderneren". Der falsche Text 
entstammt aber offenbar älteren Datenblättern.

: Bearbeitet durch User
von Fpgakuechle K. (fpgakuechle) Benutzerseite


Angehängte Dateien:

Lesenswert?

Stefan ⛄ F. schrieb:
> Fpgakuechle K. schrieb:
>> Zählst du die hier vom TO refenrenzierten tinyAVR® 0-series zu den
>> klassischen AVR?
>
> Nein.

Anbei auszug aus der series-0 doku, da kann man IMHO schon mehr als nur 
eine clock domain erkennen.

> Und eben da könnte der Knackpunkt liegen. Die haben von alten
> Modellen abgeschrieben, die anders ausgebaut sind.

Also passt das µC-Modell bei dem ein abweichendes Verhalten festgestellt 
wurde, nicht zu dem µC-Modell auf das sich das angemeckerte Datenblatt 
bezieht?!

Da würde ich nicht von 'penetranten Lügen' aka "Dauerhaft FakeNews" 
schreiben, zumal es ja in der detaillierten SPI-Beschreibung 
realistsicher/fehlertoleranter beschrieben ist. Errare humanum est - 
auch in Datenblättern.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Fpgakuechle K. schrieb:
> Also passt das µC-Modell bei dem ein abweichendes Verhalten festgestellt
> wurde, nicht zu dem µC-Modell auf das sich das angemeckerte Datenblatt
> bezieht?!

Du hast ein Bild von "modernen" (nicht klassischen AVR) gezeigt. Die 
Kritik vom TO bezieht sich auf ein Datenblatt eines "modernen" AVR.

Der falsche Text würde hingegen zu einem klassischen AVR passen.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Fpgakuechle K. schrieb:
> Errare humanum est - auch in Datenblättern.

Ja gerne. Doch gemeldet Fehler sollten korrigiert werden. Hier wurde 
schon öfter gemeldet, dass diverse Fehler trotz Meldung nicht korrigiert 
wurden.

Seit der Übernahme durch Microchip hat ist die Qualität der AVR 
Datenblätter auffällig gesunken. Da hat der TO schon absolut Recht.

: Bearbeitet durch User
von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Fpgakuechle K. schrieb:
>> Errare humanum est - auch in Datenblättern.
>
> Ja gerne. Doch gemeldet Fehler sollten korrigiert werden. Hier wurde
> schon öfter gemeldet, dass diverse Fehler trotz Meldung nicht korrigiert
> wurden.

Diese Absicht ist sicher gerechtfertigt.

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. Und 
konkrete Vorschläge machen, wie man das 'näher am Optimum' tippen 
könnte. Da bleibt dem Autor der angemeckerten zeilen genug Platz zur 
"Geichtswahrung". Ja, der Umgang mit Menschen ist oft nicht einfach ;-)
https://www.youtube.com/watch?v=TYiqgU_GrAE

> Seit der Übernahme durch Microchip hat ist die Qualität der AVR
> Datenblätter auffällig gesunken. Da hat der TO schon absolut Recht.

der TO bezieht sich hier auf einen µC, der 2018 vorgestellt wurde, da 
könnte man noch von (bekannten) Kinderkrankheiten sprechen.

von Dieter (Gast)


Lesenswert?

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.

Stefan ⛄ F. schrieb:
> Seit der Übernahme durch Microchip hat ist die Qualität der AVR
> Datenblätter auffällig gesunken. Da hat der TO schon absolut Recht.

Alles vorarbeiten zur Beerdigung der AVR-Chips würde ich mal vermuten 
oder so dumm kann doch keine raubtierkapitaliste Firmenführung sein, 
oder vielleicht doch...

von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Es wäre besser gewesen, den Series 0/1/2 Typen einen ganz anderen Namen 
zu geben.
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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

Je nun, Namen - waren sie nicht mal Schall & Rauch? Heutzutrage ist 
jeder ein 'Troll', dessen Nase nicht gefällt, oder ein eklatanter Fehler 
im Datenblatt wird unter "Fake News" subsummiert.

von Wühlhase (Gast)


Lesenswert?

Je angelsächsisch-infantiler, desto weniger sind die Leute anscheinend 
in der Lage, Wörtern differenzierten Sinn zuzuordnen.

Was haben Fehler im Datenblatt mit bewußt lancierten Falschnachrichten 
zu tun?

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Angehängte Dateien:

Lesenswert?

Stefan ⛄ F. schrieb:
> Fpgakuechle K. schrieb:
>>
> 
http://ww1.microchip.com/downloads/en/AppNotes/TB3215-Getting-Started-with-SPI-90003215A.pdf
>
> Das ist kein Datenblatt. Es geht hier ums Datenblatt.

Eigentlich geht es um eine Beschreibung wie man es richtig macht, hier 
mit dem SPI auf diesem µC. Ob das Datenblatt oder TB heisst -wurscht- es 
ist Teil der offizielle Dokumentation.

Wie ich bereits schrieb, data sheet hat auch viel von product 
specifiaction, also steht da drin, was der fertige Chip tun soll. bei 
Xilinx steht da bei den timings oft "Preliminary Data" also vorläufige 
daten. als Begründung wurde angegeben, das man 'production data' erst 
dann angeben kann, wenn man genügend Statistik über die Serie hat.


Manchmal wird der Chip eben nie fertig, man fixed dann auch keine 
'Fehler' weil man abwärtskompatible sein will.

PS: auch den series-0 datasheet steht Datasheet Preliminary (siehe 
Anhang)
PSS: Die doku wurde neu strukturiert, deshalb scheint es von dem 2019 
series-0 datenblatt keine Updates zu geben. Es gibt sie aber (ist aber 
auch nicht der weisheit letzter schluss).

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Jens B. (dasjens)


Lesenswert?

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

Nö, schreib doch einfach eigene. ;P

von Percy N. (vox_bovi)


Lesenswert?

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

Schade, das nimmt dem Thread die Rekursion.

von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Ron T. schrieb:
> Fpgakuechle K. schrieb:
>> Eigentlich geht es um eine Beschreibung wie man es richtig macht,
>
> Eigentlich geht es hier um korrekte Datenblätter!

Ich weiss ja nicht, ob du Englisch-Lehrer/Paragraphenreiter oder 
Elektroniker bist. Einem Elektroniker/Ingenieur geht es um konstruktiven 
Umgang mit der Technik. Falls sich also ein Ding nicht wie beschrieben 
verhält, dann analysiert man das und findet einen work around und macht 
so das Ganze (für die community) nutzbar. Und Sprache ist ohnehin selten 
fehlerfrei, schon aus Prinzip nicht:

https://de.wikipedia.org/wiki/G%C3%B6delscher_Unvollst%C3%A4ndigkeitssatz
https://de.wikipedia.org/wiki/Tractatus_logico-philosophicus#Sagen_und_Zeigen,_Grenzen_der_Sprache

>> Manchmal wird der Chip eben nie fertig
>
> Bei Datenblättern besteht diese Möglichkeit aber. Zumal nach Jahren.

Naja viel Erfahrung haste mit solchen Dingen nicht, man spricht nicht 
umsonst von Kinderkrankheit, manche Produkte/Datenblätter sind erst mit 
18 halbwegs reif. Selbst ein Donald Knuth muss noch Belohnungs-schecks 
für gefundene Fehler ausstellen: 
https://en.wikipedia.org/wiki/Knuth_reward_check

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

Es wäre schön, wenn Du mal links angeben würdest, das erspart einem die 
Suche.

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Ron T. schrieb :


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

Naja, der ganze Umgang mit Elektronik kostet Lebenszeit nicht zu knapp, 
Debugging, In-Betriebnahme, Evaluierung, ... egal wie man es nennt. 
Sollte man aber dem Mephisto aus Faust zustimmen ?!?

"... denn alles was entsteht ist werth daß es zu Grunde geht; Drum 
besser wär's daß nichts entstünde ..."

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

Ja. Kannst dir ja auch ein anderes Lebensziel suchen ...

> Du kommst aus
> dem Relativierungs-Trip harter Datenblatt-Fehler einfach nicht raus...

Eben konstruktiver Umgang um Technik, dein Berufswunsch im Kindergarten 
war wohl eher "Bestrafer". SCNR


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

Naja, woher soll man wissen welches datenblatt du grad meinst wenn du 
weder Typ noch Jahreszahl angibst. Aber darauf scheinst du es ja 
anzulegen, Leute in die Irre zu schicken und deren zeit zu stehlen.

: Bearbeitet durch User
von Percy N. (vox_bovi)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Ron T. schrieb:
> Fpgakuechle K. schrieb:
>> wenn du weder Typ
>
> Mit 4808 ist ein AtMega4808 gemeint. Falls Du daran gescheitert sein
> solltest...

Link!

>> 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!

Leck mich!

> Ich lege es sicher nicht drauf an daß Du hier Deine Zeit zur
> Relativierung vermeidbarer Fehler verschwendest.
Wo du es sagt - Over and out und PLONK nicht vergessen.

von Ron T. (rontem)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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

Keineswegs. Der TO und wir alle wissen, wie man es richtig macht.

Es geht darum, dass das Datenblatt eine falsche Information enthält. Das 
kann man ganz klar im Eröffnungsbeitrag lesen.

Wenn dir nicht klar, wie man es richtig macht - dein Problem. Das 
kannst du gerne in einem separaten Thread klären.

von Stefan ⛄ F. (stefanus)


Angehängte Dateien:

Lesenswert?

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

Fpgakuechle K. schrieb:
> Es wäre schön, wenn Du mal links angeben würdest, das erspart einem die
> Suche.

Oh Mann, das bringt Google gleich als erstes Suchergebnis!
https://ww1.microchip.com/downloads/en/DeviceDoc/ATmega4808-09-DataSheet-DS40002173C.pdf

Beitrag #7064681 wurde von einem Moderator gelöscht.
von Jobst M. (jobstens-de)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Jobst M. (jobstens-de)


Lesenswert?

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

: Bearbeitet durch User
von Lust L. (lust)


Lesenswert?

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?

von Rudolph R. (rudolph)


Lesenswert?

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.

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

Bei ARM gibt es eine Tabelle mit Sprungadressen. Die Position der 
Tabelle ist variabel.

Bei AVR gibt es diese Indirektion nicht. Da wird beim Interrupt direkt 
an eine feste Adresse gesprungen. Da diese Adressen dicht hintereinder 
liegen ist dort nur Platz für jeweils einen einzigen Befehl (IRET oder 
RJMP). In der Praxis läuft es darauf hinaus, dass der Block mit den 
Interrupt Vektoren meist Reihe von RJMP Befehlen zu den eigentlichen 
Interruptroutinen enthält. Deswegen wird das oft mit einer 
Vektor-Tabelle verglichen, ist es aber genau genommen nicht.

Für die AVR CPU besteht das Ausführen einer Interrupt-Anforderung darin, 
direkt zu einem fest vorgegebenen Interrupt Vektor zu springen.

Eine ARM CPU würde hingegen zuerst die Zieladresse aus einer Tabelle 
lesen, und dann dorthin springen.

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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 :)

von Wollvieh W. (wollvieh)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

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.)

von Ron T. (rontem)


Lesenswert?

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"

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Ron T. (rontem)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

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 ...

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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...

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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?

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

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 ...

von Euro (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Jetzt einfach mal selbst die Frage stellen, wie viele Zeilen Code ihr
> fehlerfrei ohne Compiler und ohne Tests hinschreiben könnt.
Aus Sicht des TR, der sicherlich oft genug gefragt hat, was sich 
zwischen den Modulversionen geändert hat, kein Fehler.
Der HW-Entwickler des neuen Chips hat's nicht gesagt, also ist die 
Änderung nicht existent - wenn doch, dann ist es ein Designfehler der 
Chips, der zweifellos in der nächsten HW-Revision zu beheben ist.
(Ironie aus)

Als jemand, der auch mal technische Redaktion in Teilzeit gemacht hat: 
Solche Änderungen, die mehrfach im Dokument nachzuvollziehen sind, sind 
die Pest. Selten findet man alle betreffenden Passagen im Fließtext.
Will nicht heißen, dass bei fleißiger Rückmeldung der Anwender solche 
Bugs nicht behebbar sind, allerdings ist ein TR selten mit nur einem DB 
beschäftigt. Bei mir waren es mit halber Stelle etwa 5000 Druckseiten, 
deren Anspruch auf Konsistenz bei fortlaufender Entwicklung in einigen 
Passagen schon etwas Schmerzresistenz beim Kunden voraussetzten.

Also tröstet Euch, der TR sitzt gerade am DB für den Chip, der nächstes 
Jahr rauskommt.

von Rudolph R. (rudolph)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Rudolph R. (rudolph)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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 ...

von Stefan ⛄ F. (stefanus)


Lesenswert?

Wilhelm M. schrieb:
> Oh man, hast Du jetzt ein Problem damit, dass Du der letzte bist, der
> diesen Fehler im DB erkannt hat?

Textverständnis: 6 (durchgefallen)

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von H. H. (hhinz)


Lesenswert?

Ron T. schrieb:
> Hier krankt es bei Microchip an allen Fronten-  trotz viel
> Werbe-Blendwerk mit allerhand Qualitäts-Zertifizierungen.

Du kannst das ändern!

https://careers.microchip.com/jobsearch

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

H. H. schrieb:
> Ron T. schrieb:
>> Hier krankt es bei Microchip an allen Fronten-  trotz viel
>> Werbe-Blendwerk mit allerhand Qualitäts-Zertifizierungen.
>
> Du kannst das ändern!
>
> https://careers.microchip.com/jobsearch

Ja, dieser job: 
https://careers.microchip.com/job/7328/engineer_verification

passt auf das TO-Gezeter

-Debug failures, fix testbench/model/checker issues, and manage bug 
tracking
-Must possess excellent verbal and written skills including ability to 
write clear and concise technical documentation in English.

Dazu ist das Ganze in Deutschland. Allerdings sehe ich Defizite im 
Mannschaftsgeist und Fehlens einener konstruktiven Geisteshaltung - da 
TO ist da eher von der Iddee getrieben sich durch "Du hast einen fehler 
gemacht" in den Vordergrund zu spielen und an einer schnellen 
Problemlösung höchstens am Rand interessiert. Ob es auch an der richtung 
Ausbildung mangelt (BSEE is required, MSEE/PhD preferred) kann man nicht 
sagen.

von Ron T. (rontem)


Lesenswert?

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

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Ron T. schrieb:
> 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?

Eben.

von Stefan ⛄ F. (stefanus)


Lesenswert?

Wer keine anständige Doku braucht, kann sich ja mit chinesischen 
Produkten eindecken.

von Purzel H. (hacky)


Lesenswert?

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

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Ron T. schrieb:
> Nachdem ich nun dort selbst aktiv und der
> Fehler bestätigt wurde (mein Support-Ticket ließ man mir offen)

Also die angebliche 'Bestätigung' deiner ominösen Fehlerbestätigung 
besteht darin das das Support-ticket offen blieb?

> bin ich
> schon auf die nächsten neuen Datenblatt-Versionen betreffender
> Controller gespannt!

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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).

von Wilhelm M. (wimalopaan)


Lesenswert?

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 ...

von Euro (Gast)


Lesenswert?

Ron T. schrieb:
> 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.
Meine praktische Erfahrung dazu:
Je besser Dein Ergebnis als TR, desto flüchtiger schlussendlich die 
Tester. Auch der personalisierte Testsatz "Hallo ..., bist Du noch 
wach?" mitten im Fließtext wurde in der Regel nur zu 50% in der 
Korrekturfahne gefunden und markiert.
D.h.: Das von Dir genannte Prozedere ist Usus, aber kein Erfolgsgarant.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

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.

Und manchmal besteht eine Update eben darin, das der bemoserte Satz 
stehen bleibt, aber im nachfolgenden Abschnitt oder im sonstigen Kontext 
"gerade gerückt wird" indem mehr Details genannt werden statt den Kunden 
raten lassen was (mit "by Hardware") gemeint sein könnte. Hier ".. the 
IF can be cleared by first reading the SPIn.INTFLAGS register when IF is 
set and then accessing the SPIn.DATA register"

--
> 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).

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.

Und erst nach Reproduktion des Fehlers beim Hersteller kann man von 
einer Bestätigung reden.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

: Bearbeitet durch User
von Euro (Gast)


Lesenswert?

Ron T. schrieb:
> Jedem wirklich HW-Kundigen dürfte der genannte Doku-Fehler sofort
> auffallen.
Wenn er es denn tatsächlich konzentriert und zeitnah liest und nicht 
derweil schon in ganz andere Arbeit verstrickt ist, das Telefon nicht 
klingelt, der Anzug nicht in der Reinigung ist und auch kein Erdbeben 
kommt...
(Ja, ist ärgerlich - und nein, ist kein Weltuntergang)

von Stefan ⛄ F. (stefanus)


Lesenswert?

Wilhelm M. schrieb:
> Was ich meinte, ist, dass dies in der gesamten, aktuellen Doku nicht
> drin steht, auch nicht in den Errata.

Vergiss es, auf dem Ohr ist Fpgakuechle taub.

von Rudolph (Gast)


Lesenswert?

Ron T. schrieb:
> 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.

Das ist allgemein richtig, Polling blockiert.
Bei 16MHz Core-Takt, 8MHz SPI-Takt und der Aufgabe 3 Bytes an einen 
DA-Wandler zu schicken ist die Lösung mit dem Interrupt allerdings eine 
Null-Nummer.

von c-hater (Gast)


Lesenswert?

Wilhelm M. schrieb:

Das stimmt unbezweifelbar.

Aber er pusht bei vielen Projekten immer noch weit mehr, als tatsächlich 
nötig wäre.

Das liegt an zwei Sachen:

1) Compiler haben einen sehr eingeschränkten Blickwinkel. Sie haben 
keine Ahnung vom Gesamtwerk. Und sind somit quasi dazu verurteilt, 
falsch zu optimieren, wenn es mehr als einen Codebaum gibt.

2) Compiler haben keine (zumindest keine einfach benutzbaren und 
portablen) Möglichkeiten, ihnen Tips zu geben, wie sie es richtig im 
Sinne der Gesamtlösung angehen sollten.

von c-hater (Gast)


Lesenswert?

Rudolph schrieb:

> Bei 16MHz Core-Takt, 8MHz SPI-Takt und der Aufgabe 3 Bytes an einen
> DA-Wandler zu schicken ist die Lösung mit dem Interrupt allerdings eine
> Null-Nummer.

Richtig. Bei 24MHz Takt und im Slavebetrieb sieht das aber schon ganz 
anders aus. Und bei den neueren AVR8 ist Slavebetrieb tatsächlich eine 
realistische Anwendung.

von Joachim B. (jar)


Lesenswert?

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!

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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

Und bei 32MHz noch anders ;-)

von c-hater (Gast)


Lesenswert?

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.

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.

Es bleibt trotzdem das Risiko jedes Entwicklers, solch eine Entscheidung 
zu treffen. Sollte man sich in jedem Fall durch Cheffe absegnen lassen. 
Wenn man klug ist...

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

: Bearbeitet durch User
von Rudolph R. (rudolph)


Lesenswert?

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.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

Stefan ⛄ F. schrieb:
> Wilhelm M. schrieb:
>> Was ich meinte, ist, dass dies in der gesamten, aktuellen Doku nicht
>> drin steht, auch nicht in den Errata.
>
> Vergiss es, auf dem Ohr ist Fpgakuechle taub.

Naja was nicht genannt wird, kann auch nicht verstanden werden ...

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?

Zumal das konsistent zu der Beschreibung der Änderungen/Erweiterungen im 
Interruptsystem der Serie-0 ist, in der erklärt wird, was bei einem 
gesharten IRQ-Vector ersatzweise für eine HW Zurücksetzung möglich ist.

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

Bedauerlich un-aktuell ist dagegen diesbezüglich das Forums-eigene Wiki, 
in dem diese und weitere Änderungen (automatische Setzen des IE-bit im 
SREG) innerhalb der AVR genannten Familie nicht vermerkt sind.

https://www.mikrocontroller.net/articles/AVR-Tutorial:_Interrupts

https://snowgoons.ro/posts/2022-02-21-atmega-avr-interrupt-handling/

"On the older AVRs, when you enter an ISR, the chip clears the global 
interrupt enable flag in SREG. This is what stops interrupts 
interrupting themselves. Then, when you exit the ISR, the reti 
instruction sets the interrupt enable flag again.

But on the newer “zero series” AVRs  does not clear the interrupt 
enable bit when it enters an interrupt service routine!

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Fpgakuechle K. schrieb:

> "On the older AVRs, when you enter an ISR, the chip clears the global
> interrupt enable flag in SREG. This is what stops interrupts
> interrupting themselves. Then, when you exit the ISR, the reti
> instruction sets the interrupt enable flag again.

Und das ist auch bei den aktuellen Inkarnationen der AVR8 noch ganz 
GENAU so.

Nur Leuten, die den Debugger/Simulator nicht kompetent benutzen können, 
scheint es anders zu sein. Diese armen Idioten haben einfach die 
entsprechende Einstellung noch nicht gefunden, die Atmel 
schwachsinnigerweise mit Rücksicht auf die geistig minderbemittelten 
C-only-User zum Default gemacht hat, damit die nicht bei ihrem 
inkompetenten Rumgepröble in main() immer wieder auf die Situation 
stoßen, plötzlich auf ein Disassembly von Code zu stoßen, der mit dem, 
was besagte Schnarchnasen aktuell debuggen wollen, so rein garnichts zu 
schaffen hat...

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Lesenswert?

c-hater schrieb:

>> "On the older AVRs, when you enter an ISR, the chip clears the global
>> interrupt enable flag in SREG. This is what stops interrupts
>> interrupting themselves. Then, when you exit the ISR, the reti
>> instruction sets the interrupt enable flag again.
>
> Und das ist auch bei den aktuellen Inkarnationen der AVR8 noch ganz
> GENAU so.

Naja, bei einer kurzen Stichprobe in den Dokus war schon eine solche 
Verhaltensänderung im SREG beschrieben.

von c-hater (Gast)


Lesenswert?

Fpgakuechle K. schrieb:

> Naja, bei einer kurzen Stichprobe in den Dokus war schon eine solche
> Verhaltensänderung im SREG beschrieben.

Tatsächlich? Wo?

von Ron T. (rontem)


Lesenswert?

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 :)

von Ron T. (rontem)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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 ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

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

von Ron T. (rontem)


Lesenswert?

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.

von Wilhelm M. (wimalopaan)


Lesenswert?

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!

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Angehängte Dateien:

Lesenswert?

c-hater schrieb:
> Fpgakuechle K. schrieb:
>
>> Naja, bei einer kurzen Stichprobe in den Dokus war schon eine solche
>> Verhaltensänderung im SREG beschrieben.
>
> Tatsächlich? Wo?

Anbei Beispiel f. serie-0 (4808: 'not cleared') und 'klassisch (328: 
'cleared').

von S. Landolt (Gast)


Lesenswert?

c-hater schrieb:
> Fpgakuechle K. schrieb:
>
>> "On the older AVRs, when you enter an ISR, the chip clears the global
>> interrupt enable flag in SREG. This is what stops interrupts
>> interrupting themselves. Then, when you exit the ISR, the reti
>> instruction sets the interrupt enable flag again.
>
> Und das ist auch bei den aktuellen Inkarnationen der AVR8 noch ganz
> GENAU so.

Hat jemand verstanden, was c-hater damit sagen will?

von S. Landolt (Gast)


Lesenswert?

PS:
> Anbei Beispiel f. serie-0 (4808: 'not cleared') und 'klassisch (328:
'cleared').

Eben! Und das steht nicht nur im Datenblatt, sondern ist tatsächlich so, 
auch bei z.B. einem AVR128DB28.

von Ron T. (rontem)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

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.

von S. Landolt (Gast)


Lesenswert?

> Hatte das jemand bestritten?

Es schien mir bei c-hater so, darum hatte ich ja gefragt, ob jemand 
dessen Tirade verstanden hätte.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Angehängte Dateien:

Lesenswert?

Wilhelm M. schrieb:

> 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.

Das Problem ist eher das zusammengestückelte Wissen beim Anwender, der 
sich einfach irgendeine Zeile aus den Datenblätter/Dokumentensatz reisst 
("weiteres Mitglied der AVR-reihe") und sich alles weitere aus diesem 
Fetzen ableiten will ('dann ist ja auch das Interrupt-verhalten wie 
immer') oder ableiten muß, weil bspw. im hiesigen AVR-Tutorial eben 
nicht auf die signifikanten Unterschiede zw. Series-0 und Vorgänger 
eingegangen wird.

Beim Interrupt-enable sind diese Unterschiede noch relativ kompakt im 
Datenblatt zu finden, da es eine zentrale Komponente ist.

Dagegen verhält sich das hier exemplarisch eröterte IR-bit des 
SPI-Modules stark abhängig von den Betriebsarten (Buffer/normal, 
Master/slave, read/write) so das es gleich zwei Register-bit Tabellen 
für die gleiche Adresse gibt (siehe Anhang, aus tiny-series 0). Es 
'gibt' eben dieses IR-bit nicht in allen Betriebsweisen dieses 
Peripherals, in vielen Modi ist es durch das RXCIF-bit an gleicher 
Position 'ersetzt'. Nur verhält sich eben das RXCIF-bit anders als das 
IF-bit.

Da verwundert es nicht, das einer vergeblich auf ein Verhalten setzt, 
was er aus anderen Datenblättern oder aus anderen Modi kennt. Oder ohne 
genaues nachlesen schlichtweg erwartet "weil es schon immer so war".

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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?

: Bearbeitet durch User
von H. H. (hhinz)


Lesenswert?

Ron T. schrieb:
> Reden wir hier eigentlich von einer kleinen Halbleiter-Klitsche nebenan
> oder von einer der größten Chip-Firmen der Welt?

Du erzählst von deinen Träumen.

von Ron T. (rontem)


Lesenswert?

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 :)

von Wilhelm M. (wimalopaan)


Lesenswert?

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?

von Wilhelm M. (wimalopaan)


Lesenswert?

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 ;-)

von Ron T. (rontem)


Lesenswert?

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.

von H. H. (hhinz)


Lesenswert?

Ron T. schrieb:
> Wilhelm M. schrieb:
>> In Deinem 50ten Post schwenkst Du schon auf dieses unqualifizierte
>> Verhalten um?
>
> Ich glaube da verwechselst Du was.

Keineswegs.

von V.Orsicht (Gast)


Lesenswert?

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 :)

Vorsicht insbesondere vor diesem Typen: Der dreht Dir das Wort im Munde 
ohne den geringsten Schlupf dabei zu erzeugen. Solche Leute nur mit der 
Kohlenzange anfassen!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.