ZitierenHallo.
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 Siro,
Das war noch viel kritischer in den Zeiten als man noch Kuchenblech grosse Boards mit Standard TTL gefüllt hat!Zitat von Siro
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
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,
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)
Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?
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
Geändert von Siro (14.07.2016 um 10:39 Uhr)
Berechtigungen
Lesezeichen