Belinea 106020 Datei für eprom 24c08

Hi Andy, Hi Klaus,

was treibt Ihr denn hier. Helft doch einfach den Mädels und Jungs die wirklich Hilfe benötigen.

Jockel kennt sich ja Bestens aus.

Gruß

Erwin

Der mit dem Helfersyndrom )

eboll: das ist wie in der Politik: da ist auch die Ideologie wichtiger als die Praxis..

>man kann die wenigen Daten, die sich häufig ändern, auf viele Speicherzellen verteilen.

Und woher soll die Software dann wissen, in welcher Speicherzelle die aktuellen Werte stehen? Am besten abgespeichert in einer anderen Speicherzelle, die dann wiederum das gleiche Problem mit der Speicherhäufigkeit hat.

Das scheint auf den ersten Blick tatsächlich ein Problem zu sein. Wie das folgende Beispiel zeigt, läßt sich das aber ganz simpel lösen:
Angenommen du willst einen Bytewert im Minutentakt verändern und das EEPROM soll rund 30 Jahre halten. Das bedeutet, dass der Wert rund 15.000.000 mal verändert werden muss, was vermutlich einen vorzeitigen Ausfall zur Folge hätte. Du reservierst dir nun 256 Bytes Speicherplatz und setzt alle Bits auf eins (Zellen gelöscht). Um die Sache zu vereinfachen, nehmen wir an, dass nur ein Wertebereich von 0...254 zulässig ist. Um den aktuellen Wert zu finden, durchsucht die CPU den gesamten 256-Byte-Speicherbereich von oben nach unten. Der erste von 255 verschiedene Wert ist der aktuell gültige. Ein neuer Wert wird in die nächsthöhere Speicheradresse geschrieben. Ist die letzte Adresse des reservierten Bereiches beschrieben, wird beim nächsten Schreibvorgang der gesamte Bereich wieder gelöscht und der aktuelle Wert in die unterste Adresse geschrieben. So wird die Anzahl der Schreibzyklen innerhalb von 30 Jahren von 15.000.000 auf ca. 59.000 pro Zelle reduziert.

Die Anzahl der Speicherzyklen in den Datenblättern sind übrigens nicht als absolute Minimumwerte zu verstehen, die in jedem Fall garantiert werden. Das eine oder andere geht schon eher kaputt.

Das mag schon sein, aber das wäre noch lange kein Grund, gleich den ganzen Monitor ausser Gefecht zu setzen, nur weil irgendwelche Bits nicht stimmen. Bei wirklich funktionswichtigen Daten könnte man auch Backups innerhalb des EEPROMs abspeichern und im Fehlerfall auf diese zurückgreifen, wenn man es nur wollte.

Joe

Jockel: Die Hersteller geben aber Lese und Schreibzyklen an. Bei Deiner Methode wird zwar eine bestimmte Speicherstelle nicht so häufig beschrieben aber gelesen werden muss umso mehr-was die Lebendauer durchaus auch erheblich verkürzen kann. Sollte bei Deiner Methode auch nur eine Speicherstelle einen falschen Wert annehmen (also nicht 255 sein) dann ist der Spass vorbei. Von diesem zeitpunkt an greift der Prozessor dann nur noch auf falsche Werte zu. Ausserdem benötigt man wesentlich mehr Speicherplatz und da ein 4k Eeprom 5cent billiger ist als ein16k..tut der Hersteller was er tuen muss.
Übrigens gibt es mittlerweile Hersteller, die den Eepromínhalt 3 mal hintereinander ablegen und mit checksumme versehen. Wird der erste Speicherblock gelesen und an Hand der prüfsumme festgestellt, das ein Fehler vorliegt wird der zweite Block gelesen . Ist dieser dann fehlerfrei wird er in den ersten Bereich kopiert usw.
Dass die Geräte komplett ausfallen liegt dran, dass z.B. dann einen Divison durch 0 stattfindet und der arme Prozessor abstürzt.

Jockel: Die Hersteller geben aber Lese und Schreibzyklen an. Bei Deiner Methode wird zwar eine bestimmte Speicherstelle nicht so häufig beschrieben aber gelesen werden muss umso mehr-was die Lebendauer durchaus auch erheblich verkürzen kann.

wo hastn das her ? Da ist immer nur von Schreibzyklen die Rede. Die Anzahl der Lesezyklen ist unbegrenzt.

Sollte bei Deiner Methode auch nur eine Speicherstelle einen falschen Wert annehmen (also nicht 255 sein) dann ist der Spass vorbei. Von diesem zeitpunkt an greift der Prozessor dann nur noch auf falsche Werte zu.

Das ist ja auch nur die primitivste Form der Zellenschonenden Programmierung, nur um zu zeigen, dass es geht. Natürlich kann man auch hier auf fehlererkennende oder fehlerkorrigierende Kodierung erweitern.

