SOUP (Software Of Unknown Provenance)

Hallo zusammen,
ich war mir jetzt nicht sicher wohin mit dem Beitrag, also ist er hier gelandet:

Was zählt eigentlich zu SOUP ? Erbsensuppe nicht unbedingt ;)

Info gibt es natürlich hier:
https://de.wikipedia.org/wiki/Soup

Zählt IAP(In Application Programinng mit ROM Code) zu SOUP
oder der interne Bootloader ?

Dazu ein kurzer Ausschweif:
Für meine medizinischen Geräte habe ich bisher nur eine Firmware.
Der "gesamte" Source Code liegt vor.
Es werden bei mir KEINE Bibliotheken verwendet,
weder STDINT noch STDLIB oder Printf oder ähnliches.
Alles wurde immer komplett NEU implementiert.
Damit stehen ALLE Sourcen zur Verfügung und
es gibt keine einzige Zeile Fremdcode.

Nun habe ich ein Neues Projekt und setzte den LPC1347 von NXP ein.
Dieser hat z.B. ein internes EEPROM.
Um auf diesen zugreifen zu können, muss ich die ROM internen Funktionen verwenden.
IAP Function....

Dafür existiert aber kein Source Code (zumindest habe ich keinen Zugriff darauf)
Also ist das in meinen Augen SOUP (Software unbekannter Herkunft)

Jetzt muss ich in der Risikoanlyse also auch diese Software entsprechend bewerten,
oder liege ich da falsch ?

Nach einiger Recherche habe ich gefunden, dass der ROM Code eh nicht sonderlich
ausgereift ist, man muss nämlich Interrupts sperren usw.

Das hat NXP wohl auch bemerkt und liefert nun eine Bibliothek namens Libeeprom-LPC1347 nach.
aber leider auch völlig ohne Source-Code.
Wenn ich diese also dazulinke habe ich wieder das Thema "SOUP"
Mir wäre es viel lieber die würden die Registerbeschreibungen veröffentichen für das EERPOM,
dann könnte ich selbst die Funktionen dazu schreiben und bewerten, zumal ein EEPROM zu beschreiben ist
ja nun wirklich kein Geheimnis.

Ich würd gern mal Eure Meinung dazu hören.
Siro

Hey, ich denke man kann das ganze sehr zweischneidig sehen:

Zum einen ist der Einsatz von Bibliotheken zu denen kein Sourcecode vorliegt ein wesentlichen Sicherheitsrisiko. Man kann an dieser Stelle keine Einfluss bzw. Kontrolle der implementierten Funktionen. Es ist eben wie in deinem Fall auch die Zertifizierung zu bedenken.

Auf der anderen Seite muss man sich vorhalten: Kann man wirklich selber umfangreiche Bibliotheken selbst besser/korrekt implementieren. Gerade bei häufig benutzen Bibliotheken wie z.B. der std-lib sollte man nicht vergessen, dass aufgrund der breiten Verwendung und langjährigen Entwicklung durch erfahrene Entwickler viele auch eher seltenere Fehler gefunden und behoben werden. Zudem muss man bedenken, dass auch wenn alle Funktionen selber geschrieben wurden, bzw. der Sourcecode zu einer Bibliothek vorliegt, man bei weitem keine Sicherheit hat, dass der Code in die korrekte Binärfunktionalität übersetzt wurde. Abhilfe schafft hier nur ein zertifizierter Compiler, und zum Beispiel der Einsatz von MISRA C als Standard, um undefinierte Zustände die der normale C Standard erlaubt zu verhindern.

Mein Fazit dazu ist:
Man kann die Unsicherheit die durch Einsatz von Bibliotheken ohne vorliegenden Sourcecode entstehen, z.B. durch Opensource umgehen, Im Kommerziellen Umfeld kann man durchaus auch auf Anfrage bzw. Lizenzzahlung auch den Sourcecode erhalten. Alternativ ist z.B. der Einsatz von Bibliotheken die mit einem zertifizierten Compiler + MISRA C Standard + der Garantie des Herstellers für Korrektheit der Funktionen erstellt wurden.

Hallo Siro,

In deinem Fall ist der Bootloader Bestandteil des Chips. Insofern stellt sich die Frage ob dieser Chip überhaupt für deine Anwendung verwendbar ist!
Grundsätzlich lehnt NPX jegliche Verantwortung für die fehlerfreie Funktion des Chips ab.

