Nabend.
Ich lese mir grad die Errata vom xmega E durch. Da sind ja einige
ärgerliche bei. Nun handelt es sich hier ja nicht um Software-Bugs, die
man mal eben so fixen kann. Ich frage mich, ob Microchip beim
Nachproduzieren theoretisch die Bugs fixen kann, oder ob das ein ganz
anderer Prozess ist, den man einfach nicht macht, weil er ein Vermögen
kostet.
Letztendlich frage ich mich, wie hoch die Wahrscheinlichkeit ist, dass
die irgendwann gefixed werden. Mir fehlen da einfach Erfahrungswerte.
Wenn der Druck von wichtigen Kunden mit hohen Stückzahlen da ist, wird
gefixt. Leider weiß man als Aussenstehender nicht, ob das bei dem
jeweiligen uC der Fall ist. Speziell bei den XMega würde ich vermuten,
dass da wegen zu geringer Nachfrage nichts mehr gefixt wird.
Jan schrieb:> Letztendlich frage ich mich, wie hoch die Wahrscheinlichkeit ist, dass> die irgendwann gefixed werden. Mir fehlen da einfach Erfahrungswerte.
Naja,es gibt ja dann in spaeteren Produktionen neuere Revisionen in
denen dann Fehler behoben wurden.
Im Anhang ein Auszug von einer Errata eines Pic12f1840
Bei dem gibt es offensichtlich eine Revision A4 und A5.
Wobei A4 die aeltere Version ist und einen Siliconfehler enthaelt was
durch ein "X" gekennzeichnet ist.
So sehe ich das zumindest.
A5 sollte also die erste Wahl sein wenn man ausgerechnet mit der
fehlerbehafteten Hardwareeinheit zu arbeiten hat.Ansonsten kann man auch
die aeltere Version einsetzen.
Fuer manche Siliconfehler gibt es Software "work arounds" was ja dann
aber auch in der Errata angegeben wird.
Häufig kommt es drauf an wie schwerwiegend die Fehler sind. Wir haben
zum Beispiel einen Controller von NXP evaluiert und festgestellt, das
eine Bussystem gar nicht darauf läuft, Errata hat es noch mal bestätigt,
in der nächsten Maskenrevision war das Problem nicht mehr vorhanden.
René F. schrieb:> in der nächsten Maskenrevision
Aha, also ist es tatsächlich so, dass ein reines Nachproduzieren nicht
automatisch eine Gelegenheit für ein Bugfixing ist. Na dann wird der
xmega E wohl nicht mehr angefasst. Schade.
> Leider weiß man als Aussenstehender nicht, ob das bei dem> jeweiligen uC der Fall ist.
Bei ST steht die Revision auf dem Chip.
Vom STM32F407 gibt es z.B. eine 'A' und eine 'Z'.
'Z' steht wohl fuer: Hier ist Ende Gelaende.
Jan schrieb:> Aha, also ist es tatsächlich so, dass ein reines Nachproduzieren nicht> automatisch eine Gelegenheit für ein Bugfixing ist.
Wie stellst du dir das vor. Dann wären unter der gleichen Revision
korrigierte und unkorrigierte Versionen auf dem Markt. Ziel der
unterschiedlichen Revisionsnummern ist doch gerade, dazwischen
unterscheiden zu können.
Wie aus gut unterrichteten Kreisen verlautbarte,
gibt es noch eine Revision '0'.
Die ist aber nicht verfuegbar bzw. wird zu einem
Produktpreis von $ 9.999.999,99 angeboten.
Har har haar....
Cartman schrieb:> Vom STM32F407 gibt es z.B. eine 'A' und eine 'Z'.> 'Z' steht wohl fuer: Hier ist Ende Gelaende.
Nicht unbedingt. Ich hab jetzt den konkreten STM Typ nicht im Kopf (ich
glaube ein L0er), aber ich hatte schon eine Errata mit Z und
nachfolgender Y Revision gesehen. Aber ich denke auch: ursprünglich
sollte bei Z Ende sein und ist es wahrscheinlich auch bei 99% der Typen.
Sei froh dass die Errata überhaupt publiziert werden. Es gibt da einige
Kandidaten, denen man den Fehler erst sehr detailliert nachweisen muss,
während der Support erst meint das könnte ja alles nicht sein, um dann,
wenn die Beweise erdrückend werden, ein fünf Jahre altes Dokument aus
dem Hut zu ziehen, in dem alles genau beschrieben ist. Da gehört auch
diese in Bastlerkreisen beliebte Bude dazu.
Vorbildlich sind die Japaner. NEC, Mitsubishi, Renesas.
Wir hatten mal den Fall in der Firma mit einer ARM CPU von Atmel, wo es
einen schwerwiegenden Fehler in der Grafikengine gab. Die GraKa war
quasi fast nutzlos. Auf der embedded world sind wir dann auf einen
engagierten Atmel-Mitarbeiter gestoßen, der uns folgendes berichtete:
Man könne den Fehler nicht fixen, da der Fehler in einem zugekauften IP
Core läge und die Lizenzrechte eine solche Korrektur nicht so einfach
ermöglichen würden. Angeblich könne nur der Lizenzinhaber das
durchführen, was zu einem neuen Lizenzvertrag führen würde. Genau da lag
das Problem, dieses Szenario sei rein wirtschaftlich bei der CPU nicht
mehr gegeben. Das war also ein Fall, wo errata nicht gefixt wurde. Es
gibt aber zahllose andere Beispiele von Atmel und auch anderen
Herstellern, wo Fehler recht schnell beseitigt wurden.
kommt vermutlich auch auf die Stückzahl an, wenn du 6-7 stellige Mengen
brauchst, dann werden die Silicon Vendors schon Wege finden die Probleme
zu beheben.
Ich hab mal eine SW-Entwicklung mit einem 16Bit Renesas uC gemacht. Das
Errata Sheet war ultra kurz, ich weiß gar nicht mehr, ob die 1 oder 2
Fehler den Chip betrafen, oder die zugehörige Flash-SW-Bibliothek.
Gerade auch bei so wenigen Fehlern frage ich mich, ob das wirklich sein
kann- sind die Japaner so viel besser als die westlichen
Chip-Entwickler?
Ich kenne die entsprechenden Konkurrenzprodukte (MSP430/HCS08/HCS12) mit
ihren teils dutzenden Seiten langen E.S. und das bei deutlich weniger
komplexen Periperiemodulen im Vergleich zum Renesas uC.
APW schrieb:> Gerade auch bei so wenigen Fehlern frage ich mich, ob das wirklich sein> kann- sind die Japaner so viel besser als die westlichen> Chip-Entwickler?
Natürlich nicht. Das heißt nur, dass entweder der Chip kaum genutzt wird
und deshalb noch keine Fehler aufgefallen sind, oder dass sie
nicht-schwerwiegende Fehler einfach gar nicht veröffentlichen.
APW schrieb:> Gerade auch bei so wenigen Fehlern frage ich mich, ob das wirklich sein> kann- sind die Japaner so viel besser als die westlichen> Chip-Entwickler?
Das Problem dort ist: ab einer bestimmten Anzahl von Errata müssen sich
die Chefs vor versammelter Weltpresse öffentlich und tränenreich
entschuldigen. Bei noch mehr Fehlern ist das einmalige Aufsuchen des
Büros mit dem Firmenschwert obligatorisch.
Ich hatte schon ein Errata gelesen wo bei jedem einzelnen Fehler
explizit dabei stand das er nicht gefixt werden wird. So eine eindeutige
Ansage habe ich aber bisher nur einmal gesehen.
Jan schrieb:> Aha, also ist es tatsächlich so, dass ein reines Nachproduzieren nicht> automatisch eine Gelegenheit für ein Bugfixing ist.
Könnte daran liegen das es ohne Maskenrevision kein Bugfixing gibt.
>> sind die Japaner so viel besser als die westlichen>> Chip-Entwickler?> Natürlich nicht. Das heißt nur, dass entweder der Chip kaum genutzt wird
Das kann täuschen. Ich glaube Renesas hat bei einigen Produktlinien mehr
Stückzahlen als ST. Eben nicht im europäischen Raum, im asiatischen Raum
schon. Das sieht man schon an den Foren. Eines in japanisch, eines in
chinesisch und ein englisches für den Rest der Welt das aber im
Vergleich zu den beiden anderen Sprachen kaum Einträge hat.
Janvi schrieb:> Das kann täuschen. Ich glaube Renesas hat bei einigen Produktlinien mehr> Stückzahlen als ST.
Renesas ist mit seinen RH850 Controllern stark im Automotive Bereich
vertreten, auch bei den deutschen Zulieferern.
Janvi schrieb:> Das kann täuschen. Ich glaube Renesas hat bei einigen Produktlinien mehr> Stückzahlen als ST.
Weltweit hat Renesas ungefähr 50% mehr Marktanteil als STM. Nur
NXP-Freescale-Motorola ist größer.
Haben mal ein schwerwiegendes Problem in einer Funktion entdeckt und
über eine Instanz dazwischen (welche das Problem reproduzieren konnte
dem Hersteller gemeldet. Nach langem Hin-Her und direktem Kontakt mit
einem Repräsentanten des Chip-Herstellers wurde das Problem seitens
Herstellers folgendermaßen gelöst:
Die spezielle Funktion wurde einfach aus dem
Feature-Sheet/Datenblatt/etc... gestrichen.
Wäre wohl mit einem Firmwareupgrade zu beheben gewesen aber hat wohl
außer uns keiner oder nicht viel verwendet. Errata dazu gabs meines
Wissens nach nie.
Wir verwenden einen dreckigen Workaround um die Funktion dennoch nutzen
zu können.