Ausserdem benötigt man wesentlich mehr Speicherplatz und da ein 4k Eeprom 5cent billiger ist als ein16k..tut der Hersteller was er tuen muss.

Das ist kein Problem. Wenn das EEPROM keine 30 Jahre halten muss und nicht minütlich geändert wird, kommt man auch mit wesentlich weniger Platz aus. Da ist selbst im kleinsten EEPROM noch genügend Platz.

Übrigens gibt es mittlerweile Hersteller, die den Eepromínhalt 3 mal hintereinander ablegen und mit checksumme versehen. Wird der erste Speicherblock gelesen und an Hand der prüfsumme festgestellt, das ein Fehler vorliegt wird der zweite Block gelesen . Ist dieser dann fehlerfrei wird er in den ersten Bereich kopiert usw.

Das ist nur eine von vielen Möglichkeiten, fehlerkorrigierend zu speichern, wenn auch keine besonders effektive hinsichtlich Datensicherheit-Speicherbedarf-Verhältnis. Die Zellen des EEPROMs werden auch maximal abgenutzt.

Dass die Geräte komplett ausfallen liegt dran, dass z.B. dann einen Divison durch 0 stattfindet und der arme Prozessor abstürzt.

Woher willst du denn das wissen ?
1. Warum sollen fehelhafte Daten zu einer Division durch null führen ?
2. Die einfachen Microcontroller können nicht einmal dividieren. Wenn sie es können oder wenn eine entsprechende Divisionsroutine programmiert wurde, führt eine Division durch null nicht zum Absturz, es sei denn der Programmierer hat seinen Beruf verfehlt.

Joe

Jockel: da ju alles so toll kannst geh doch China programmier dort die Prozessoren und gebe dich mit einem Stundenlohn von 2-3Eur (als Programmierer) zufrieden. Ausserdem geht es hier nicht darum zu beweisen, dass man ein Gerät Hard oder Softwaremässig besser machen kann, sondern darum ob vorsätzlich das Gerät ausser Betrieb geniommen wird.

Wenn erst das ganze EEprom nach Daten durchsucht werden muß, ist die Zugriffzeit viel zu hoch(immerhin geht das seriell über I²C). Dann kann beispielsweise bei einem Monitor im laufenden Betrieb keine Auflösung mehr umgeschaltet werden nur weil das Auslesen des Eeproms viel zu lange dauert um die richtigen Geometrie- und Ablenkwerte zu erhalten.
Mit Prüfsummen und dergleichen kann man wohl erkennen, daß ein Bit gekippt ist (z.B. nach Hochspannungsüberschlägen), bei einer dauerhaft defekten Speicherzelle hilft mir das aber nichts.

Jockel: da ju alles so toll kannst geh doch China programmier dort die Prozessoren und gebe dich mit einem Stundenlohn von 2-3Eur (als Programmierer) zufrieden.

Da ich ja alles so toll kann, bleibe ich lieber hier und verdiene ein paar Euro mehr

Ausserdem geht es hier nicht darum zu beweisen, dass man ein Gerät Hard oder Softwaremässig besser machen kann, sondern darum ob vorsätzlich das Gerät ausser Betrieb geniommen wird.

Das eine hängt mit dem anderen zusammen. Ich habe nur gezeigt, dass es einerseits technisch möglich ist, das Gerät nach der Garantiezeit absichtlich ausser Betrieb zu setzen und andererseits ein Totalausfall durch Datenfehler leicht zu vermeiden wäre. Der Schritt von schlampiger Programmierung zu vorsätzlichen Fehlern ist da nicht mehr weit. Der Verdacht der Vorsätzlichkeit ist jedenfalls nicht ganz unberechtigt und ich frage mich, aufgrund welcher höheren Erkenntnisse du dies 100 prozentig ausschließen kannst.

Joe

Wenn erst das ganze EEprom nach Daten durchsucht werden muß, ist die Zugriffzeit viel zu hoch(immerhin geht das seriell über I²C). Dann kann beispielsweise bei einem Monitor im laufenden Betrieb keine Auflösung mehr umgeschaltet werden nur weil das Auslesen des Eeproms viel zu lange dauert um die richtigen Geometrie- und Ablenkwerte zu erhalten.

Das Auslesen eines kompletten 24C16-Inhaltes über I²C dauert weniger als 200 ms und es muss ja immer nur ein Bruchteil der Datenmenge ausgelesen werden. Das ist also wirklich nicht das Problem. Selbst wenn der ganze Inhalt ausgelesen werden müsste, ist das immer noch wesentlich schneller als die Einrastdauer der Zeilen-PLL.