Grundsätzlich hat es Vorteile für den Programmierer und den Hersteller, wenn das Beschreiben von FLASH/EEPROM nur über den fest eingebauten Bootloader funktioniert. Der Hersteller kann jederzeit die Programmierparameter ändern und jegliche Software funktioniert problemlos auch auf den geänderten Chips. Vorstellbar ist sogar, dass die Chips in der Fabrikation vermessen werden und dann einen passenden Bootloader (Timing) verpasst bekommen.

Interrupts muss man beim Programmieren von FLASH/EEPROM immer abschalten, andernfalls funktioniert das Timing nicht und die Bit-Zellen können verbrannt werden, bzw. erreichen die Lebensdauer nicht! Die Frage ist nur ob man dies in der Funktion macht oder dem Programmierer überlässt. Umgehen kann man dies nur durch zusätzliche Hardware, welche den Programmierablauf übernehmen würde. Das kostet aber eine Menge zusätzliche Transistoren und funktioniert auch nur, wenn eine bekannte Taktfrequenz vorhanden ist.

MfG Peter(TOO)

Medizinische Anwendungen sind ein heikles Gebiet, ich selber hab damit noch keinen Kontakt aber Kollegen von mir arbeiten an Medizinischen Entwicklungen und was ich bisher so erfahren habe, verlässt man sich i.d.R. auf zertifizierte Hardware bzw. zertifizierte Softwarekomponenten um Entwicklungszeit zu sparen.
Der Aufwand ist enorm und die Zertifizierung (wie dir sicher bekannt ist) streng.

Hut ab auf jeden Fall von mir, dass ihr keine stdlibs benutzt! Das grenzt schon fast an Assemblerprogrammierung :)

OpenSource ist zumindest Zertifizierungstechnisch "umsetzbar" aber fertig Zertifiziert würde ich wo es geht vorziehen auch wenn es mehr kostet.
Man spart sich Entwicklungs- und Zertifizierungszeit (letztere ist wohl besonders teuer) und man muss das Rad ja nicht zwingend neu erfinden, auch wenn deine Parameter nur "Rund, leichtläufig, hohe Haftung" lautet und das zugekauft Rad zusätzlich "Leichtmetall, Verchromt, 6 Speichen im Mercedes look" mitbringt.

PS: Ich glaue in einem Projekt wurden sogar fremde (offene) Libs benutzt die dann mittels teurer Analysetools untersucht worden ist um die Code Coverage zu prüfen um die Zertifizierung zu erlangen.

Hallo!

Zitat:

---

Zitat von Ceos

Medizinische Anwendungen sind ein heikles Gebiet ... grenzt schon fast an Assemblerprogrammierung :)

---

Das stimmt. Ich war früher ein paar Jahre dort als Entwickler tätig und sage nur dazu, dass damals µC nur in Diagnostik und nichtinvasiven Therapien z.B. nicht in Herzschrittmacher nach Verlangen ("pacemaker on demand") benutzt werden dürften. Übrigens, ich programmiere bis heute nur im Assembler.

eine Aussterbende Generation .. leider .. aber ich muss gestehen dass ich nur mit Assembler nicht fröhlich programmieren kann

Ersteinmal vielen Dank für Eure Anteilnahme.

Mal eben zu den letzten Threads:

Ich habe auch jahrelang NUR Assembler programmiert, musste notgedrungen auf "C umsteigen,
wobei ich die neuen Generationen von Prozessoren auch nicht mehr nur in Assembler programmieren möchte,
aber regelmässig mir den erzeugten Assembler Code vom C-Compiler anschaue und dann tatsächlich
Fehler finde, was der Compiler falsch gemacht hat.....
Natürlich nur weil ich es ihm nicht eindeutig erklärt habe was ich machen wollte. ;)

----------------------------------------------------
Gut getestete Bibliotheken die von zig Programmieren verwendet werden, haben natürlich
viele Vorteile, eben weil Fehler bei dem einem oder anderem schon aufgetaucht wären
oder sind und dementsprechend beseitigt wurden.

Open Source hat auf jeden Fall Vorteile. Wobei bei größeren Projekten
oder Bibliotheken das auch keiner mehr bis ins Detail nachvollziehen kann.

