petSD+ - RTC speichert das Datum nicht - Selbsttest zeigt andere Werte

Versuche mal bitte folgendes: Zuerst nur die Fuses flashen (also Haken bei den anderen Sachen raus nehmen), danach den Bootloader wie gehabt flashen (also alle Haken im Brenntool Xgecu? setzen) und dann über SD-Karte NODISKEMU flashen.

Das Xgecu Tool macht das scheinbar in der falschen Reihenfolge (Bootloader und erst dann die Fuses) richtig wäre es aber wohl anders herum (erst die Fuses und dann den Bootloader).

In dem Fall halt erstmal nur den oberen Haken (Fuses and Lock Bits) setzen, flashen und danach nochmal den Vorgang mit den restlichen Haken (die die für das erste Flashen raus genommen hast) durchführen.

Das ist mir aufgefallen, da ich ettliche Atmega Chips hatte, die sich nicht mehr sauber flashen ließen, weil er den EEPROM Anteil nicht mehr schreiben konnte... Vorher einmal die Fuses und Lock Bits geschrieben und die ließen sich wieder flashen.

Beim ersten Schritt würde ich den Haken bei "CODE Memory" noch raus nehmen... Dann sollte er wirklich nur die Fuses richtig setzen.

Wahrscheinlich wird es ja am Brennen liegen,

ich hab trotzdem noch eine Frage.

Die RTC ist eine I2C Clock?

Kann die den benötigten Bus Takt?

Ich habe das nur noch schwammig in Erinnerung,

aber es gab da glaube ich zwei oder drei verschiedene Busfrequenzen und nicht jede Uhr oder jedes EEPROM ist für jede Busfrequenz geeignet gewesen.

Stefan

Quote from Bobbel

Warum weicht der ADC-Wert ab?

Weil das vermutlich der gemessene Wert des Analog-Digital-Wandlers ist und wo Analog im Spiel ist gibts immer Ungenauigkeiten und Rauschen. Wenn das sauber implementiert wurde (wovon ich mal ausgehen würde) dann prüft die Firmware nicht auf exakte Werte sondern ob der Wert in einem gewissen Toleranzbereich liegt. Die Abstände zwischen den Beispielwerten aus deinem Wiki-Screenshot sind auf jeden Fall gross genug um da einiges an Toleranz zu erlauben.

Quote from Bobbel

Moin moin. Mein erstes petSD+ ist fertig

Herzlichen Glückwunsch!

Quote from Bobbel

Warum in Gottes Namen wird mir ein BAD angezeigt? Warum wird mir eine andere L Fuse angezeigt, als ich geflasht habe?

Die Firmware hat erkannt, dass es ein Problem mit den Fuses gibt. Die sind nicht so eingestellt, wie sie sein sollten, deshalb das BAD. Die Firmware hat $DF gelesen, der Wert sollte aber $F7 sein. Was da schief gelaufen ist... keine Ahnung. Ich hatte das aber auch schon, dass sich der Programmierer verschluckt hat, wenn sowohl Fuses gesetzt als auch das Flash programmiert werden sollte, deshalb setze ich seit einiger Zeit erst die Fuses, prüfe ob sie passen und erste wenn sie okay sind, programmiere ich das Flash.

Probier halt einfach nochmal die Fuses zu setzen.

Quote from Bobbel

Warum weicht der ADC-Wert ab?

Das ist analoger Kram, die verbauten Widerstände haben eine bestimmte Toleranz. Die Firmware prüft, ob der gelesene Wert innerhalb eines bestimmten Bereichs ist und 573 und 574 liegen ja nun wirklich nicht weit auseinander, das ist also quasi perfekt.

Quote from Bobbel

Was sagt der PWM-Wert aus?

Das ist schon so lange her, dass die Erinnerung verblasst, aber ich möchte meinen, dass das der Wert ist, der an die PWM-Steuerung für den Kontrast des LCD-Displays ist. Wenn er das nicht ist, war es die Helligkeit. Da Dein Display aber gut lesbar ist, kannst Du diesen Wert getrost ignorieren.

Wenn die Fuses dann richtig funktionieren, würde ich noch einmal probieren, ob es dann auch mit der Speicherung der Uhrzeit funktioniert. Oder hast Du irgendwo gemessen und bist Dir sicher, dass die Batterieaufnahme keinen Kontakt gibt?

Quote from for(;;)

Das ist schon so lange her, dass die Erinnerung verblasst, aber ich möchte meinen, dass das der Wert ist, der an die PWM-Steuerung für den Kontrast des LCD-Displays ist. Wenn er das nicht ist, war es die Helligkeit. Da Dein Display aber gut lesbar ist, kannst Du diesen Wert getrost ignorieren.

Nein, der ADC-Wert ist der Wert des Button-Inputs für "no Button pressed) . Und nach meiner Vermutung (Bauchgefühl+ein paar anekdotische Dinge und ein paar krude Tests) auch ein (Teil?)problem der immer wieder auftauchenden Startprobleme. Weshalb ich die bei meiner Implementation entfernt habe (mittlerweile dank Hilfe von Andy Grady auch aus dem Code selbst).

Auf einem Pin sind 3 Buttons +WS ergeben einen variablen Spannungsteiler. 2.79V ohne jeden Button-Input und dann von da bis 4.55V

Was eigentlich eine gute und coole Idee ist, um mehrere Buttons mit einem Pin zu lesen. Aber auch anfällig für kleinste Spannungsschwankungen.
Zwischen 2.79V (keine Taste gedrückt) und PREV gehalten (2,96V) liegen 0.17V. Und dazwischen wird noch ein illegaler Bereich liegen.
Dazu kommt noch, das die Eingänge für einen Haufen Kram genutzt werden. Nicht nur die PREV/NEXT/SELECT sondern beim Start auch als Adress-Jumper (siehe Tabelle Address), zur Steuerung des Kontrasts etc.

