Hallo liebe Leute,
Ich schreibe diesen Beitrag, weil ich als Mikroelektroniker von der
Firma Microchip sehr enttäuscht bin. Es handelt sich um PIC Mcus. Schon
lange repariere ich Geräte als Hobby, um die Umwelt zu schonen und aus
den Gerätedesigns zu lernen. Von den vielen Herstellern, von denen ich
die Geräte bisher repariert habe zeigte sich Microchip als eine
Hauptursache warum das Gerät nicht mehr lief.
Bsp 1.:
Ich habe vor längerer Zeit ein Tenma 72-8350A Schaltnetzteil repariert.
Das Symptom war, dass es irgendwelche Hiroglyphen zeigte, ein anderes wo
sich Strom und Spannung nicht mehr einstellen ließen. Der Fehler war ein
verbauter PIC18, der nach einigen Einstellzyklen den eigenen Flash durch
Schreibzyklen selbst verschleißen ließ. Aus einem funktionierenden
Netzteil konnte ich die Firmware kopieren und auf einen neuen uC
installieren.
Bsp 2.:
Die Miele M611S meiner Oma gab seit kurzem auf. Die Steuerung übernimmt
ein PIC16. Auch ist hier dasselbe Problem dass der uC nichts mehr macht.
Die Firmware kann man auch nicht mehr kopieren, da der uC nicht mehr
ansprechbar ist.
Was mich bei den ganzen Geräten so wunderte, egal ob es Waschmaschinen,
Wärmepumpen oder Wechselrichter waren, die MCUs zb von ST sind noch nie
ausgefallen.
Jetzt regt mich das ganze schon auf, da jeder immer über Miele, Aeg,
Fronius etc. schimpft, sagt dass die doch nur abzocken und die billige
Chinesennachbaugeräte eh besser wären.
Doch wenn man die zerlegt und Datenblätter sucht, kann man gleich alles
vergessen. Worauf ich hinaus will ist, dass in diesem Fall Microchip für
seine Fehler einstehen muss und unbedingt auf Langzeittests achten muss,
damit die Hersteller, die diese Bauteile dann verwenden nicht die Fehler
ausbügeln müssen. Die Leute sollen noch an die Qualität der renommierten
Hersteller glauben!
Vielen Dank und liebe Grüße
Teil 1 ist einfach eine schlecht gemachte Firmware. Da musst du dich
beim Programmierer beschweren.
Teil 2 ist mit Sicherheit ein Folgefehler, z.B. durch Überspannung.
Ich bastel seit 30 Jahren mit PICs, und viele meiner Dinge laufen noch,
z.B. auch mit den ersten 16F84, programmiert Ende der 90er mit einem
selbstgebauten Assembler und Programmer auf einem Amiga 500, also alles
andere als "production proof".
Also ich kenne keine robusteren als die PICs.
Falsch herum in den DIP40 Sockel: Hats überlebt.
Defekter Lüfter Massefehler. Über das Tacho Signal 12 V and den PIC:
Überlebt !
Alle Ausgänge auf High programmiert und mit Masse verbunden. Kein
Problem.
Martin schrieb:> Ich schreibe diesen Beitrag, weil ich als Mikroelektroniker von der> Firma Microchip sehr enttäuscht bin.
Und es ist dein erster Beitrag hier. Ist zwar noch nicht
Frei-(Troll-)Tag, aber in diese Richtung geht dein Gejammer. Ist mir
gerade auch passiert: nach einem Jahr Betrieb der SD-Karte im Raspberry
ist das Flash ausgefallen, weil alle paar Millisekunden auf dieses
geschrieben wurde. Nichts hält ewig, auch ich nicht!
Martin schrieb:> Worauf ich hinaus will ist, dass in diesem Fall Microchip für seine> Fehler einstehen muss
Du bellst den falschen Baum an. Die Programmierer müssen das Datenblatt
lesen und beachten. Und wenn ich jeden Programmierer für seine Fehler
einstehen ließe, dann wäre ein lange Schlange vor meiner Haustür.
„Microchip PIC Microcontroller haben ein Ablaufdatum”
Haben sie nicht, sie werden aber irgendwann mal zu Staub zerfallen,
vorher werden aber die Beinchen korrodieren und das Silizium ein wenig
altern und/oder degenerieren. Der Flashspeicher hat auch kein
Ablaufdatum – jede Zelle ist wie ein Behälter, um eine Ladung, die mit
entsprechend hoher Spannung und über quantenmechanische Effekte
eingefangen werden kann, zu halten. Auf molekularer Ebene degeneriert
die Isolationsschicht der Siliziumstruktur mit jedem Durchtunneln unter
dieser hohen Spannung ein wenig, andererseits fließt jede Ladung immer
auch unabhängig davon sehr langsam ab – es ist wie bei einem riesigen
Fass mit Wasser, das mit immer mehr kleinen Löchern versehen wird, was
bei dieser Veranschaulichung die Programmiervorgänge symbolisieren soll.
Je wärmer es wird, desto schneller fließt die eingefangene Ladung auch
ab – je mehr eingeschossene Löcher das Fass hat, desto mehr wird dieser
Prozess des Wasserablaufens beschleunigt – die beiden Effekte überlagern
und addieren sich. Das Fass kann man aber in bestimmten Zeitintervallen
(z.B. alle 10 Jahre) auch nachfüllen, die eingeschossenen Löcher (durch
Writezugriffe verursacht) selbst bleiben aber bestehen. Lesen ist bei
diesen Flash-Speichern als nicht destruktiv gebaut und ist somit quasi
unbegrenzt möglich.
Die Informationen und Parameter zu den Schreibvorgängen und Datenerhalt
werden in den Datenblättern angegeben – die Anzahl der Jahre, der
Schreibzyklen in Kombination mit der Umgebungstemperatur stehen da nicht
zufällig, sondern haben genau diese Aussagekraft, die aber nicht jeder
deuten kann. Ferner ist ein Daten-EEPROM in der Regel für 10x mehr
Schreibvorgänge als der Flash für den Programmcode eines µController
konzipiert, was auch immer akribisch angegeben wird – wenn aber
irgendwelche Möchtegerne-Programmierer und Hippies, die sich auf ihr
Arduino stürzen und nur Klicken mit Wischen oder fremde Sachen kopieren
können, das in den Datenblättern dann weder lesen noch verstehen oder
beachten können, dann kommt später im Betrieb genau so eine Kacke, die
am dampfen ist, dabei raus. Die wird auch mit jedem Flash und jedem
µController passieren, wenn man das nicht beachten und entsprechend
programmieren kann – unabhängig davon, von welchem Hersteller die Chips
stammen. Kleine Qualitätsunterschiede gibt es natürlich auch, die
spielen aber bei dieser Betrachtung erstmal gar keine Rolle. Dumme Leute
schreiben dumme Programme und bauen dumme Geräte – in bestimmten Ländern
ist das sehr in Mode, weil der Profit – wie bei den Ferengi – mehr
zählt. Bei uns in Europa und in Deutschland ist das 'dumm wie Brot sein
und dumm zu designen' aber mittlerweile auch sehr en vogue.
Martin schrieb:> ließen. Der Fehler war ein> verbauter PIC18, der nach einigen Einstellzyklen den eigenen Flash durch> Schreibzyklen selbst verschleißen ließ.
Das ist völliger Blödsinn, die Flash-Speicher der meisten PICs halten
zwischen 10.000 und 100.000 Schreibzyklen aus, nur die PIC18FxxJ6x haben
nur 100 Schreibzyklen. Bei den PIC16 ist es ähnlich, meist 10.000
Schreibzyklen für Flash. Das EEPROM liegt meist bei 100.000
Schreibzyklen.
Genauso koennte man der IBM vorwerfen, bei ihren Thinkpads nur Schrott
entwickelt zu haben.
Ein 560x: Ausfall einer von der IBM zugekauften "Power-Supply-Platine".
Ein X21: Der Folienleiter im Displaydeckel ist so bloedsinnig gefaltet,
dass er bei jedem Druck aufs Display, z.B. in einem Koffer, beansprucht
wird und irgendwann bricht.
Ein T21: Der verbaute IC fuer die CPU-Spannungserzeugung neigt zum
vorzeitigem "Vergreisen". Irgendwann mag der IC einfach nicht mehr.
Einfach so... und das teure Notebook bleibt dunkel.
(Listenpreis 11k DM)
Ein A21: teilt die Leidensgeschichte mit dem T21...
Das im Akku verbaute Akkumanagement zieht zu viel Strom.
Nach einem 1/2 Jahr ist der Akku ohne Aktivitaet tief(st)entladen.
Usw. Usf...
Conclusion: Thinkpads waren (sind?) auch nur teurer Schrott.
Man kann die Firmware natürlich auch so schreiben, dass nach einer
bestimmten Anzahl an Betriebsstunden, z.B. deutlich nach der
Garantiezeit, was mit einem Flash- bzw. EEPROM-Speicher und über
Zeitmessung mit einem Timer relativ gut abgeschätzt und programmiert
werden kann, quasi ein „Defekt” kommt. So ein Speicher wäre dafür
hervorragend geeignet, denn der errechnete Zeitraum bleibt dann im
nichtflüchtigen Speicher erhalten und das Weiterzählen kann nach
erneutem Betrieb fortgesetzt werden – nach Ablauf einer geschätzen Zeit,
die dann auch noch ein wenig mit einer Zufallsvariable vermischt wird,
damit es nicht so auffällt, kann man dem Kunden dann quasi einen Schaden
in irgendeiner Form vorgaukeln – auf dem Display komische Zeichen
ausgeben lassen oder das Gerät lässt sich nicht mehr einschalten oder
hat eine Fehlfunktion – damit die Leute neue Geräte kaufen. Dazu braucht
man aber etwas mehr Grips und viel kriminelle Energie, um diesen
Sub-Algorithmus zu schreiben und in der Firmware geheim zu halten, damit
es nicht ans Tageslicht kommt. Die Ursachen für Fehlfunktionen der
Geräte liegen aber meistens woanders, ausschließen lässt sich das aber
nicht und es nachzuweisen ist eigentlich noch schwieriger.
Gregor J. schrieb:> ausschließen lässt sich das aber> nicht und es nachzuweisen ist eigentlich noch schwieriger.
So wie bei jedem geschwurbelten Verschwörungsmythos.
> zeigte sich Microchip als eine Hauptursache warum das Gerät nicht mehr lief.
Was kann Microchip für mangelhafte Software und Hardware der
Gerätehersteller?
Wenn eine 2,5V Glühbirne in einer 3V Taschenlampe dauernd durch brennt,
ist dann der Hersteller der Glühbirne Schuld?
Wenn ein fehlerhaftes Programm deine SSD verschleißt, ist dann der
Hersteller der SSD Schuld?
Wenn eine Levis nach 5000 mal Waschen löchrig wird, ist dann Levis
Schuld?
Wenn eine Scheune ohne Blitzableiter abfackelt, ist dann der Produzent
des Heus Schuld?
Gregor J. schrieb:> wenn aber> irgendwelche Möchtegerne-Programmierer und Hippies, die sich auf ihr> Arduino stürzen und nur Klicken mit Wischen oder fremde Sachen kopieren> können,
Blödsinniges Arduino bashing, mal wieder...
Was hat PIC mit Arduino zu tun?
Nichts!
Überhaupt nichts.
Oder Arduino mit Miele?
Arduino F. schrieb:> Was hat PIC mit Arduino zu tun?
Sind doch beides Teilgebiete der (angewandten) Käferkunde. ;)
> Oder Arduino mit Miele?
Bei beiden zahlt man für den Namen zu viel.
Sherlock 🕵🏽♂️ schrieb:> müssen betroffene Kunden den Austausch bezahlen
Natürlich, die hätten ihren Tesla schon lange gegen ein aktuelles Modell
eintauschen sollen. ;)
> (warum auch immer).
Weil der gute Elon halt 'n Turbokapitalist ist, der sich keine
Gelegenheit entgehen läßt, seine Kunden auszuquetschen wie 'ne Zitrone;
gut, anders wird man vermutlich nicht so einfach reichster Trump-Fan der
Welt.
Teo D. schrieb:> Wenn eine Diskette,
Das war das Stichwort!
Wer noch Disketten als echtes Speichermedium für die Arbeitsdateien
verwendet hat, der überlegt sich dreimal, ob er sich wirklich über die
Unzuverlässlichlkeiten mit Flash-Medien beklagen will. ;)
Sherlock 🕵🏽♂️ schrieb:> Wenn eine 2,5V Glühbirne in einer 3V Taschenlampe dauernd> durch brennt, ist dann der Hersteller der Glühbirne Schuld?
Nö! Der Batterienhersteller natürlich, weil er seine Zellen gar so
randvoll gefüllt ausliefert. ;)
Gregor J. schrieb:> Dazu braucht man aber etwas mehr Grips und> viel kriminelle Energie, um diesen Sub-Algorithmus zu
Wer reichlich mit diesen beiden Fähigkeiten gesegnet ist, findet
garantiert bequemere Wege sehr viel mehr Geld abzustauben, als daß er
sich als fFF (fieser Firmware-Frickler :) verdingen müßte.
> schreiben und in der Firmware geheim zu halten,> damit es nicht ans Tageslicht kommt.
Sieht man eh bei VW, was einer Firma blüht, die mit solchen Schummeleien
auffliegt. Da ist es doch viel bequemer bei z.B. einem Netzteil jede
Änderung der Einstellungen (U, I) sofort im Flash speichert; wenn man
dann auch noch die Zifferntastatur dafür einspart und durch rauf/runter
Tasten ersetzt, dann kann man sich entspannt zurücklehnen und einfach
der Natur freien Lauf lassen.
Denn sollten diese 'Programierkünste' tatsächlich auffliegen, dann wäre
das zwar peinlich ohne Ende, aber eine böse Absicht wäre wohl unmöglich
wirklich beweisbar; dagegen ist bei so 'ner Zeitbombe, die 'n Gerät ausm
Verkehr zieht, schon das Auffinden selbiger in der Firmware Beweis
genug.
Michi S. schrieb:> Wer reichlich mit diesen beiden Fähigkeiten gesegnet ist, findet> garantiert bequemere Wege sehr viel mehr Geld abzustauben, als daß er> sich als fFF (fieser Firmware-Frickler :) verdingen müßte.
Es kommt immer auf die Anzahl und Menge an Geräten an – bei
Fernsehgeräten etc. könnte sich das lohnen.
______> Denn sollten diese 'Programierkünste' tatsächlich auffliegen, dann wäre> das zwar peinlich ohne Ende, aber eine böse Absicht wäre wohl unmöglich> wirklich beweisbar; dagegen ist bei so 'ner Zeitbombe, die 'n Gerät ausm> Verkehr zieht, schon das Auffinden selbiger in der Firmware Beweis> genug.
Eine böse Absicht wird klar, wenn z.B. der Programmcode bekannt wird,
weil einer dieser Leute nicht dichthalten konnte, weil sich die in diese
Angelegenheit involvierten Herrschaften z.B. im Laufe der Zeit
zerstritten haben. Wenn man dann nachvollziehen kann, was das Programm
macht, damit das Gerät nach dieser Subroutine nicht funktioniert, dann
sind das harte Fakten. Die Folge davon kann ein Totalschaden für ein
Unternehmen oder eine Marke sein, wenn es medial und internetmäßig
bekannt wird.
Martin schrieb:> Die Firmware kann man auch nicht mehr kopieren, da der uC nicht mehr> ansprechbar ist.
Vielleicht war er auch einfach nur auslese-geschützt ...