Das Rad immer wieder neu erfinden ist wirklich SEHR zeitaufwändig, da kann ich ein Lied von singen.
Und ich würde lügen, wenn da nicht etliche von Fehlern beseitigt werden musten, bis es "augenscheinlich" richtig funktionierte.
Auch ich schaue gerne mal in fremden Code und schaue mir an wie andere das lösen.
Dabei lernt man ja auch und auch da gab es "bessere" Lösungen an denen ich mich gerne orientiere.

Die vielen Analyse-Tools, die man uns gerne "andrehen" möchte, ohne diese jetzt schlecht machen zu wollen,
können schon div. Unzulänglichkeiten, Fehler usw finden.
Leider ist eine sichere Funktion deshalb aber trotzdem nicht gewährleistet.
Die Analyse Tools können nicht die Hardware abbilden und da liegt schon ein riesen Problem.
Den Code durch einen Compiler jagen und mit dutzenden Parametern füttern ist sicher
eine grobe Abschätzung aber z.B. Read/Modify/Write Probleme kann man damit nicht finden.
Ebenso wird ein AnyseTool nicht die Problematik mit den Interrupts beim ARM Code aufzeigen.
Wenn hier nämlich in der letzen Softwarezeile das IRQ-Bit gelöscht wird, kann,
aber muss es nicht funktionieren, das hängt vom erzeugten Code ab.
Da hilft nur Testpunkte/Oszilloskop und viel Geduld und Erfahrung.

Ich brauch ja nur ein Häkchen im Compiler ändern und schwupps steht das ganze System.
Deshalb werden bei mir die Tests mit "allen möglichen" Optionen auf Speed/Size usw durchgeführt.
Die Software MUSS in allen Compilaten einwandfrei laufen.
Das kostet richtig viel Zeit, aber ich fühle mich für meine Software auch verantwortlich.

Wenn es um die Risikobewertung geht, muss ich ja auch die Hardware, also die Prozessoren selbst
mit einbeziehen und ich kenne keinen, für den es nicht einen/mehrere Errata Sheets gibt,
in denen Probleme beschrieben werden.
Auch nach Jahren werden diese Dokumente immer länger, weil irgendwann irgendwer ein Problem
unter bestimmten Bedingungen erkannt hat.
Hier muss ich eigentlich regelmäßig gucken, ob es nicht neue Fehler gibt, welche mein
System/Patienten gefährden könnten.

Ein "zertifizierte Compiler" ist auch auch ein heikles Thema.
Darf ich einen GNU-Compiler verwenden oder nicht ?
Mit Sicherheit ein SEHR gut getesteter Compiler und Open Source.
Wobei ich hier ja schon eine "speziell compilierte" Variante für die ARM Prozessoren verwende,
wobei ich hier auch nicht weis was wie zusammengelinkt und compiliert hat.

Wie Peter schon richtig schrieb: Ist die Benutzung der Prozessoren immer auf eigene Gefahr und
nicht für Lebenserhaltene Systeme gedacht.

Glücklicherweise konnte ich in meinen Geräten bisher immer eine zusätzliche Hardware einbauen,
die im Fehlerfalle das System in einen unkritischen Zustand versetzt.
Das steht auch in meiner Risikoanlyse, dass eine ausreichende Sicherheit ohne zusätzliche
Hardwaremaßnahmen NICHT gewährleistet werden kann.

Damit bin ich erstmal fein raus, da kann die Software oder der Prozessor machen was er will.
Doppelte Sicherheit ist ja IMMER angesagt in unserem Bereich.

------------------
Hier mal ein Ausschnitt aus meiner Rechtfertigung, der zusätzlichen Hardwaresicherung:
Der benutzte Prozessor Kern CORTEX-M3 enthält Fehler, es gibt verschiedene Revisionen.

Die Firma NXP verbaut diese fehlerhaften Kerne in einen Microcontroller, hiebei kommen weitere Fehler hinzu.
NXP hat also auch verschiedenen Revisionen.

Mit der Entwicklungssoftware (welche ebenfalls) Fehler enthalten kann, wird eine Geräte-Software entwickelt.
Eine Sicherstellung auf einwandfreie Funktion von 93.582 Dateien in 9.967 Ordnern der IAR Entwicklungsumgebung ist unmöglich.

Mit einer Programmiersoftware (z.B Flashmagic), welche ebenfalls Fehler beinhalten kann, wird der Chip programmiert und ausgeliefert.

Die interne Bootloader des Chips (Software) könnte auch Fehler beinhalten.