Mit Prüfsummen und dergleichen kann man wohl erkennen, daß ein Bit gekippt ist (z.B. nach Hochspannungsüberschlägen), bei einer dauerhaft defekten Speicherzelle hilft mir das aber nichts.

Mit einer fehlerkorrigierenden Codierung wäre auch eine permanent defekte Zelle kein Problem.

Joe

Ich verstehe nicht warum Du dich so auf die Software versteifst, defekte Hardware (z.B. DST) ist ein viel schlimmerer Defekt und kommt weitaus häufiger vor. Warum soll sich eigentlich ein Hersteller diese Mühe machen sowas absichtlich zu programmieren wenn die Kisten wegen schlechtem Hardware und Softwaredesign sterben wie die Fliegen? Was erwartest Du eigentlich für 99Eur? Ein Software und Hardwaremässig ausgereiftes, langlebiges Produkt mit besten Zutaten? Der Kunde will billig, billig, billig-da ist kein Platz für Qualität.

Ich verstehe nicht warum Du dich so auf die Software versteifst,

das ist halt vorrangig das Thema dieser Diskussion.

defekte Hardware (z.B. DST) ist ein viel schlimmerer Defekt und kommt weitaus häufiger vor.

insgesamt sicher. Bei einzelnen Gerätetypen nicht unbedingt. Ich nannte ja bereits das Beispiel Apple 1705.

Warum soll sich eigentlich ein Hersteller diese Mühe machen sowas absichtlich zu programmieren wenn die Kisten wegen schlechtem Hardware und Softwaredesign sterben wie die Fliegen?

1. ist es keine Mühe und
2. wäre es die am besten berechenbare Lebensdauerkontrolle.
Wenn das Gerät die Garantiezeit überstehen soll, tut der Hersteller gut daran, die Hardware nicht zu anfällig zu machen. Ob ein schlechter DST nach 3 Jahren oder schon nach 3 Monaten ausfällt, läßt sich nicht so leicht berechnen. Da sind die austrocknenden Elkos schon wesentlich berechenbarer.

Was erwartest Du eigentlich für 99Eur? Ein Software und Hardwaremässig ausgereiftes, langlebiges Produkt mit besten Zutaten? Der Kunde will billig, billig, billig-da ist kein Platz für Qualität.

Wobei die Entwicklungskosten bei Massenprodukten kaum noch ins Gewicht fallen. Der Endpreis sagt nicht viel über die Qalität des Design von Hard- und Software aus. Auch ein Billigmonitor könnte gut durchkonstruiert sein.

Joe

Ob ein billig Moni wirklich gut sein kann bezweifel ich, selbst wenn die Entwicklungskosten umgerechnet pro Moni nicht hoch sind-für bessere Elkos etc. ist dann spätestens das Geld nicht mehr da-die rechnen mit jedem 1/10cent. Ausserdem bedenke man, dass die Entwicklungszeiten immer kürzer werden. Der Appel mag da eine Ausnahme sein (von welchem Hersteller ist der eigentlich?), ich habe früher sehr viel Monis repariert-Eeprom Probleme hatte ich kaum-hätte ich wirklich viele Eeprom fehler gehabt würde ich nicht mehr hier sitzen..Das ist auch der Grund warum ich an deine Softwaregeschichte nicht glaube-da hätte ich weit mehr Geräte mit solchen Fehlern sehen müssen (und hätte sie dann schnell reparieren können).

Der Apple 1705 war von Goldstar, heute LG, mit einer Hitachi-Röhre.

War abgesehen von den Lötstellen im OW-Teil, am BR-Print und der EEPROM-Geschichte, gar nicht einmal so übel.

Ob ein billig Moni wirklich gut sein kann bezweifel ich, selbst wenn die Entwicklungskosten umgerechnet pro Moni nicht hoch sind-für bessere Elkos etc. ist dann spätestens das Geld nicht mehr da-die rechnen mit jedem 1/10cent.

Entwicklung und Produktion sind zwei ganz verschiedene Dinge. Ein gut konstruierter Monitor kann mit billigen Bauteilen u.U. wesentlich länger halten als eine Fehlkonstruktion mit hochwertigen Bauteilen. Was nützen hochwertige Elkos, wenn sie direkt neben Hochlastwiderständen sitzen oder einfach falsch dimensioniert sind ? Ein Billigelko kann an einem nicht allzu warmen Ort 20 Jahre halten, wenn er nicht wesentlich belastet wird.

Ausserdem bedenke man, dass die Entwicklungszeiten immer kürzer werden.

Dafür steigt aber auch die Erfahrung der Entwickler. Das sollte kein Nachteil für die Qualität sein.

Der Appel mag da eine Ausnahme sein (von welchem Hersteller ist der eigentlich?),