"Drüben" im anderen Forum haben anekdotische Tests ergeben dass eine petSD+ mit einem 4,9V Netzteil nicht startet, aber mit einem 5.1V
Mit meiner Version (initial mit einem fixen Spannungsteiler der 2.79V ergibt, ohne Buttons, jetzt komplett ohne Spannungsteiler und im Code entfernte Buttonroutine) hatte ich Probleme, wenn der Power-Schalter der petSD+ das Netzteil selbst, auf der 220V Seite schaltet (das Netzteil also erst die Spannungs hochfährt). Keine Chance auf Start, sogar voller Lockup, der nicht mal durch RESET gelöst werden konnte. Auch RESET gedrückt halten beim Einschalten half nichts.

Mit einer Firmware, aus der die Buttonroutine entfernt wurde, und die auf der neuesten FM beruhte war dieser Lockup durch einmaliges Resetten nach dem Start zu lösen.

Mit einer Firmware, aus der die Buttonroutine entfernt wurde, und die auf der letzten als stabil bekannten FM bestand, startet die petSD+ (bei mir hier) jetzt auch mit primär geschalteten Netzteil klaglos. Interessant dabei, das die nächstfolgende FM revision u.A. diese Änderung hatte: "Press NEXT key on power-up for LCD contrast adjustment".


Für mich "riecht" es also stark danach, dass irgendwas mit dieser Button-Implementation, in Kombination mit nicht perfekt von anfang an (also vor allem zur Startzeit) 5.1V liefernden Netzteilen (was erklären würde, das einige petSD+ lange gut liefen und dann zu "altern" schienen) zumindest in die Problematik der Start-Bugs verwickelt sind.
Kann sein, das diese meine Empfindung Unsinn ist, und ich will auch in Keinster Weise ausdrücken das das schlecht implementiert ist.

Für mich habe ich jedenfalls entschieden dass ich in meiner Implementation komplett auf alles Unnötige Geraffel verzichte, kein Display, keine Buttons, keine Clock die eh am Pet so gut wie nichts bringt, nur die eigentlich wichtige Sache: eine verlässliche, durch DOS-Kommandos perfekt und einfach zu bedienende SD-"Festplatte".

Quote from Bobbel

Was sagt der PWM-Wert aus?

Quote from for(;;)

Das ist schon so lange her, dass die Erinnerung verblasst

Quote from Zitruskeks

Nein, der ADC-Wert ist der Wert des Button-Inputs für "no Button pressed)

Also ich verstehe ja, dass Dir der ADC-Wert ein wichtiges Thema ist, aber hier ging es nunmal wirklich um den PWM-Wert und ich betone, dass meine Erinnerung sooo verblasst nun auch wieder nicht ist.

Eure Untersuchungen und Überlegungen bzgl. des ADC-Tasteninterfaces finde ich sehr interessant und habe sie schon im "Nachbarforum" aufmerksam gelesen. Aber eines gleich vorneweg: ich habe über viele Jahre so viel Lebenszeit in die Entwicklung des petSD gesteckt, dass ich irgendwann den Entschluss gefasst habe, dass es jetzt auch gut sein muss. Außer einen pull-request bei github automatisch zu mergen (sofern das möglich ist) werde ich keine weitere Zeit mehr investieren.

Ich weiß aber nicht, ob hier, wo es um eine konkrete Fragestellung eines Erstaufbauers ging, der richtige Platz ist um einen Kompromiss oder eine Schwäche im Design des aktuellen petSD-Standes zu diskutieren, aber unzweifelhaft finde ich, dass die Energie, diese Angelegenheit in verschiedenen Foren zu diskutieren, besser in die Entwicklung eines Patches der Software oder vielleicht auch der Widerstandswerte des Tasten-Spannungsteiler geflossen wäre. Vielleicht ein kulturelles Problem. Mir scheint, der Deutsche nörgelt lieber, statt es selbst besser zu machen.

Bei mir ist das kein kulturelles Problem, es ist ein Problem dass ich nicht auf dem Level coden kann und mir das erforderliche Wissen um alle HW/SW Specs fehlt. Mich in einen über viele Dateien und hunderte Zeilen erstreckenden Quellcode einarbeiten, mit meinem gesammelten Halbwissen was sich seit 2017 aufbaut. ...Btw für den PET ab 2020, als nicht wusste was einen 2001 von einem SK unterscheidet, das funktioniert nicht. Ich kann einen Arduino dazu bewegen die ROMS meines PETs auszulesen, ich kann in C# aus passenden Libs und Frameworks VR-Anwendungen schreiben, ich frickel mich grade in Assembler ein aber... das ist einfach 10 Level über mir. Ich hab mir den Code gezogen, ich hab ihn compiliert bekommen, ich hab zumindest einige der Stellen gefunden in denen die Tasten abgefragt wurden. Die herauszupatchen wie Andy hätte ich auch noch hinbekommen, nicht so schnell, aber sicher, irgendwie.

Aber Ich KANN den Code nicht debuggen. Also tüddele ich herum und schaue ob das Ding sich bei 5V aufhängt oder nicht.

Scheib bei dem Atmega mal nur das Lock Bit und Versuche ihn danach normal zu Flaschen. Sollte dann wieder klappen

Quote from Bobbel

Mein erstere ATmega lässt sich nicht mehr löschen und auch nicht mehr programmieren. weder auf dem MiniPro, noch auf dem Batronix

Wie dein Screenshot zeigt, hast du wohl das Lockbit gesetzt. Das kann man wohl mit "High Voltage Programming" wieder rückgängig machen.