Die Endsoftware versucht Probleme mittels Checksumme zu ermitteln. Die Checksummen Funktion kann aber nicht alle Fehler erkennen, und/oder könnte selbst Fehlerhaft sein.

Dann bleibt offen:
Welche Revision des Controllers hat später der Bestücker verbaut ?
Welcher CORTEX-Kern wurde dabei verwendet ?
Mit welcher Revision wurde programmiert ?
Und zum Schluss:
Welche unentdeckten Fehler befinden sich in der Geräte-Software ?

Eigentlich ein schier endloses Grab an Fehlermöglichkeiten.

Eine ausreichende Sicherheit nur mittels Software kann NICHT gewährleistet werden.
Es ist zwingend erforderlich ein zusätzliches mechanisches/elektromechanisches Sicherungssystem zu integrieren.

Also eigentlich egal ob SOUP oder nicht, ich muss eh gegensteuern um ausreichende Sicherheit zu gewährleisten...;)

Ich wünsche Euch ein erholsames Wochenende
Siro

sorry für die folgende Ausdrucksweise

oh shit ... und ich hab schon die Ankündigung bekommen, dass da ein SIL2 Projekt am Horizont wartet >_< ... übernimmt das die Krankenkasse wenn ich mich dann einweisen lasse ?! Sollte ich eventuell mein Gehalt nachverhandeln? XD

Hallo Siro,

Auch ein netter Fehler:
Mitte der 80er Jahre setzten wir die ersten statischen 8Kx8 Low Power RAM ein, die ganz normalen 6264.
Diese hatte bei bestimmten Adressen-/Datenkombinationen Lesefehler.

Normale Speichertests zeigten keine Fehler. Und der Zelleninhalt stimmte auch. War irgendein Problem mit Übersprechen auf den Chip-Lese-Leitungen.

Dauerte aber ein paar Wochen, bis wir den Fehler finden konnten.
Die Hard- und Software war schon im Einsatz und es wurde nur das RAM von 2Kx8 auf 8Kx8 erweitert.
Wenn man die Software veränderte und sich dadurch die RAM-Adressen verschoben, war dann auch der Fehler meistens verschwunden.
Allerding reagierte der Hersteller erst wirklich als eine Expertise aus dem BBC-Halbleiterlabor vor lag, welch den Fehler unabhängig von uns fanden.

In der ersten Hälfte der 90er Jahre unterzog NS die NS16C450/550 UARTs einem Dieshrink. Dieser Baustein war damals in fast jedem PC enthalten.
Bei einem Gerät in der laufenden Fabrikation es dann Probleme, weil die Baudraute manchmal plötzlich umschaltete, war aber alles sauber nach Datenblatt aufgebaut. Wenn man mit dem Oszilloskop gemessen hat trat der Fehler nie auf :-(
Ursache war auch hier ein Übersprechen, durch die steileren Flanken im Oszillator. Durch den Dieshrink wird nicht nur die Schaltung kleiner, sondern auch die MOS-Transistoren schneller.
Abhilfe bestand dann in eine 10pF-Kondensator am Oszillator Ausgang, zumindest bis NS den Chip überarbeitet hatte.

Du solltest also genau abklären was deine Krankenkasse alles als Berufskrankheit versichert und das Gehalt den Risiken anpassen lassen! :-)

Interessant bei den ganzen Problemen war dabei, dass ich direkten Kontakt zu den Chip-Entwicklern bekam und so auch andere Fragen beantwortet bekam :-)

MfG Peter(TOO)

Der gute alte 8250 :-)
Noch heute baut man die "uralte" 8 Bit Hardware in hochmoderne 32 Bit ARM Prozessoren.
Hier hatte ich in den 80zigern schon Assembler/Pascal Routinen für die RS232-Software geschrieben,
Das lief auch immer einwandfrei, bis ich meinen ersten "ARM" Contoller hatte.
Da trat zum ersten mal das Read Modify Write Problem in mein Leben.
Im RX Interrupt gab es die Zeile rx_count++;
Das Hauptprogramm rief RX_Get auf und dort war rx_count--;
Bei allen Prozessoren vorher war das kein Problem, denn die hatten "atomare" Befehle
für inc und dec. Auch der 80286 in meinem PC-XT sowie die PIC-Controller noch heute.
Nur der Arm Prozessor konnte/kann das bis heute nicht und das geht dann gehörig daneben.
Er macht aus einem INC einen Dreizeiler, welche natürlich vom Interrupt unterbrochen werden kann....

