Übersicht serieller Grafik-LCD's?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • DG7GJ schrieb:

      Löst der Empfang eines Zeichens über den RxD im µC auch dann einen INT aus, obwohl kein INPUT, Inkey oder so definiert wird.
      Das hängt von der Konfiguration ab.
      Ich weiß nicht ob Bascom mit
      Open "COM1:"
      einen Interrupt verwendet geschweige denn den Hardware-Uart verwendet.
      Aber das kannst du im Simulator feststellen.

      Simulator starten und in den Reiter Interrupts wechseln.
      Dort werden alle Interrupts, die der Controller auslösen kann angezeigt.

      Nicht konfigurierte Interrupts bleiben gellgrau. Konfigurierte Interrupts sind schwarz.
      Die relevanten Interrupts für Uart sind
      • URXC (Byte empfangen)
      • UDRE (Datenregister leer)
      • UTXC (Byte gesendet)
      Da ist dann noch eine Nummer angehängt, um welchen Uart es sich handelt (0 oder 1).
      Kannst ja mal die aktiven Interrupts posten. Vielleicht fällt dann noch was auf.
    • Hallo Mitch64!

      Mitch64 schrieb:

      Simulator starten und in den Reiter Interrupts wechseln.Dort werden alle Interrupts, die der Controller auslösen kann angezeigt.

      Nicht konfigurierte Interrupts bleiben gellgrau. Konfigurierte Interrupts sind schwarz.
      Die relevanten Interrupts für Uart sind
      • URXC (Byte empfangen)
      • UDRE (Datenregister leer)
      • UTXC (Byte gesendet)

      Interessant! Der Bascom-Simulator zeigt mir nur einen einzigen aktiven INT an: OVF2, also Timer2 Overflow.

      Das ist also meine asynchrone RTC. Sonst zeigt mir der Simulator nix an:
      Screen2.jpg

      Nicht mal die diversen UART-Ausgaben aktivieren irgend welche Interrupts.
      Kann ich dem Simulator da trauen? Ich dachte die Hardware-UARTS nutzen generell Interrupts, ob der User nun will oder nicht?

      Demnächst, wenn das LCD mal zuverlässig läuft, und auch AVR-DOS funktioniert, geht es um das parsen der RxD0.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Nicht mal die diversen UART-Ausgaben aktivieren irgend welche Interrupts.
      Kann ich dem Simulator da trauen? Ich dachte die Hardware-UARTS nutzen generell Interrupts, ob der User nun will oder nicht?
      Ich denke du kannst da dem Simulator trauen. Natürlich immer mit einem Quäntchen Unsicherheit.

      Bascon wird in das Register für den Uart z.B. schreiben und dann das Flag abwarten UTxC. Dann dieses manuell löschen und das nächste byte rein schreiben. Beim lesen wartet eben auf das Flag URxC. Wird also alles gepollt.

      Wenn du Buffer verwendest, sieht es wieder anders aus.

      Also haste nur den ovf2-Interrupt.
      Und was steht da drin in der ISR?
    • Hallo!

      Mitch64 schrieb:

      Ich habe das mal geprüft.

      Interrupts werden scheinbar erst verwendet, wenn du einen Sende oder Empgangsbuffer aktivierst.
      So etwa:

      Config Serialin0=Buffered, Size=20
      oder
      Config SerialOut0=Buffered, Size=20
      Achso, war schon verwundert.
      Aktuell verwende ich keinerlei Buffer. Ob ich später welche brauche weis ich noch nicht.
      Die ESP8266 meldet sich bislang nur an meiner FritzBox an und tauscht dann gelegentliche Handshakes mit ihr aus.
      Beim Connect soll dann am RxD0 sowas wie "+IPD,<Len>[,<remote IP>,<remote port>]:<data>" erkannt werden.

      Ob ich das jederzeit zur beliebigen Laufzeit zulasse, oder dafür ein manuellen Sondermodus bastel weis ich noch nicht.
      Erst mal bin ich noch am LCD sowie dem funktechnischen Teil.
      Irgend was scheint da mit der AGC des RFM69HW ziemlich neben der Spur zu laufen.

      Terminal empfängt die Pakete zweier Sender: Ein Sensor hier am Tisch liegend, etwa 1m Entfernung, und ein Repeater (die Referenzuhr) hinter augenblicklich zwei Stahlbetonwänden und gut 9m Luftlinie.
      Sendeleistung beide aktuell +13dBm.

      Anfangs kamen da glaubhafte RSSI-Werte raus:
      Der Sensor (<1m Distanz) kamen am Terminal mit -23 bis -26dBm an, der Repeater (9m, zwei Wände) mit -71dBm.
      Alles gute, plausible Werte.
      Seit gestern Abend hingegen:
      Sensor, egal ob 1m oder 10cm durchweg mit -75dBm.
      Der Repeater mit ca. -90dBm.
      Ursache liegt darin das die AGC falsch regelt...

      Grüße

      Jürgen
    • Mitch64 schrieb:

      Also haste nur den ovf2-Interrupt.Und was steht da drin in der ISR?

      Wie bereits gesagt, das wird durch
      Config Clock = Soft , Gosub = Sectic
      gebastelt. Diese springt die Sectic an:

      Sectic:
      LCDtime = 1 ' Flag für LCD-Ausgabe
      If _sec = 30 then Gosub LCDadc ' Wenn Sekunde=30 ADC abfragen (Akkuspannung)
      return

      Bliebe noch die Frage wie Config Clock = Soft das genau macht.
      Also ist es direkt der OFV2 welcher die Sectic anspringt, oder sitzt da ein Counter zwischen.

      Mal sehen...Register für den Timer2:
      TCCR2B sitzt auf b00000101, ergibt einen Precounter von 128
      ASSR sitzt auf b00100000, also asyncroner Modus am 32,768kHz Quarz.

      Also 32,768kHz / 128 = 256Hz
      Wenn das 8Bit-Register vom Timer2 (TCNT2) überläuft kommt also OFV2 mit exakt 1Hz.

      Somit wäre es nun auch geklärt das auch der Timer keine Interrupts schneller als 1s fabriziert.

      Auf der anderen Seite habe ich nun noch einen Verdachtspunkt.
      Irgend ein Hapser in meinem SRAM: Obwohl ich keinerlei Overlays verwende ist es mir erst letztens beim Repeater passiert das eine Variable sich plötzlich unwillentlich aber regelmässig verändert hat.
      Ein Byte "Aufgabe" welches die Betriebszyklen steuern sollte.
      Wurde in der Sectic ahängig der aktuellen Sekunde auf einen Wert zwischen 1-6 gesetzt um der Hauptschleife zu sagen welche Sub als nächstes angesprungen werden soll.
      In den jeweiligen Subs sollte die Aufgabe als erledigt markiert werden: "Aufgabe = 0".

      Lief Amok, nahm im laufe der Zeit alle möglichen Werte an.
      Musste ich beheben durch totlegen der Variable und anlegen einer Ersatzvariable "Aufgabe1" an anderer Stelle der Dim-Tapete.
      War der selbe µC - ein ATmega1284P wie jetzt hier beim Terminal.

      Sollte ein ähnlicher Fall jetzt auch hier vorliegen, dummer weise bei einer Variable die von der glcdEADOGM128x6.lbx dimensioniert wird, würde das meinen Effekt erklären.

      Gestern konnte ich ein paar Abstufungen beobachten.
      Nach einigen Stunden korrekter LCD-Anzeige rutschte die Anzeige spontan um exakt 2 Pixelzeilen nach unten.
      Das verwendete Font8x8TT lässt unter dem ASCII-Zeichen exakt eine Pixelzeile frei.

      Der Rutsch um 2 Pixel nach unten war darin zu erkennen das die unterste Zeile leicht beschnitten waren.
      Die letzte abgeschnittene Pixelzeile sowie die nachfolgende Leerzeile tauchte dafür am obersten Rand der Anzeigefläche auf.
      Ab diesem Punkt rutscht es dann, zunächst gleichbleibend mit diesem 2-Pixel-Versatz um jeweils 8 oder vielfache von 8 Pixeln nach unten.
      DSCF5252_M.jpg

      Die Zeile "Mi 21.08.19 16:40:29s" sollte eigentlich in der obersten Displayzeile (Lcdat 1,1) und die darüber liegende Zeile "Akku: 3.685V" in der untersten Displayzeile (Lcdat 7,1) liegen.
      Der erste Versatz um exakt 2 Pixelzeilen bleibt eine ganze Weile konstant, während nach und nach mehrere Zeilen dann nachrücken.
      Wenige Minuten nach diesem Foto ist dann das LCD leer.
      Das einzige was dann hilft ist ein manuell (Tastenabfrage) Initlcd.

      Grüße

      Jürgen
    • Hallo!

      Mitch64 schrieb:

      Haste du was an der RFM-Konfiguration geändert?
      Sonst vielleicht mal richtig Saft weg und wieder dran (General-Reset).
      Mitnichten, die RFM-Konfiguration wird bei jedem Reset in den RFM geschoben und verbleibt dann dort während der kompletten Laufzeit. Gelegentliche Resets (ISP-Programmierungen) und auch Total-Resets (Akkuentnahme) verändern an diesem AGC-Verhalten nichts.

      Ansonsten habe ich einen Komplett Reset im Sinne von "Strom wech" in der Schaltung nicht berücksichtigt.
      Bei zukünftigen Projekten werde ich das aber berücksichtigen.
      Bisher weniger beim RFM69, weil da ein Soft-Reset möglich (und vor jeder initialisierung obligatorisch sinvoll) ist.
      Spätestens aber beim ESP hätte ich sowas vorsehen sollen, weil der bezüglich Stromaufnahme brutal ist.
      Eine Art Notabschaltung, z.B wenn die 18650-Zelle auf 3,00V runter ist - nicht möglich.
      Dumm aber auch: Mit dem ATmega1284 fahre ich bezüglich Port-IO's schon ziemlich auf Kante bei diesem Projekt.
      Von Anfangs 2 ungenutzten IO's habe ich nun nur noch einen.
      Sollte ich das Teil nochmal irgendwann neu designen, oder vergleichbar umfangreiche Projekte, werde ich wohl was mit mehr Pins nehmen müssen.
      Abseits der ATXmegas ist mir letztens noch der Mega2561 aufgefallen, TQFP-64.
      Allerdings wurde ich beim überfliegen des Datenblattes nicht schlau über die Programmierschnittstelle.
      ISP ist es wohl nicht, TPI im Sinne von ATXmegas wohl auch nicht, sondern irgend ein Mischkonstrukt.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Bliebe noch die Frage wie Config Clock = Soft das genau macht.
      Also ist es direkt der OFV2 welcher die Sectic anspringt, oder sitzt da ein Counter zwischen.
      eigentlich stehts ja schon im Text. OVF2 ist der Überlauf Interrupt von Timer 2. Also klar ist da ein Counter "zwischen". Mit dem Timer wird wohl die Uhr nachgebildet.


      DG7GJ schrieb:

      Auf der anderen Seite habe ich nun noch einen Verdachtspunkt.
      Irgend ein Hapser in meinem SRAM: Obwohl ich keinerlei Overlays verwende ist es mir erst letztens beim Repeater passiert das eine Variable sich plötzlich unwillentlich aber regelmässig verändert hat.
      Ein Byte "Aufgabe" welches die Betriebszyklen steuern sollte.
      Das ist natürlich nicht schön. Da überschreiben sich wohl irgendwelche Speicherbereiche.
      An den Stackwerten kann es eigentlich nicht liegen die sollten ja groß genug sein. Aber wer weiß, vielleicht ist da ein Bug irgendwo?

      Mach doch mal alle deine Stackwerte auf 200 (Bytegrenze). Das reicht immer noch dicke. Sollte das Überschreiben bleiben, liegt hier offensichtlich kein Bug vor.


      DG7GJ schrieb:

      Gestern konnte ich ein paar Abstufungen beobachten.
      Nach einigen Stunden korrekter LCD-Anzeige rutschte die Anzeige spontan um exakt 2 Pixelzeilen nach unten.
      Das verwendete Font8x8TT lässt unter dem ASCII-Zeichen exakt eine Pixelzeile frei.
      Das deutet doch drauf hin, dass "eigentlich" alles ok läuft. Aber dass irgendwann mal eine ungünstige Konstellation auftritt, die dann zu dem Fehler führt.

      Ich denke da wieder an einen Interrupt. Selbst wenn der nur alle 3 Stunden mal auftritt und man nur alle 5 Minuten 3ms was macht, werden sich die beiden irgendwann treffen.

      Vielleicht versaut dein Interrupt den SRAM bzw wirft da was durcheinander.
      Ich kann dir nur empfehlen, mach mal den so, dass du nur Flags setzt in der ISR.
      Und in der Hauptschleife dann abarbeiten. Vielleicht dauert die Abarbeitung zu lange.

      Wenn du das nie probierst, wirst du nie erfahren, ob es an dem liegt.

      Ich habe auch schon an die Routine Sectic erinnert.
      Mach doch da mal bevor du irgendwelche Befehle ausführtsr ein PUSHALL rein.
      Und vor dem Return als letzter Befehl POPALL.

      Leider zeigst du nur immer einzelne Passagen von deinem Code.
      Da kann man schlecht helfen, weil man die Zusammenhänge nicht erkennt.

      Stell den doch mal hier rein, dass jeder selber den code compilieren und im Simulator testen kann.
    • Aua!
      Ich bin die letzte Stunde mal versunken in der SRAM-Tabelle des Simulators, und dort auf eine recht chaotische Stelle gestoßen.
      Von h0100 bis h05A0 stehen alle meine gedimmten Variablen im SRAM, doch dann kommt es:

      Der Quelltext dieses Bereiches sieht wie folgt aus:

      BASCOM-Quellcode

      1. Dim ocr2bS as String*8
      2. Dim assrS as String*8 '<- meine letzte selbst definierte Variable
      3. Config ADC = Single, Prescaler = AUTO , Reference = OFF
      4. Config SPI = Soft, DIN = PinB.6, DOUT = Portb.5, SS = NONE, Clock = Portb.7, MODE = 1
      5. spiinit
      6. waitms 100
      7. Config GRAPHLCD = 128x64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7
      8. initlcd
      9. waitms 100
      10. Open "COM1:" for Binary as #1 ' Öffne Com1 zum ESP-WLAN
      11. Open "COM2:" for Binary as #2 ' Öffne Com2 zur Serviceschnittstelle
      12. Config Clock = Soft , Gosub = Sectic
      13. config Date = DMY , Separator = DOT
      14. Date$ = "14.05.19"
      15. Time$ = "12:52:00"
      16. enable Interrupts
      17. cls
      18. Setfont Font8x8TT
      Alles anzeigen

      Meine zuletzt dimensionierte Variable assrS as String*8 endet auf SRAM-Adresse h05A0
      Dann wird es spannend:

      h05A1 - 05A2 : FONTTABLE
      h05A3 : FONTTABLE_H
      h05A4 : LCDROW
      h05A5 : LCDCOL
      h05A6 : LCDREV
      h05A7 : _SEC
      h05A8 : _MIN
      h05A9 : _HOUR
      h05AA : _DAY
      h05AB : _MONTH
      h05AC : _YEAR
      h05AD - 05B5 : DATE$
      h05B6 - 05BE : TIME$
      h05BF : LCDCOUNTER

      Kurz gesagt:
      Offenbar hat die die Clock mitten in den Adressbereich der Variablen von der GLCD-Lib gesetzt!
      Bislang fand ich kein Indiz dafür das irgendwas von der Clock-Funktion sich überlagert oder überschieben hat, aber wundern würde es mich nicht.

      Morgen also erstmal ein komplett neues Projekt komplett neu aufziehen und gucken wie ich Bascom das SRAM-Gestricke in Ordentlich aufzwinge.


      Mitch64 schrieb:

      Leider zeigst du nur immer einzelne Passagen von deinem Code.
      Da kann man schlecht helfen, weil man die Zusammenhänge nicht erkennt.

      Ähm, mitnichten...auf Seite 2 im Posting Nr. 31:
      Übersicht serieller Grafik-LCD's?
      liegt das bislang komplette Projekt im Anhang.

      Abgespeckt im Sinne von: Problemorientiert neu angefangen letzte Woche mit bislang nur den Modulen (Subs) die bislang Funktionieren, also ohne E²PROM-Datenlogger, ohne SD-Card AVR-DOS, und ohne ESP-Funktionen.
      Dafür mit RFM69HW Initioalisierung und Paketempfang und LCD-Init und Ansteuerversuchen.

      Dieser dort (Anhang Posting 31) abgebildete Status ist noch weitgehend aktuell und die Anpassungen bislang eher überschaubar.
      Also wie im Laufe des Themas vielleicht untergegangen sein mag:
      POPALL / PUSHALL in der Sectic, dann in der LCD-Ausgabe-Sub unmittelbar vor und nach den Lcdat-Befehlen jeweils ein waitms 100.

      Letzteres um testweise eine hinreichende Zwangspause auf dem SPI-Bus zwischen RFM-Kommunikation und LCD-Befehlen zu erzwingen.

      Aber wie bereits vorhin geschrieben: Die m.E. sehr kritische verteilung der von Config Graphlcd und Config Clock dimensionierten Variablen im SRAM richen für mich sehr verdächtig.
      Morgen werden ich mir also das Projekt komplett neu erstellen und mir nochmals Gedanken machen müssen welche Variablen ich tatsächlich brauche.
      In der aktuellen Dim-Tapete sind schon diverse Leichen enthalten die längst hinfällig sind.

      Grüße

      Jürgen
    • Über die Variablenverteilung im SRAM musste ich mir bisher keine Gedanken machen, solange ich in Basic programmiere. Assembler ist wieder was anderes. Aber da sind wir ja auch nicht.

      Bascom legt die Adressen für Variablen im SRAM der reihe nach fest, so wie der Compiler auf sie trifft.
      Variablen die zuerst dimensioniert werdn liegen am RAM Anfang und die anderen jeweils danach.

      Libs, die eingebunden werden kommen zum Schluss. Werden dort Variablen dimensioniert, werden die an die bisherige Variablenliste im RAM angehängt.

      Mich verwundert da also nicht wirklich was.

      Dann werd ich mir deinen Code erst mal laden und schauen, ob mir was auffällt.

      Nachtrag.
      Die angegebene Datei LCD-Test.zip enthält nur Include-Dateien.
      Das Mainfile fehlt da völlig. Also Compilieren nicht möglich.
    • Sorry, geht doch.
      Du hast eine INC-Datei als Hauptdatei.

      Nachdem ich das kompilieren konnte, habe ich auch einen Fehler gefunden!
      Ob das der jetzt ist wird sich rausstellen.

      In deiner Sectic rufst du wenn _sec=30 ist diese Routine auf:

      BASCOM-Quellcode

      1. LCDadc:
      2. cls
      3. adcwert1 = getadc(3)
      4. adcwert2 = getadc(3)
      5. adcwert3 = getadc(3)
      6. adcwert1 = adcwert1 + adcwert2
      7. adcwert1 = adcwert1 + adcwert3
      8. adcwert1 = adcwert1 / 3 'Mittelwertbildung
      9. Akkuspannung0 = adcwert1 * 0.0017578125 'AVref = 1,80V
      10. Akkuspannung1 = Akkuspannung0 + 2.50 'Differenz = 2,49 - 2,50V
      11. AkkuS = Fusing(Akkuspannung1, "#.###")
      12. 'Lcdat 7, 1, "Akku: ";AkkuS;"V"
      13. Return
      Alles anzeigen
      In der Zeile 2 greifst du eindeutig auf das LCD zu, also auf die SPI-Schnittstelle.

      Mach mal das CLS raus und versuch es nochmal.
      Vielleicht ist der Fehler jetzt weg.
    • Hallo!

      Wie bereits gesagt "lebt" soein Quelltext gerade in der Entwicklung und Fehlersuche.
      Wenn ich hier Tips und Hinweise bekomme dann wende ich diese freilich auch an.

      Als der Hinweis von Mitch64 kam das ich in der Sectic alles rausschmeißen sollte was möglicherweise irgendwas mit Interrupts zu tun hat, tat ich das selbstverständlich. Dort wird dann nur der neuen Variable "ADClable" ein Wert zugewiesen, welcher über eine weitere If-Then-Zeile ausgewertet wird.

      Ebenso sind die testweise eingefügten CLS-Anweisungen bereits wieder raus - war mir gar nicht mehr bewusst das sie überhaupt im hochgeladenen Projekt noch enthalten waren.
      Denn diese, z.B. in der Sectic, waren ein kurzer Versuch das LCD regelmässig zu leeren.
      Schlug aber fehl - denn wenn ein Versatz erst mal drinn war, reichte kein CLS mehr, da musste dann ein Initlcd her, der bis heute noch immer als Notbehelf via Taste auslösbar ist.

      Aktuelle Änderung, wo ich gerade wieder über der SRAM-Auswertung hänge:

      Änderung der Reihenfolge von:

      Config GRAPHLCD = 128x64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7
      Config Clock = Soft , Gosub = Sectic

      auf:

      Config Clock = Soft , Gosub = Sectic
      Config GRAPHLCD = 128x64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7


      So auf den ersten Blick sieht es zunächst aufgeräumter aus:

      Der String TIME$ endet auf h05B9...dann

      h05BA = FONTTABLE

      h05BB = FONTTABLE

      h05BC = FONTTABLE_H

      h05BD = LCDROW

      h05BE = LCDCOL

      h05BF = LCDREV
      h05C0 = LCDCOUNTER

      Das einzige was mich noch wundert und wo mich hier eventuell jemand auflären könnte:
      Das aller erste Byte im SRAM auf Adresse h0100 enthält richtiger weise meine erste Variable "ID".
      Als zweite definierte Variable müsste das Array RFMinit(113) folgen.
      Klicke ich jedoch im Simulator auf Adresse h0101 sagt mir Bascom das dort "__READRAMPZ" drauf liegt.
      Erst ab Adresse h0102 fängt meine zweite Variable RFMinit(113) an *grübel*

      Grüße

      Jürgen
      Dateien
      • LCD-Test 1.zip

        (19,57 kB, 15 mal heruntergeladen, zuletzt: )
    • Hallo!

      Mitch64 schrieb:

      Ist das Problem mit dem Display jetzt weg oder nicht?
      Derzeit der selbe Status wie vor knapp 3 Tagen:
      Als ich diverse Tips ausprobiert habe (u.a. die POPALL/PUSHALL in der Sectic die aber nix änderten) kam ich auf Die Idee in der LCD-Schreibsub vor und nach den LCD-Zugriffen ein Waitms 100 eingefügt habe. In der Hoffnung durch eine Zwangspause auf dem SPI das LCD zu verwöhnen.

      Ergebniss: 2 Stunden fehlerfrei, bis es dann doch wieder auftrat.

      Jetzt läuft das Teil (mit der Umstellung erst Config Clock, dann Config Graphlcd) seit knapp 90~100 Minuten fehlerfrei.
      So ganz 100% trauen tue ich der Sache aber noch nicht.

      Auf der einen Seite reizt es mich da jetzt andere baustellen an zu gehen, aber ich halte die Füße erst mal still und gucke ob in den nächsten Stunden der Fehler doch wieder auftaucht.

      Ein solche andere Baustelle wäre z.B., habe ich bislang nicht erwähnt um das Thema hier nicht unnötig zu verkomplizieren:

      Die Tastenabfrage mache ich in der Hauptschleife mit einer gewöhnlichen If-Then-Unterscheidung und in der Sub dann eine Tastenentprellung mit waitms.
      Sieht doof aus, weiß ich...zumal da vor ein paar Tagen (Post 31) noch ein Config Debounce = 200 stand.

      Tja...das ist so wie es aktuell noch ist deshalb, weil ein Tastendruck der mit Debonce S2, 1, Lichtwechsel bei Tastendruck zuverlässig in einen µC-Reset führte.
      Dennoch irritiert mich noch die __READRAMPZ aus h0101 im SRAM zwischen meiner 1. und 2. Variable.

      Screen3.jpg

      Zumal der Begriff "READRAMPZ" weder in der Bascom.pdf noch im Datenblatt des ATmega1284 vorkommt.
      Das MCS-Forum kennt dort zwei Fundstellen:

      mcselec.com/index2.php?option=…59&page=viewtopic&p=74957
      mcselec.com/index2.php?option=…59&page=viewtopic&p=71790

      Und beide Fundstellen deuten für mich alarmierend darauf hin, das READRAMPZ etwas mit Zeichentabellen grafischer LCD's zu tun hat. Und das dürfte nach meinem Verständniss irgendwo im RAM-Adressbereich naje der LCD-Variablen besser aufgehoben sein, als am Anfang zwischen meine ersten beiden Variablen gequetscht.


      Realstatus bisher aktuell: 110 Minuten und LCD noch immer Fehlerfrei.


      Grüße


      Jürgen
    • RAMPZ solltest du in den Datenblättern aber finden.

      Ein Atmel-Controller hat 16 Bit zur Adressierung des Flash-Speichers. Deiner ist aber größer als 65536 Words. Damit man nun mehr Flash adressieren kann, braucht man noch ein paar Bits. Und die stecken in dem in dem RAMPZ. Das ist ein Register was die Controller mit mehr als 65536 Speicherzellen haben.

      Schau mal im Simulator die IO-Register an. Da findest du RAMPZ.

      Hat nichts mit LCD-Zeichentabellen zu tun.

      Und zu der Frage, warum an SRAM-Adresse $101 READRAMPZ steht, das kann dir nur der Programmierer des Compilers sagen. Denn der legt die Adressen für Variablen festgelegt.

      Aber egal ob READRAMPZ nun an Adresse $100 oder an der letzten Speicher-Adresse stehen würde. Fragen kämen immer auf. Warum das überhaupt eine Variable ist, kann dir auch nur der Programmierer des Compilers sagen.

      Ich kann nur vermuten, dass es eine Kopie ist vom Register RAMPZ ist, denn wenn das verstellt wird, dann kommt man in eine andere Page (65536 Words) vom Speicher. Irgendwie muss man ja zurück finden, wenn man in einer anderen Page Code ausführt. Das wurde vielleicht aus Kompatibilitäts-Gründen so gemacht. Denn würde man das Register auch auf dem Stack sichern, müsste man alle Libs umschreiben.

      Aber das ist nur eine Vermutung.

      RAMPZ hat also nix mit LCD zu tun, sondern mit Speicherverwaltung vom Flash-Speicher.
    • Hallo Mitch64!

      Vielen dank für die super Erklärung!
      Tatsächlich, suchte zuerst nach dem Variablennamen "READRAMPZ" und "__READRAMPZ" erfolglos.
      Unter "RAMPZ" wurde ich dann jetzt gerade im Datenblatt zum ATmega1284 fündig!

      Und das Display:
      Etwas über 3h Laufzeit und noch keinen einzigen Pixel Versatz. Sieht also erst mal gut aus.

      Sieht also so aus als ob das doch was mit der SRAM-Zuordnung zu tun hatte - also das sich die Clock-Variablen mitten zwischen den LCD-Variablen setzte.

      Dank dir habe ich einiges gelernt, beispielsweise das "Print" nicht zwingend mit Interrupts arbeitet, oder auch die sinvolle Verwendung einiger Informationen aus dem Simulator.

      Ich lass das Teil über Nacht durchlaufen und lasse mich morgen überraschen wie der LCD-Inhalt aussieht.
      Aber dieses mal habe ich da vorerst gute Hoffnungen.

      Grüße

      Jürgen