I2C Display - SSD1306

Jain. Die Watchdog Konfiguration sind auch nur Register die mit gelöscht werden. Was nicht gelöscht wird ist natürlich die Fuse die beim Flashen festgelegt wird (und im Programm nicht geändert werden kann). Sprich ist der Hund per Fuse auf immer aktiviert gestellt bleibt er es auch, nach Reset aber wieder mit Standardwerten.
 
Ich meinte eher ob der WDT den RAM resettet..
 
Aso, nein. Macht der Chip generell nicht selbst. Auch wenn der 5 Jahre lang kein Strom hatte, der Zustand des RAMs ist trotzdem undefiniert.
 
Aso, nein. Macht der Chip generell nicht selbst. Auch wenn der 5 Jahre lang kein Strom hatte, der Zustand des RAMs ist trotzdem undefiniert.
Undefiniert ja klar! Aber sehr unwahrscheinlich das die alten Werte von mir dort noch drinn stehen oder?
 
Bascom setzt den afaik per Software auf 0x00 oder 0xFF bei Programmstart
Ja, auf 0x00 - aber das kannst Du auch mit der "$NORAMCLEAR"-Direktive unterdrücken.
Daher konnte man Bascom für winzige Tinies auch lange Zeit kaum verwenden
Dann gibt's noch Tinies ganz ohne SRAM, die kann BASCOM gar nicht programmieren.
Beim Versuch, ein "leeres" Programm mit inkludiertem AT90S2343 zu compilieren stürzt meine Bascom-Version übrigens ab (das Regfile existiert, der Controller hat auch SRAM...)
Das betrifft aber nicht den WDT oder den auch?
Ob Hund oder PowerOn: Während des Reset gehen die Beine Tristate (bis auf eventuelle Programmierleitungen (JTag, dWire, SPI (sofern CS aktiviert wird)). Nach Ablauf des Reset-Timeout werden alle I/O-Register mit ihren Defaults (*) beladen und der Program-Counter zurückgesetzt. Danach beginnt der Instruction-Decoder mit seiner Arbeit.
Wenn es nicht im Programm steht, werden die Speicher auch nicht manipuliert.
Solange der Controller während/vor dem Reset nicht stromlos wird/war, enthält er die zuletzt geschriebenen Werte bei. Sonst kann da alles mögliche drinnstehen.

mit ihren Defaults (*) : Die Reset- Quelle ist ein Bestandteil der Defaults, und kann aus einem Register ausgelesen werden (also 'ne Software-Angelegenheit). Einige Defaults sind Fuse-abhängig (Main-Clock-Prescaler, bei einigen Controllern auch der Grundzustand von (PWM-)Beinen von Timern, wenn ich mich recht erinner.)
 
Aber sehr unwahrscheinlich das die alten Werte von mir dort noch drinn stehen oder?
Selbst wenn die Daten (wegen Restspannung) im SRAM erhalten bleiben - Dein Programm initialisiert ja nach dem Reset die Schreib-/Lesezeiger auf Variablen (Arrays) im SRAM. Oder gehst Du beim Start davon aus, daß Daten im Speicher stehen könnten(!) und versuchst die zu verwenden?
 
Unwahrscheinlich nicht zwangsläufig. Vielleicht reicht die Ladung grade noch aus den RAM zu halten, für die CPU aber nicht (Stichwort BrownOut). Alles Andere ist pures Raten, weil wer weiß wie dein Code mit bereits existierenden Daten umgeht.

Zwecks Debug: Bevor du irgendwas machst lösche mal den SRAM komplett. Mache ich selbst auch. Im Fall von Bussystemen dort ebenfalls zurück setzen (bei I2C Stop, bei SPI die CS Leitung, ... Wartezeiten beachten!).

Sonst ist dem Post von LotadaC nichts hinzuzufügen.
Und stimmt, es gibt ein Register was ich vergessen hatte, das gibt den Grund für den letzten Reset an. Das wird natürlich nicht gelöscht.
 
Und stimmt, es gibt ein Register was ich vergessen hatte, das gibt den Grund für den letzten Reset an. Das wird natürlich nicht gelöscht.
Jain... es wird ein definierter Grundzustand geladen, aber dieser Grundzustand ist eben abhängig von der letzten Reset-Quelle (POR, BOR, WDR, ExtR). So, wie der Grundzustand eines Main Clock Prescale Registers abhängig von einer CKDIV8-Fuse sein kann.
 
Habe nun 3 x 10kOhm parallel geschalten ( mangels Widerständen.. ).. Und bis jetzt keine Ausfälle gehabt.
Muss anscheind wie ihr schon gesagt habt an den PullUps gelegen haben..

IMG_1678.jpg IMG_1679.jpg
 
  • Like
Reaktionen: Dirk
Korrektur:

Das Einrichten der Stacks kann man mit "$Tiny"-Direktive unterdrücken - was aber auch nicht alle Probleme löst...
Wozu legt man überhaupt den "Stack" fest? bzw. die größe? Kann das Bascom nicht selbständig berechnen?
 
Weil es drei Stacks sind, die zusammen mit den global definierten Variablen um den vorhandenen SRAM konkurrieren.
Und Du nur aus dem Code heraus nicht immer vorhersagen kannst, welcher wie weit wachsen können muß.
Bei zwei Stacks könntest Du die gegeneinander wachsen lassen, aber der dritte muß irgendwo dazwischen platziert werden...
 
**UPDATE**

Heute ist das Phänomen wieder aufgetreten.Nun habe ich zwei 10k´s parallel geschaltet, sollten also 5kOhm für SCL und 5kOhm für SDA sein.
Hmm.. Bin echt ratlos..
 
Nach wie vor immer noch das selbe Problem.
Hier mal meine Lib. Sollte jemand mal Langeweile haben, kann er ja mal ein Blick würdigen...
 

Anhänge

  • ssd1306.c
    6,3 KB · Aufrufe: 3
  • ssd1306.h
    2,3 KB · Aufrufe: 2

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)