Aber auch die Umstellung von Assembler/Pascal auf C führte wieder zum Nichtfunktionieren,
weil der C-Compiler die Umschaltung des D-LAB Bits weggekürzt hat, er sah da nicht so den Sinn drin
ein Bit zu setzen ohne es zu benutzen und dann wieder zu löschen,
das ist aber zwingend notwendig für die Registerumschaltung.
Hier half dann das "volatile"

Es gibt schon "schöne" Fehler .....:)

Ich konnte schon mal einen Softwarefehler mit einem 100nF Kondensator beseitigen :-)

Tagelange Suche nach unerklärlichem Verhalten bei einem Board mit PIC-Controller.
Endlich hatte ich die vermeintliche Softwarezeile gefunden.
Kleine Änderungen und der Fehler war weg...
Aber eigentlich war ich dann soweit fortgeschritten dass völlig
unnützer Code den Fehler beseitigte.
Es war mir völlig rätselhaft warum nun ein "NOP" die Software zum Absturz brachte.
Timing Problem war nicht gegeben, da war überhaupt nichts Zeitkritisches.
Ich habe mich dann nach "SEHR langem" suchen an Microchip gewendet und es gab da einen "Spezialisten"
der hat das Problem recht schnell erkannt, bzw. vermutet.

Der Flashspeicher im PIC war aufgeteilt in mehrere Bereiche, wobei nicht
immer alle aktiv waren. Verschob sich nun der Programmcode im Speicher
und es wurde die nächste Bank angesprungen, zog der Chip kurzzeitig mehr Strom.
Da der "entscheidende" Entkoppelkondensator etwas zu weit vom den Chip entfernt war
gab es einen Spannungseinruch/Störung...
Es ging da also nur um etwas 1 cm Leiterbahn......
Einen zusätzlichen 100nF an die Beinchen gelötet und das war es dann schon.

Hier konnte man mal sehen wie wichtig diese kleinen Dinger sind.
Nicht immer ist die Software schuld
Also immer so dicht wie möglich an die Versorgungspins.

Siro

Hallo Siro,

Zitat:

---

Zitat von Siro

Da der "entscheidende" Entkoppelkondensator etwas zu weit vom den Chip entfernt war
gab es einen Spannungseinruch/Störung...
Es ging da also nur um etwas 1 cm Leiterbahn......
Einen zusätzlichen 100nF an die Beinchen gelötet und das war es dann schon.

Hier konnte man mal sehen wie wichtig diese kleinen Dinger sind.
Nicht immer ist die Software schuld
Also immer so dicht wie möglich an die Versorgungspins.

---

Das war noch viel kritischer in den Zeiten als man noch Kuchenblech grosse Boards mit Standard TTL gefüllt hat!
Da war ein wichtiges Debugging-Tool eine Handvoll 100nF Keramik-Kondensatoren :-)