Leider nicht, es war wirklich nur ein Beispiel von vielen. Vielleicht noch eins: Ich glaube es war der Sony GDM20E21. Dort gab es desöfteren EEPROM-Fehler bei dem nicht einmal das Hauptnetzteil anlief. Sehr ungünstig war dabei, dass der 24C16 im SMD-Gehäuse war.
Das Problem ist sehr oft, dass der EEPROM-Fehler garnicht als solcher erkennbar ist. In vielen Fällen muß man das Gerät auch aufgeben, weil man kein Vergleichtyp hat um festzustellen, ob es wirklich nur am EEPROM liegt oder am Prozessor. Wenn das EEPROM dann auch noch im Prozessor drin ist hat man sowieso verloren.

ich habe früher sehr viel Monis repariert-Eeprom Probleme hatte ich kaum-hätte ich wirklich viele Eeprom fehler gehabt würde ich nicht mehr hier sitzen..

wie viele ? Wir haben hier jahrelang regelmäßig über 100 pro Monat repariert und das ist wenig im Vergleich zu den Mengen, die auf dem Markt sind. Trotzdem sind solche EEPROM-Fehler regelmäßig aufgetreten, was mir auch von vielen anderen Monitor-Werkstätten bestätigt wurde. Euras hat daraufhin sogar extra eine EEPROM-Datenbank eingerichtet.

Das ist auch der Grund warum ich an deine Softwaregeschichte nicht glaube-da hätte ich weit mehr Geräte mit solchen Fehlern sehen müssen (und hätte sie dann schnell reparieren können).

Dann hast du vermutlich nicht die nötigen Stückzahlen erreicht.

Joe

Glaub mir ich habe genug repariert, wenn man allerdings 10000Stk reparieren muss um einen mit Eepromfehler zu finden widersprichst Du dir selber. Schau mal hier ins Forum da ist kaum ein Gerät mit Eepromfehler drin.Wenn das Eeprom im Prozessor integriert ist kann man mit entsprechender Software die Daten neu reinladen (z.B. Softjig von Samsung), da gabs sogar vom Hersteller fertige Dumps zum reinladen. Da braucht man nicht mal mehr den Moni auf zu machen

Glaub mir ich habe genug repariert,

ich bin nicht gläubig. Mich überzeugen eher Zahlen und Fakten.

wenn man allerdings 10000Stk reparieren muss um einen mit Eepromfehler zu finden widersprichst Du dir selber.

also dann gebe ich dir jetzt auch mal einen Rat: Erst lesen, dann antworten. Zur Erinnerung: Ich schrieb, dass diese EEPROM-Fehler regelmäßig auftraten. D.h. nicht einmal und auch nicht zehnmal sondern wesentlich häufiger und das auch in anderen Werkstätten.

Schau mal hier ins Forum da ist kaum ein Gerät mit Eepromfehler drin.

schauen wonach ? Die meisten Leute wissen doch garnicht, dass es sich um einen EEPROM-Fehler handelt. Im Zweifelsfall lassen sich viele unerklärliche Symptome auf einen EEPROM-Fehler zurückführen und sehr viele Geräte landen im Schrott, bevor dies endgültig geklärt ist.
Übrigens habe ich erst vor einigen Wochen ein EEPROM-Dump hier ins Forum gestellt, weil die Fehlerbeschreibung auf einen solchen Fehler hindeutete.

Wenn das Eeprom im Prozessor integriert ist kann man mit entsprechender Software die Daten neu reinladen (z.B. Softjig von Samsung), da gabs sogar vom Hersteller fertige Dumps zum reinladen. Da braucht man nicht mal mehr den Moni auf zu machen

das ist leider die Ausnahme. Die meisten Hersteller sind nicht so freundlich.

Joe

Jockel: ich kann schon lesen-nur Du offenbar willst selber nicht mehr wissen was du geschrieben hast: Wenn diese Eepromfehler recht häufig auftauchen (das müsste ja schon so sein , damit deine Theorie Sinn macht) dann kann es nicht sein, dass ich bei 500 reparierten Monis einen mit Eepromdefekt habe. Wenn ich einen Eepromdefekt hatte, dann war fast immer nur ein Wert verändert (z.B. Cut-off für eine Farbe) das lässt sich aber auch im Service-Menü neu abspeichern. Ich habe keinen Moni weggeschmissen wegen Eeprom defekt oder unklarem Defekt aber ich weiss nicht wieviel wegen einem defekten DST. Da gabs sogar mal eine Rückrufaktion von Belinea / Maxdata wg. defekten Trafos- haben die wahrscheinlich auch nur gemacht weil die Mitarbeiter in der Werkstatt Langeweile hatten. Es gibt Foren da wird über Marsmännlein diskutiert-vielleicht wäre das für dich das richtige.