Ich war 1976 an der Entwicklung des ersten µP-gesteuerten Geldspielautomaten in Europa beteiligt. Das Projekt landete bei uns, weil es nicht funktioniert hat und sich ein paar Ingenieure schon 3 Monate daran versucht hatten.
Eigentlich hatte alles funktioniert, nur wenn Ausbezahlt wurde sprang der 6502 aus dem Programm :-(
Es wurde alles versucht: RC-Glieder, Varistoren usw. über dem Auszahlmagneten, Netzfilter usw.
Abhilfe schafften dann zwei 100nF Folienkondensatoren direkt an Ein- und Ausgang des 7805 :-(

Ich habe dann den ganzen Aufbau überarbeitet, es gab dann eine grosse Leiterplatte mit den Lampen für das Spiel, darauf wurde die CPU, RAM, ROM und I/O als Modul aufgesteckt. Des Netzteil mit Interface für den Auszahlmagneten bekam auch eine eigene Leiterplatte. Da 5V Glühlampen mit an 12V gemultiplext wurden und bei einem Reset alle Glühlampen angehen sollten (Funktionstest), bekam das Netzteil noch eine passende Stromquellen-Charakteristik.
Es gab dann total 4 Spiele, welche im Feld in 5 Minuten umgerüstet werden konnten.

Und als Dank dafür durfte ich die Prüfadapter bauen und den KIM-1 programmieren. Alles mit anfänglich keine Ahnung von Programmieren. :-(

Für die Ineltec 1977 (Elektronikmesse in Basel) habe ich dann noch 2 Spielautomaten in Plexiglas, als Ausstellungsstücke, gebaut. Dabei war die grösste Herausforderung keine Fingerabdrücke zu hinterlassen :-(

Leider kam dann zu dieser Zeit hier in der Schweiz das Geldspielautomaten-Verbot, sodass nur etwa 100 Stück gebaut wurden.

MfG Peter(TOO)

Hallo.

Die letzten paar Beiträge sind zwar sowas von Offtopic, aber ich habe sie mit Staunen und Vergnügen aufgesogen.

Danke für Eure Exkurse in die Untiefen der Elektronik !

Gruß
Christian.

Hallo Christian,

Zitat:

---

Zitat von RoboHolIC

Die letzten paar Beiträge sind zwar sowas von Offtopic, aber ich habe sie mit Staunen und Vergnügen aufgesogen.

---

So OT bezogen auf SOUP ist es gar nicht!
SOUP ist ja nur die halbe Wahrheit. Wenn, wie schon geschrieben wurde, i++ kein atomarer CPU-Befehl ist, kann sich die Software ganz anders verhalten.

Bei Fly by Wire verwendet man 3 Rechner, weil man mit 3 Rechnern eine Majoritäts-Entscheidung treffen kann. Bzw. diese Steuern dann 3 Aktoren, von denen jeder alleine die nötige Kraft aufbringen kann. Spinnt ein Rechner kompensieren sich die Kräfte von 2 Aktoren zu Null.
Zudem werden die 3 Rechner mit 3 komplett unterschiedlichen CPUs von 3 getrennten Teams entwickelt. Würde man 3 gleiche CPUs verwenden könnte man zwar Hardware-Defekte erkennen, aber wenn die CPU einen grundsätzlichen Fehler hat, sind sich die 3 CPUs einig. Wir hatten das Problem bei den ersten 80386er. Da gab es einen Temperaturabhängigen Rechenfehler in der 32-Bit Addition. Allerdings gab es zur damaligen Zeit noch kein 32-Bit DOS, sodass der Fehler bei normalen Anwendungen nicht aufgefallen ist.
Die selbe CPU von unterschiedlichen Herstellern bringt auch nichts, da meistens das Secondsource die selben Masken wie das Original verwendet.
Mit den 2 Teams, welche auch unabhängig die Software entwickeln, versucht man gleiche Denkfehler in der Software auszuschliessen.

Aber noch ein paar Softwarefehler, welche sich nicht auf SOUP beziehen:

Die Erste Ariane-5 ist wegen einem Softwarefehler abgestürzt.
Die Software wurde von der Ariane-4 übernommen wo sie 113 mal problemlos funktioniert hat.
Das Problem waren die grösseren Kräfte der Ariane-5 wodurch es zu einem Überlauf bei den Berechnungen gekommen ist.
Es wurde einfach vergessen, die Software mit den neuen Parameter-Bereichen zu testen!

Ein ähnliches Problem gab es bei den Patriot-Luftabwehrraketen.
Hier wurde die Zeit in 10tel Sekunden in einem 24-Bit Integer-Register erfasst. Für weitere Berechnungen wurde dieser Interger in einen FP-Wert konvertiert und mit 1/10 multipliziert um ganze Sekunden zu erhalten. Nun ist aber 1/10 binär ein nicht abrechender Bruch.
Nach 100 Stunden nach den Booten betrug die Abweichung der Zeit dann 0.34 Sekunden. Zudem kommt es nach etwa 19 tagen zu einem Überlauf.
Die Scud-Raketen fliegen mit knapp 1'700m/s, sodass die Patriot bei 0.34s Abweichung über 500m daneben lag.
Bei den Tests wurde das Patriot-System immer nur kurz vor dem Test gebootet.

Die ersten F-16 stellten sich wegen eines Vorzeichenfehlers auf den Kopf, wenn sie den Äquators überflogen.

So Ende der 70er Jahre hat die Kienzle Lohnbuchhaltung Minusstunden nicht vom Lohn abgezogen, sondern zusätzlich gut geschrieben. Auch ein Vorzeichenfehler.

MfG Peter(TOO)

Jetzt muss ich Suppe (SOUP) selber auslöffeln ;)

Um dem Thread und meiner Arbeit noch einen sinnvollen Wert zu geben,
habe ich mich entschlossen, die libeeprom-lpc1347.a Version 3
möglichst ausgiebig zu testen.

Dafür habe ich heute Testfunktionen geschrieben.
Es wurde ein RAM Array angelegt, welches das gesamte EEPROM wiederspiegelt,
mit Ausnahme der letzten 64 Bytes, dazu später.
Dieses RAM Array wurde mit definierten Werten beschrieben.
Dann erfolgte ein EEPROM Write mit dem "gesamten" Block.
Dann wurde das RAM Array komplett gelöscht und der Inhalt aus dem
EEPROM wieder als kompletter Block ausgelesen und verglichen.
Das verlief einwandfrei. Dieser Test wird noch mit unterschiedlichsten
Werten und Mustern durchgeführt.

Dann wurden nur einzelne Bytes oder Words ins EEPROM geschrieben
rückgelesen und verglichen. Bisher auch alles einwandfrei.

Zudem wurde nach dem Beschreiben des EEPROMs die Versorgungsspannung über längere Zeit
abgeschaltet um zu prüfen ob die Werte auch wirklich im EEPROM erhalten bleiben.
Dieser Test wurde auch über mehrere Stunden durchgeführt.

Nun wollte ich testen ob der hintere EEPROM Bereich , also die letzen 64 Bytes
tatsächlich nicht beschrieben werden können, wie im Usermanual erwähnt.
Dafür habe ich mir Testfunktionen für die RS232 geschrieben.
Hier kann ich nun mit einem Terminal Programm gezielt auf alle Bereiche zugreifen
und prüfen.
Es bestätigte sich, dass exakt die letzen 64 Bytes des EEPROMs nicht beschrieben werden
können. Das Lesen dieser Speicherstellen ergibt immer 0x00

Morgen gehts es weiter mit dem Tests:
Dazu wird ein höchst priorisierter Interrupt eingestellt,
welche lediglich ein Portbit toggelt.
Hier wird ein Oszilloskop angeschlossen.
Das Hauptprogtramm beschreibt dann sporadisch das EEPROM mit
verschiedenen Werten und Speichergrössen.
Das Testsignal dürfte sich dabei nicht verändern, sofern die EEPROM
Funktionen, wie beschrieben, wirklich keine Interrupts sperren
oder in irgend einer Form die CPU ausbremsen.

Die Versionsnummer der Bibliothek konnte auch ausgelesen werden.
Die Funktion liefert eine "3" zurück.

So kann ich die Bibliothek bzw. deren Funktionen verifizieren
Dann wird für mein Projekt exact DIESE Bibliothek vom Datum xxx
mit abgelegt und die Testreihen dokumentiert.
Ein Update dieser Bibliothek darf dann nicht mehr erfolgen.

Update heute morgen:
Ich stochere grade in der Assembler "Suppe" von NXP

Anhand der EELIB_entry funktion
erkennt man schon, dass viele Programmierer nicht mehr sinnvoll denken.
Sorry für die Kritik, aber es gibt genau 2 Funktionen.
EEPROM schreiben und EEPROM lesen.
In vielen Geräten wird nur einmal ins EEPROM geschrieben zum Beispiel beim Kalibrieren.
Danach wird nur noch gelesen.
Generell ist das Verhältnis von Lesen und Schreiben bei EEPROMs "Lesebetont"
In der Bibliothek konnte ich dem Assemblercode entnehmen, dass
hier zuerst auf Schreiben geprüft wird und damit unnütze Rechenzeit verbraten wird ;)
Generell ist der erzeugt Code recht "suboptimal" wie ich grade feststelle, zumindest wohl ohne Optimierungen compiliert.

Das EEPROM Schreiben habe ich nun grade Zeile für Zeile durchgesteppt, es gibt wirklich keinen Code welcher die Interrupts
des Controllers beeinflusst.
Die Funktionen arbeiten augenscheinlich nur mit Stackvariablen,
es ist also kein zusätzlicher RAM erforderlich
Alles spielt sich irgendwie im Speicherberiech 4003.C000 ab.

Die Versionsnummer liefert in minimalster Weise lediglich eine konstante "3" zurück.

Für die obersten 64 EEPROM Bytes habe ich in meiner Funktion einen entsprechenden Code implementiert,
damit diese nicht beschrieben werden, das existiert aber auch schon in der Library selbst wie ich grade sehe.

Siro