Ü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!

    • Disable Timer2 und
      Enable Timer2

      würden den selben Effekt bringen.
      Da wird ja nur der Sectic - Interrupt ein und ausgeschaltet.
      Das läuft aber die Uhr in der Zeit nicht.

      Die Standzeiten summieren sich und die Uhr ist recht schnell zu langsam (falsche Zeit)

      Aber ein Versuch Wert um den Sectic -Interrupt als Fehlerquelle zu identifizieren, falls das Problem noch besteht.
    • Hallo!

      Pluto25 schrieb:

      Gut wenns weiter so läuft. Falls nicht wäre ein Timsk2=0 vor dem Lcddat ein Versuch wert. Nach dem Lcddat's wieder zurückstellen ( Timsk2=1)
      Gut, den Timer2-Int ab zu würgen während der LCD-Ausgabe wäre auch eine Idee, falls dieser dazwischen rasseln sollte.
      Da gehe ich erst mal nicht von aus. Denn wie ich weiter oben bereits erwähnte:
      OFV2 kommt alle 1000ms, all meine Funktionen laufen aber in Bruchteilen davon durch, worst-Case 60ms.

      Allerdings hatte ich gestern eine Test-Konstellation die auf ein lahmes Timing am LCD offenbarte:
      Unmittelbar in der sekundlich durch die Sectic angesprungende Ausgabe-Sub vor den Lcdat-Befehlen ein CLS führte zu einem kaum lesbarem, flackernen LCD-Inhalt.

      Morgen habe ich vor mein Oszi an zu werfen um mir mal das Timing auf dem SPI genauer an zu schauen.
      Ursprünglich war geplant den SPI mit 2,7xMHz laufen zu lassen (Hardware-SPI).
      Bin morgen gespannt was ich da jetzt am Software-SPI erreiche.
      Sollte die SPI-CLK tatsächlich so drastisch tiefer sein, das eine LCD-Ausgabe >500ms liegt, werde ich Mitch64's Hinweis probieren den Hardware-ISP wieder mit 2,7MHz zu konfigurieren und die LCD-Befehle darauf um zu leiten.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Sollte die SPI-CLK tatsächlich so drastisch tiefer sein, das eine LCD-Ausgabe >500ms liegt, werde ich Mitch64's Hinweis probieren den Hardware-ISP wieder mit 2,7MHz zu konfigurieren und die LCD-Befehle darauf um zu leiten.
      Wenn du da auf $LcdPutData und $LcdPutCtrl anspielst, muss ich dir die Illusion gleich nehmen.
      Ich habe es im Simulator ausprobiert. Die eigenen Routinen werden nicht angesprungen.

      Also das geht so nicht. Das geht wohn nur mit Alphanumerischen Displays, aber nicht mit grafischen.

      In deinem Fall müsste man in die Lib direkt eingreifen, oder eine zusätzliche schreiben, die vor der Display-Lib geladen wird. Darin hätte man nun die Möglichkeit die Commandos umzuleiten.
      Ist aber ein ziemliches Unterfangen, wenn man sich die Display-Lib ansieht.

      Ist also nicht so einfach wie gedacht.

      Einfacher wäre, das Display über eigene Pins zu betreiben und SPI für den Rest als Hard-SPI zu nutzen.
    • Hallo!

      Mitch64 schrieb:

      Da wird ja nur der Sectic - Interrupt ein und ausgeschaltet.
      Das läuft aber die Uhr in der Zeit nicht.

      Die Standzeiten summieren sich und die Uhr ist recht schnell zu langsam (falsche Zeit)
      Ja, das wäre nicht schön, allerdings:
      Die Gefahr dabei währe zu verschmerzen.
      Nämlich dann wenn nur der OVF2 abgeschaltet werden würde, nicht aber der Timer2, insbesondere TCNT2 weiter zählen würde.

      Wenn allses so funktionieren würde wie geplant, wäre ich nämlich lange vor dem nächsten OFV2 fertig.

      Ausserdem soein weiterer Tischkantenbeißer:
      Der Repeater mit sammt Kleinst-Netzteil und DCF77-Modul in ein Steckergehäuse eingebaut, soll als Referenzuhr laufen.
      In jeder Minute zu Sekunde 0 sendet er diese Referenzzeit aus
      In den letzten Monaten im Testbetrieb zeigte sich jedoch das die Steckdose wo das Teil eingesteckt bleiben soll, der DCF-Empfang sehr instabil ist.
      Manchmal synchronisiert das Teil fast alle 1-3 Minuten über mehrere Wochen perfekt auf DCF, dann aber auch phasen wo 1-50h keine einzige RTC-Synchronisierung möglich ist.
      Trotz damaliger intensiver Auseinandersetzung mit der Bascom DCF77.lib sowie versuchen mit anderen Libs, kam ich immer wieder zur Erkentniss das diese Libs nicht kompatibel sind mit einer asynchronen 32,768kHz Clock.
      So blieb nur eines:
      Testläufe über fast 2 Monate zur korrektur der 8MHz Quarzdrift.
      Führt aber noch immer zu Abweichungen von ca. +- 2 Sekunden in 24h ohne DCF-Synchronisierung.

      Wenn das so weiter geht muss ich da an den Referenzuhr-Repeater noch mal ran.
      Entweder den I²C anzapfen und da ein DS3231-Breakout-Board dranfriemeln, oder ein GPS-Modul am RxD der Serviceschnittstelle stricken.

      Eine exakte Zeit ist unabdingbar, weil das ganze System in Zeitschlitzen arbeitet die maximal 3Sek. lang sind.
      Und es ist frustig das Terminal und alle Sensoren mit 32kHz-RTC regelmässig um Dimensionen genauer laufen als meine "Referenzuhr".

      Grüße

      Jürgen
    • Da gibt es doch diese alternative dcf-lib, die mit jedem timer arbeiten. Die brauchen halt einen Aufruf alle 25ms. Das kann man aber auch bisschen variieren. So einen Aufruf könntest du doch auch mit dem asynchronen timer2 hinbasteln und deinen Sekundentick durch ein Aufsummieren des dcf-aufrufs machen.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • Ist denn der Fehler überhaupt noch da mit dem kryptischen Display?
      Weil wenns läuft ist erst mal gut.

      Interrupt ist interrupt, egal wo der her kommt. Sie funken immer rein, wenn man es nicht richtig macht.

      Ich denke aber dass das Problem mit dem Sectic zusammen-hing.

      Aber mal abwarten, was @DG7GJ berichtet. Er ist ja gerade Online.
      Vielleicht gibt er kurz ein aktuelles Statement ab.
    • Hallo!

      Pluto25 schrieb:

      Jedoch nicht synchronisiert wodurch die sich sicher treffen. Den Int zu verzögern würde keine Auswirkungen auf die Zeit haben.PS waitms 100 ist weniger wie 60ms ;)
      Die Lcdat-Ausgaben sind Quasi-Synchron immer wenige µs nach den OFV2-INT, weil da durch (in der Sectic) aufgerufen.
      Also:
      INT OFV2 springt die Sectic an.
      Dort wird Variable LCDtime auf 1 gesetzt.
      Zurück in der Hauptschlefe wird diese ausgewertet:

      If LCDtime = 1 then Gosub LCDtimeout.

      LCDtimeout ist die Sub, welche das komplette LCD beschreibt.
      Die heißt nur so, weil ursprünglich gedacht nur die oberste Zeile (Datum & Uhrzeit) zu aktualsisieren.

      Diese Sub wird also ausschließlich durch den OFV2 getriggert ohne das da hunderte ms zwischen liegen.

      Und die diversen "watms 50" und "waitms 100" sind da nur testweise drin aufgrund der Ursachenforschung.
      Diese kommen, sollte das problem behoben sein, direkt wieder raus.

      Mitch64 schrieb:

      Wenn du da auf $LcdPutData und $LcdPutCtrl anspielst, muss ich dir die Illusion gleich nehmen.Ich habe es im Simulator ausprobiert. Die eigenen Routinen werden nicht angesprungen.

      Also das geht so nicht. Das geht wohn nur mit Alphanumerischen Displays, aber nicht mit grafischen.

      Autsch, währe auch zu einfach gewesen.
      Na egal, morgen hole ich mir ein DSO von meiner Funkwerkstatt rüber und schaue mal ob der Speed hinnehmbar ist.

      Mitch64 schrieb:

      Einfacher wäre, das Display über eigene Pins zu betreiben und SPI für den Rest als Hard-SPI zu nutzen.

      Tja, was dann auf ein Redesign hinauslaufen würde.

      Na erst mal abwarten was morgen das DSO sagt.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Autsch, währe auch zu einfach gewesen.
      Na egal, morgen hole ich mir ein DSO von meiner Funkwerkstatt rüber und schaue mal ob der Speed hinnehmbar ist.
      Wenns nicht reicht hab ich vielleicht eine Lösung.
      Ich weiß jetzt wo ich in der Lib den Hebenansetzen müsste, damit die Per Hardware-SPI Daten schickt.
      Dazu bräuchte ich dann aber noch ein paar Infos. Und keine Garantie. Wäre dann ein Versuch mit guten Chancen.

      Aber erst wenns so weit ist.

      Das Problem mit dem zerhackten Display muss aber vorher beseitigt sein. Denn Das Display auch auf Hardware-SPI zu legen behebt das Problem nicht. Das sind 2 getrennte Dinge.

      So

      jetzt wäre aber ein Statement schön, ob das mit dem Display jetzt funktioniert. Das läuft ja jetzt schon ne weile?
    • Hallo!

      Mitch64 schrieb:

      Ist denn der Fehler überhaupt noch da mit dem kryptischen Display?
      Weil wenns läuft ist erst mal gut.

      Interrupt ist interrupt, egal wo der her kommt. Sie funken immer rein, wenn man es nicht richtig macht.

      Ich denke aber dass das Problem mit dem Sectic zusammen-hing.

      Aber mal abwarten, was @DG7GJ berichtet. Er ist ja gerade Online.
      Vielleicht gibt er kurz ein aktuelles Statement ab.

      Jawoll, die Displayanzeige ist nun reproduzierbar sauber.
      Obwohl es so aussieht als ob die Clock-Variablen sich nur zwischen die GLCD-Variablen ins RAM gequetscht haben, ohne irgendwas zu überschreiben (habe gestern die Bytes der einzelnen Variablen durchgezählt), scheint die ursache tatsächlich in der fragmentierten LCD-Variablenliste zu liegen.
      Offensichtlich wollte die Lib gelegentlich auf den LCDCOUNTER zugreifen und hat dabei die Adresse des Timestamps erwischt.
      Was ebenso erklärt warum die Zeitabstände bis das Display fehlerhaft wurde, zeitlich relativ reproduzierbar war.

      Mitch64 schrieb:

      DG7GJ schrieb:

      Autsch, währe auch zu einfach gewesen.
      Na egal, morgen hole ich mir ein DSO von meiner Funkwerkstatt rüber und schaue mal ob der Speed hinnehmbar ist.
      Wenns nicht reicht hab ich vielleicht eine Lösung.Ich weiß jetzt wo ich in der Lib den Hebenansetzen müsste, damit die Per Hardware-SPI Daten schickt.
      Dazu bräuchte ich dann aber noch ein paar Infos. Und keine Garantie. Wäre dann ein Versuch mit guten Chancen.

      Aber erst wenns so weit ist.

      Das Problem mit dem zerhackten Display muss aber vorher beseitigt sein. Denn Das Display auch auf Hardware-SPI zu legen behebt das Problem nicht. Das sind 2 getrennte Dinge.

      So

      jetzt wäre aber ein Statement schön, ob das mit dem Display jetzt funktioniert. Das läuft ja jetzt schon ne weile?

      Ja, also bezüglich LCD-Fehler bin ich äusserst zuversichtlich. Etwas Kopfzerbrechen machten mir eine Reihe von "resetartigen" Situationen die laut UART-Log ab letzte nacht auftraten.
      Dummer weise habe ich im Programm bislang nicht vorgesehen bei Neustart den MCUSR zu drucken.
      Ich vermute aber das es ein Wackelkontakt gewesen sein könnte:
      Hatte gestern Mittag beim Start des Testlaufes noch gleich testen wollen warum die Akkuspannung so schnell sinkt, viel schneller als geplant, und und im Ergebnis der Laderegler die zwei 18650 maximal bis 4,11V laden konnte.
      Daher gestern die Schmelzsicherung entnommen und via Krokodilklemmen ein DMM als Ampermeter dazwischen gehangen.

      Damit habe ich dann schnell gesehen, was ich im Quelltext immer wieder übersah:
      Der ESP hat zwar korrekter weise seine Sleep-Anweisung bekommen, zog aber dennoch seine 200-500mA.
      Erst durch diese Erkentniss sag ich das eine Zeile unter Print #1, "AT+SLEEP=2" ein
      Print "Sende AT+SLEEP=2" stand der eigentlich ins UART-Log sollte...da fehlte ein verflixtes #2

      Eigentlich - anständige 4mm-Meßstrippen mit 1,5m² und professionelle Meßklemmen.
      Aber da kann durchaus was an Wackelkontakt in den Nachtstunden passiert sein.

      Jedoch ein komischer Reset:
      Ich sehe im UART-Log deutlisch das das Programm mehrfach neu gestartet ist, jedes mal die komplette RFM69-Initialisation durchlaufen.
      Allerdings hat er nichtmal bei der Hälfte (eher nur bei gefühlten 30%) der Neustarts auch den RTC-Stand vergessen.
      Gefühlte 70% der Resets hingegen ist die RTC beim letzten, aktuellen Wert einfach weiter gelaufen *grübel*.

      So jetzt baue ich mir gleich mal das Oszi auf um das Timing mal inspizieren zu können.

      Grüße

      Jürgen
    • Hallo Mitch64!

      Mitch64 schrieb:

      Deine Schaltung läuft doch mit 3V wenn ich das noch richtig weiß
      Hast du mal die Fusebits Controlliert, nicht dass der Brown Out zu hoch eingestellt ist und ein Reset auslöst.
      Selbstverfreilich nicht...:-)
      BrounOut in den Fuses ist auf 1,80V eingestellt, da dieser möglichst niemals im Normalbetrieb auslösen soll.
      Den zuverlässige Reset bei Unterspannung legt ein externer STM1061 fest auf 2,50V.

      Energiekonzept mal etwas ausführlicher:
      Das Terminal soll tragbar sein, hat aber diverse Periferie die bei Verwendung nicht wirklich "battery-like" sind.
      Da ist der RFM69HW der mit bis zu 120mA sendet (bei schlechter Verbindung auf +20dBm) noch harmlos.
      Der ESP zieht laut Specifikation bis zu 500mA @ 3,3V.
      Daher bekommt das Terminal keine 600mAh LiPo-Säckchen, sonder trägt zwei fette 18650-Sockel - soll ja nicht permenent am Ladegerät angeleint sein.

      Aus den 3,0-4,20V der beiden parallelen 18650 wird (freilich über eine Sicherung) ein SC4626Z versorgt der mit hoher Effizient die nötigen 10-800mA ohne nennenswerte Lasteinbrüche auf Vcc=3,3V max regelt.
      Als spezieller PFM-PWM für Akkubetrieb bricht er nicht zusammen wenn die Akkuspannung unter Vcc fällt. sondern schaltet dann einfach auf 100%PWM.
      Vcc liegt also regulär zwischen 3,0-3,3V.

      Geladen wird der Akku (im Regelbetrieb 2x 3500mAh) über einen erstaunlich fleißigen und robusten MCP73811 in SOT23-5 über ein 5V USB-Steckernetzteil.
      Bei nicht ganz leeren Akkus (aktuell zum Test 2x2200=4400mAh) auf knapp 3,1V braucht der MCP73811 rund eine Nacht (8-10h).

      So, nun aber meine DSO-Ergebnisse.
      Immer wieder nervig das serielle Busse verflixt schwierig zu triggern sind.

      Die SPI-Clock bekomme ich nicht sauber getriggert und dem augenscheinlich stabilstem Bild traue ich nicht wirklich.

      Deutlich aussagekräftiger sind da die /CS-Timings

      Am /CS des LCD sah ich das der komplette Verkehr zum LCD für alle Ausgaben zwischen 19,5ms und 23,4ms lang dauert.
      Woher exakt die Differenz von fast 4ms kommt weis ich nicht, denn nach meinem Verständniss wird jede Sekunde ziemlich genau die selbe Datenmenge an das LCD gesendet.
      Gut, habe bemerkt das der von mir verwendete Font8x8TT als Besonderheit offenbar keine feste Zeichenbreite hat (8x8).
      Vielmehr sehe ich z.B. in der obersten Zeitzeile das das Zeilenende nach vorne rückt wenn davor schmalere Zeichen sitzen:
      Verdeutlicht...: Bei
      11:11:11 habe ich rechts noch locker Platz für gut 2 ASCII-Zeichen, gute 20 Pixel.
      Bei 20:34.56 sitzt das letzte aktive Pixel auf der vorletzten Spalte.
      Mag sein das dort die 4ms Differenz her rühren.
      Wie viele bytes da insgesamt an Daten und Steuerbefehlen zum LCD geschickt werden kann ich hingegen nicht erkennen.

      Am /CS vom RFM69HW sah ich das die Auslesung der aktuell 66Bytes (FIFO) ca. 860µs dauert.
      Das ist definitiv aussagekräftiger, weil ich hier genau weis das exakt 66Bytes aus dem FIFO gelesen werden.
      Ein Byte kann dann höchstens 860µs / 66 = 13µs und jedes Bit /8 = 1,625µs was dann rechnerisch einer SCK von 615,384kHz entsprechen müsste.

      Im jetzigem Entwicklungsstadium reicht mir das, weil ich froh bin das ich nun eine stabile und klare LCD-Anzeige habe.
      Spätestens für das AVR-DOS mit der SDHC wäre das knapp.

      Wie aufwändig wären denn die Änderungen an der glcdEADOGM128x6.lib um sie auf den Hardware-SPI um zu stricken?
      Habe mir diese Lib schon mehrfach angeschaut, aber meine ASM-Kentnisse stehen da nur minnimal oberhalb von 0..:-)

      Ansonsten wäre ich dazu geneigt meine Erwartungen bei diesem Modell runter zu schrauben und das irgendwann mal auf eine Neuentwicklung zu verschieben.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Am /CS des LCD sah ich das der komplette Verkehr zum LCD für alle Ausgaben zwischen 19,5ms und 23,4ms lang dauert.
      Woher exakt die Differenz von fast 4ms kommt weis ich nicht
      In einem vorausgegangenen Post war die maximale Dauer für die Ausgabe mit 500ms limitiert. Länger dürfte die Ausgabe nicht dauern. So deine Worte.
      Jetzt haben wir zwischen ca. 19ms und 24ms. Sollte doch ausreichen. Warum das jetzt mit AVR-DOS und SD-Card länger werden soll musst du mir mal erklären.

      Übrigens ist das Software-SPI. Deine Routine macht auch noch Formatierungen von Werten etc. Je nach Ablauf des Code-Pfad kann es unterschiedlich dauern. Und da ist ja noch der Interrupt, der auf für Verzögerungen sorgen kann.

      Wenn du SD-Card auch noch am SPI betreiben willst, könnte es noch Probleme geben. Des weiteren macht dein Programm sporadisch einen Reset.
      Du solltest erst mal bekannte Fehler weg bekommen, bevor man weitere Baustellen auf macht.
      Der Umbau der Lib dauert dann nicht so lange. Aber ich bräuchte dann noch Infos.

      Erst mal Reset-Problem beseitigen und dann hänge die SD-Card mal noch dran mit AVR-DOS.
      Wenn das stabil läuft, können wir einen Schritt weiter gehen.

      Wenn ich noch einen Empfehlung geben darf.
      Ich kenne jetzt nur den Code von der LCD_Test1. Für meine Begriffe ist der Code nicht aufgeräumt. Variablen sind unbenutzt.
      Und wie mir auffällt, verwendest du keine Sub und Funktionen. Die würden mehr Komfort in die Software bringen und die Lesbarkeit steigern. Auch Strukturiertes (Einrücken) verbessert die Lesbarkeit. Dafür hat Bascom übrigens ein nettes Feature. Rechtsklick ins Code-Fenster und "Proper Indent" auswählen.

      Wenn du weitere Tips haben möchtest gerne. Ich möchte dir ja nicht vorschreiben wie du deinen Code schreibst. Aber es hilft, den Code auch selber zu verstehen, wenn man ihn mal ein Jahr nicht gesehen hat und Änderungen machen möchte.
    • Hallo tschoeatsch!

      tschoeatsch schrieb:

      Da gibt es doch diese alternative dcf-lib, die mit jedem timer arbeiten. Die brauchen halt einen Aufruf alle 25ms. Das kann man aber auch bisschen variieren. So einen Aufruf könntest du doch auch mit dem asynchronen timer2 hinbasteln und deinen Sekundentick durch ein Aufsummieren des dcf-aufrufs machen.
      Du meinst warscheinlich die Lib die im Web unter anderem bei roboter-Netz.de oder so ähnlich kursiert?
      Genau diese meine ich mit der "anderen DCF-Lib" mit der ich damals rumexperimentierte.
      Damit hatte ich noch mehr Probleme weil ich die gar nicht wirklich zum laufen brachte.

      Ist zwischenzeitlich aber kein Ärgerniss mehr für mich was beim Thema DCF77 bei mir überwiegt.
      Deutlich schwerer liegt mir im Magen das die erhältlichen DCF-Module, namentlich das DCF-1 von Pollin oder auch das DCF-2 von ELV nicht wirklich taugen.

      Im direkten Vergleich erscheint zwar das DCF-2 von ELV etwas empfindlicher zu sein als das Pollin-Modul, aber beide sind für mich eher eine minderwertige Notlösung die ich ohne Akute Not am liebten nie wieder verbauen werde.

      Dieses vernichtende Urteil liegt einfach daran das ich hier etliche komerzielle DCF77-Uhren rumstehen habe, die zum Teil schon über 30 Jahre alt sind.
      Selbst die aller erste DCF77 Armbanduhr die ich mir als Teenager kaufte, steht heute ohne Gehäuse auf einem alten LiPo-Handyakku geklebt und läuft immernoch, egal wo sie steht oder wie sie mit ihrer Winz-Antenne ausgerichtet ist, sie synchronisiert zuverlässig und sicher.

      Meine zweite oder dritte Armbanduhr (die Plastik-Armbänder haben nie lange gehalten) hängt seit Jahren an meinem Monitor dicht über der USB-Tastatur geklebt an zwei Mignonzellen. Deren permanente ausrichtung ist sogar knapp 90° von der Optimalausrichtung für DCF77 verdreht. Dennoch, auch trotz des erheblichen Störnebels tut sie tagtäglich und absolut genau.

      Die DCF-1/2 Module haben dagegen eine um ein vielfaches größere Antenne = mehr wirkfläche, höhere Güte, höhere Empfindlichkeit, dennoch sind sie deutlich empfangsschwächer als alle Billig-Funkuhren die hier rumstehen.

      Von daher habe ich mir mal eine DCF77 Experimentierschaltung entworfen wo ich mir bei meiner nächsten Platinenbestellung mal welche mitbestellen will.
      Gucken was als Vorverstärker hinter soeine Ferritantenne besser taugt...DG-FET, JFET oder doch eher ein Instrumenten-OP.
      Dahinter dann mit vielen Testpunkten dazwischen eigener Empfänger und komplett eigene Auswertung.
      Gucken wo da kritische Punkte sind und wie man sowas besser machen kann die diese heutigen Fertigmodule.

      Grüße

      Jürgen
      Dateien
      • DSCF5269_M.jpg

        (151,08 kB, 15 mal heruntergeladen, zuletzt: )
      • DSCF5270_M.jpg

        (174,1 kB, 16 mal heruntergeladen, zuletzt: )
    • Hallo Mitch64!

      Mitch64 schrieb:

      DG7GJ schrieb:

      Am /CS des LCD sah ich das der komplette Verkehr zum LCD für alle Ausgaben zwischen 19,5ms und 23,4ms lang dauert.
      Woher exakt die Differenz von fast 4ms kommt weis ich nicht
      In einem vorausgegangenen Post war die maximale Dauer für die Ausgabe mit 500ms limitiert. Länger dürfte die Ausgabe nicht dauern. So deine Worte.Jetzt haben wir zwischen ca. 19ms und 24ms. Sollte doch ausreichen. Warum das jetzt mit AVR-DOS und SD-Card länger werden soll musst du mir mal erklären.

      Am liebsten hätte ich in diesem Teil alles so "flott wie möglich":
      Das Nadelöhr wird nicht bei AVR-DOS bzw. dem Download zum ESP sein.
      Wenn der Soft-SPI mit einer Clock von 615kHz die Files von der SD-Karte lädt reicht das, denn wia UART0 geht es dann eh mit "nur" 115200Bd zum ESP und häppchenweise dann ins Netzwerk.

      Etwas mehr Bedenken habe ich mit der Rechenzeit für die grafische Ausgabe im zweiten LCD demnächst.
      Da das EADOGM ja fest in Zeilen eingeteilt sind, kann ich die Sensorkanäle ja nicht einfach mit 128x PSET x , y , 1 setzen, sondern muss jeden einzelnen Wert überhaupt erstmal bemessen in welcher Zeile der Wert skaliert werden muss.
      Und jede dieser aufwendig berechneten Diagramme müssen dann für das komplette LCD 8x128=1024Bytes rein geschossen werden.
      Wenn das direkt (ohne die Lib, die kann das eh nicht) über den Soft-SPI genau so schnell geht wie mit dem RFM-FIFO, also 13µs je byte, läge ich dann für ein komplettes XY-Diagramm bei knapp 13,3ms.
      Hmm, sieht dennoch gar nicht so schlecht aus im Vergleich zur Lib.

      Mitch64 schrieb:


      Wenn du SD-Card auch noch am SPI betreiben willst, könnte es noch Probleme geben. Des weiteren macht dein Programm sporadisch einen Reset.
      Du solltest erst mal bekannte Fehler weg bekommen, bevor man weitere Baustellen auf macht.
      Der Umbau der Lib dauert dann nicht so lange. Aber ich bräuchte dann noch Infos.

      Erst mal Reset-Problem beseitigen und dann hänge die SD-Card mal noch dran mit AVR-DOS.
      Wenn das stabil läuft, können wir einen Schritt weiter gehen.

      Das mit diesen zahlreichen Resets kann nur ein Wackelkontakt am Amperemeter gewesen sein.
      Seit dem ich heute mittag die Meßstrippen entfernt und die 5x20-Feinsicherung wieder in den Sicherungshalter gedrückt habe, gab es bislang keinen einzigen Reset mehr.

      Dennoch sind da erst noch andere Baustellen.
      Da wäre die merkwürdig abgeschmierte AGC des RFM, die nochmalige Restbestückung mit zweitem LCD usw.
      Und jawoll, die Themen AVR-DOS und ESP sind auch noch offene Baustellen.

      Mitch64 schrieb:


      Wenn ich noch einen Empfehlung geben darf.
      Ich kenne jetzt nur den Code von der LCD_Test1. Für meine Begriffe ist der Code nicht aufgeräumt. Variablen sind unbenutzt.
      Und wie mir auffällt, verwendest du keine Sub und Funktionen. Die würden mehr Komfort in die Software bringen und die Lesbarkeit steigern. Auch Strukturiertes (Einrücken) verbessert die Lesbarkeit. Dafür hat Bascom übrigens ein nettes Feature. Rechtsklick ins Code-Fenster und "Proper Indent" auswählen.
      Wenn du weitere Tips haben möchtest gerne. Ich möchte dir ja nicht vorschreiben wie du deinen Code schreibst. Aber es hilft, den Code auch selber zu verstehen, wenn man ihn mal ein Jahr nicht gesehen hat und Änderungen machen möchte.

      Ja, neulich hatte ich ja vor ein komplett neues Projekt in aufgeräumt zu erstellen.
      Als ich dann auf die Idee kam Config GraphLCD und Config Clock zu vertauschen, war die Idee gestorben.
      Ist immer noch weitgehend die selbe LCD_Test1 an der ich rumdoktere.

      Was die Übersichtlichkeit meiner Quelltexte angeht:
      Erstmals habe ich bei diesem Projekt angefangen zahlreiche Labels in eigene Dateien auszulagern und nur zu inkludieren.

      Mein Hauptproblem der Übersichtlichkeit war nämlich das ich immer weniger den Überblick behalten konnte weil ich permanent nur noch am scrollen und suchen war.
      Auf der anderen Seite bot sich die Auslagerung in Einzeldateien (zuerst mehrere *.bas, nun in ordentlichen Projekten verpackte *.inc) an, weil über alle Gerätearten dieses Projektes (Terminal, Repeater und mehrere Sensoren) einzelne Dateien schlichtweg die selben oder zumindest stark ähnliche sind. Sensoren-Steuerung, RFM-Initialisation, RFM-Pakethandling usw.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Mein Hauptproblem der Übersichtlichkeit war nämlich das ich immer weniger den Überblick behalten konnte weil ich permanent nur noch am scrollen und suchen war.
      Das ist doch ein Stichwort.

      Wenn ich größere Projekte mache, kann man die meist in verschiedene Hauptbereiche aufteilen.
      In Deinem Fall ist ein Bereich z.B. das RFM-Modul. Also der Repeater als Beispiel. das kann man in ein Modul packen und austesten. Funktioniert das, ist das Modul (Include-Datei) praktisch abgehakt und man kümmert sich um den nächten Teil. So könnte das Projekt in Module aufgeteilt werden.

      Im Hauptprogramm braucht man eigentlich nur die Module includieren und und die Verknüpfungen realisieren. Also die Steuerung des ganzen realisieren.

      Bei deiner Steuerung hast du als Beispiel eine variable benutzt um ein Flag zu setzen. Sectic als Beispiel.
      Im Hauptprogramm fragst du die Variable ab und rufst die Routine auf, danach Flag löschen.

      Dann hast du eine 2. Variable für ein anderes >Flag, was eine Aktion auslost.
      Warum nicht die ganzen Variablen in eine packen? Und die Variable ControlFlags nennen?
      Den die Flags kontrollieren je eine Aktion.

      Den Rest kannst du beispielsweise direkt abfragen wie den Empfang an den RFM-Modulen und dann drauf reagieren..

      Ich persönlich schwöre auf eine Statemachine. Klingt vielleicht nach Eigenwerbung, weil ich im Lexikon ein Tutorial darüber geschrieben habe. Aber gerade bei größeren und komplexeren Projekten wie deins eins zu werden scheint, lohnt sich die Überlegung. Denn dadurch bleibt der Code übersichtlich und Strukturiert.
      Die ganze Steuerung kann tabellarisch dokumentiert werden, da findet man sich dann schnell wieder rein.
      Die Statemachine ist zudem extrem flexibel um nachträglich Erweiterungen (Funktionsumfach) einzufügen.

      Das alles führt zu einer übersichtlichen Struktur und macht den Code auch für einen selbst sehr gut wartbar.

      Auch Variablen können in ein Modul verlagert werden. Damit ist in dem Hauptprogramm der wesentliche Programmablauf deutlich schneller erkennbar und scrollt sich nicht zu Tode.

      Das sind so ein paar Tips von meiner Seite.
      Wie gesagt gut gemeinte Anmerkungen, kein muss. Ich kanns nur empfehlen.

      Das bezieht sich im übrigen nicht nur auf dein Projekt, sondern kann allgemein auf jeden Code angewendet werden.

      In dem Zusammenhang bin ich auch gerne bereit Rede und Antwort zu stehen. Dafür aber bitte dann ein neues Thema eröffnen. Ich wollte es hier nur mal los werden.
    • Hallo Mitch64!

      Mitch64 schrieb:


      DG7GJ schrieb:

      Mein Hauptproblem der Übersichtlichkeit war nämlich das ich immer weniger den Überblick behalten konnte weil ich permanent nur noch am scrollen und suchen war.
      Das ist doch ein Stichwort.
      Wenn ich größere Projekte mache, kann man die meist in verschiedene Hauptbereiche aufteilen.
      In Deinem Fall ist ein Bereich z.B. das RFM-Modul. Also der Repeater als Beispiel. das kann man in ein Modul packen und austesten. Funktioniert das, ist das Modul (Include-Datei) praktisch abgehakt und man kümmert sich um den nächten Teil. So könnte das Projekt in Module aufgeteilt werden.

      Im Hauptprogramm braucht man eigentlich nur die Module includieren und und die Verknüpfungen realisieren. Also die Steuerung des ganzen realisieren.

      Genau das fing ich bei diesem Projekt auch in der Mitte an. Eben weil irgendwo im vierstelligen Zeilenbereich die Übersichtlichkeit nicht mehr beherrschbar war.
      Zumal bei aufkommenden Problemen dann mittendrinn an zig Stellen Lösungsansätze eingefügt und wieder auskommentiert wurden, die nur un den seltensten Fällen mit 3 neuen Zeilen sondern mit bis zu hunderten aufwarteten.

      Deine Tips wie man in Bascom vernüftige Projektdateien erstellt hat mich da um einiges weiter gebracht.

      Mitch64 schrieb:

      Bei deiner Steuerung hast du als Beispiel eine variable benutzt um ein Flag zu setzen. Sectic als Beispiel.Im Hauptprogramm fragst du die Variable ab und rufst die Routine auf, danach Flag löschen.
      Dann hast du eine 2. Variable für ein anderes >Flag, was eine Aktion auslost.
      Warum nicht die ganzen Variablen in eine packen? Und die Variable ControlFlags nennen?
      Den die Flags kontrollieren je eine Aktion.
      Kann man selbstverständlich, was sicherlich Platz im SRAM spart.
      Ob man nun eine typisch digitale Zustandbeschreibung "wahr" oder "unwahr" in einem Byte speichert, oder acht soler Entscheidung in den 8Bit eines Bytes zusammenpackt macht diesbezüglich einen Unterschied.

      Dort liegt aber, speziell in der Try&Error-Entwicklung solcher Projekte kein Schwerpunkt.
      Wie du ja schon an meinen vorgegebenen Stackwerten gesehen hast versuche ich mir Speicherplatzprobleme in diesem Stadium erstmal weg zu schieben. Lieber Chips mit mehr als reichlich RAM nehmen um sich in der Entwicklung austoben zu können.

      Klar gibt es bei dem einen oder anderem Projekt von mir durchaus Nachoptimierungsmöglichkeiten.
      Funktioniert etwas erst mal kommen dann schon Überlegungen wie:
      Welcher µC kleiner, preiswerter, Energiesparsamer wäre angemessen.

      Davon ab, nachdem das Thema hier ziemlich OT wurde nur noch von mir die abschließende Statusansage:

      Die Ansteuerung des EADOGM128x64 läuft bis heute nun schon deutlich über 48h stabil ohne Probleme.
      Im Laufe der verschiedenen Versuche fand ich auch eine ziemlich spezielle Eigenart dieses LCD's herraus die ich bislang bei Textdisplays nie hatte:

      Das Grafik-RAM des EADOGM128x64 ist äusserst Beständig.
      Resettet der µC nach kurzer Vcc-Unterbrechung neu, erscheint automatisch der letzte LCD-Inhalt.
      Dieser wird auch durch die LCD-Initialisierung nicht gelöscht.
      Selbst mehrere Sekunden Spannungslosigkeit bekommt das Grafik-RAM nicht zuverlässig gelöscht.
      Erst nach einem CLS hört der Spuk auf.

      Und die merkwürdig unwillige AGC des RFM69HW habe ich auch gebändigt.
      Die RSSI-Werte (immer zwischen -71 und -79dBm egal ob der Sender wenige cm oder mehrere Meter und zwei Betonwänden entfernt war) sind vor wenigen Tagen urplötzlich aufgetreten, obwohl an den Registerwerten nichts verändert wurde.

      Der Fehler lag nicht an der eigentlichen AGC (Register h18) sondern an der DAGC (Register h6F):
      Defaultwert nach Neustart eines RFM69HW für DAGC-Register h6F ist h00 = DAGC deaktiviert.
      Laut Datenblätter zum RFM69HW sowie zum verwendeten SX1231h sagt das eine aktivierung "recommened" ist.
      In meinem Fall mit dem Registerinhalt h20.
      Hat in den erste Tagen auch nachvollziehbar und realistisch funktioniert.
      Nun aber musste ich die DAGC abwürgen (h00) um wieder nachvollziehbare Empfangsqualitäten zu erreichen:

      Quellcode

      1. 18:26:16 MESZ Sa 24.08.19 A1 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 F6 RSSI: -4.5dBm
      2. 18:26:16 MESZ Sa 24.08.19 Status: 5C FF E4 FF E5 02 09 00 07 D9 66 FEI: -1.71kHz AFC: -1.71kHz
      3. 18:27:00 MESZ Sa 24.08.19 A0 13 A8 98 12 1B 13 11 6C 48 00 61 CB 50 1D 00 03 20 00 5F 00 00 00 00 8C RSSI: -42.5dBm
      4. 18:27:00 MESZ Sa 24.08.19 Status: 5C 00 14 00 14 02 55 00 07 D9 66 FEI: 1.22kHz AFC: 1.22kHz
      5. 18:27:16 MESZ Sa 24.08.19 A1 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 F6 RSSI: -5.5dBm
      6. 18:27:16 MESZ Sa 24.08.19 Status: 5C FF E4 FF E5 02 0B 00 07 D9 66 FEI: -1.71kHz AFC: -1.71kHz
      7. 18:28:00 MESZ Sa 24.08.19 A0 13 A8 98 12 1C 13 82 6B A8 00 61 CE A0 1C A0 03 21 00 5F 00 00 00 00 53 RSSI: -43.5dBm
      Der Repeater (erstes Byte = hA0) mit seinen ca. -43dBm steht aktuell 10m entfernt mit einer Betonwand dazwischen.
      Der Sensor1 (erstes Byte = hA1) mit seinen -5dBm liegt gerade direkt neben dem Terminal zwecks Akkuladung.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Das Grafik-RAM des EADOGM128x64 ist äusserst Beständig.
      Resettet der µC nach kurzer Vcc-Unterbrechung neu, erscheint automatisch der letzte LCD-Inhalt.
      Dieser wird auch durch die LCD-Initialisierung nicht gelöscht.
      Ich denke dann hatte das Display wohl noch von irgend woher Spannung. Vielleicht vom Programmier-Adapter. Keine Ahnung. Aber wenn nur der Controller Resettet hat das ja auch erst mal nicht unbedingt was mit dem Display-Reset zu tun. Das hat doch sein eigenen Reset. korrekt?

      Wenn der Controller resettet, macht man normal auch an der Peripherie ein Reset, zumindest wenn das am Controller angehängt ist. Oder beim Starten vom Controller den RST-Pin vom Display mal auf Low ziehen.

      Mit deinen RFM-Modulen kenne ich mich gar nicht aus. Da kann ich dir zu AGC, Konfiguration und sonstigen Dingen nicht helfen.

      Nachdem dann ja erst mal alles läuft, wie machst du weiter?
      SD-Card und AVR-Dos anhängen? Oder was ist deine nächste Baustelle.
    • Hallo Mitch64!

      Mitch64 schrieb:

      Ich denke dann hatte das Display wohl noch von irgend woher Spannung. Vielleicht vom Programmier-Adapter. Keine Ahnung. Aber wenn nur der Controller Resettet hat das ja auch erst mal nicht unbedingt was mit dem Display-Reset zu tun. Das hat doch sein eigenen Reset. korrekt?
      Wenn der Controller resettet, macht man normal auch an der Peripherie ein Reset, zumindest wenn das am Controller angehängt ist. Oder beim Starten vom Controller den RST-Pin vom Display mal auf Low ziehen.

      Mit deinen RFM-Modulen kenne ich mich gar nicht aus. Da kann ich dir zu AGC, Konfiguration und sonstigen Dingen nicht helfen.

      Nachdem dann ja erst mal alles läuft, wie machst du weiter?
      SD-Card und AVR-Dos anhängen? Oder was ist deine nächste Baustelle.

      Nunja, der /Reset des LCD's liegt an PortA.7 und ist so auch mit in der Config Graphlcd mit eingetragen.
      Ob dieser bei Initlcd betätigt wird oder nicht weis ich nicht, manuell mache ich da nichts.

      Und woanders eine Vcc kann er nicht bekommen. Zwar habe fünf Stüzkondensatoren zu je 10µF am Vcc = 50µF, aber da bleibt keine nennenswerte Restspannung für diese Zeit stehen.

      Was die Erfahrungen bezüglich RFM angehen habe ich ja in den letzten 1,5-2Wochen hier schon an verschiedenen Stellen im Forum gesagt. Diese Teile haben so viele Eigenarten und Besonderheiten das die üblichen Datenblätter zum RFM-Modul sowie zum verwendeten Chip bei weitem nicht reichten um damit einfachste Sachen zu machen.
      Im Gegenteil produzieren diese Datenblätter noch eine, bis auf wenige Register, Einfachheit, das man das Teil für "einfach beherrschbar" hält.
      Da musste ich erst ein paar Monate weite Teile meiner Freizeit reinwerfen und dabei auch einige Module "abschießen" um zu begreifen welche "Designfehler" da drin stechen und wie man diese behandeln und berücksichtigen muss.

      Kleine Andektode eines dieser Designfehler:
      Fällt beim Senden (45mA bei Standardleistung, rund 140mA bei Maximalleistung) die Spannung, senden die Teile im Dauerbetrieb. Kann ein µC den RFM nicht mehr resetten, weil er entweder gerade im Reset-Zustand ist, oder aber kein ausreichend hohen High-Pegel mehr erreichen kann um mit dem RFM zu reden, verharrt der RFM im Sendemodus bis die Batterie komplett leer ist.
      Warum das ein Designfehler ist?
      Nun, wenn man schon keine Sendezeitbegrenzung im Modul vorgesehen hatt, bliebe ja noch der Reset.
      Dummer weise ist der Reset-Pin des RFM aber ebenso wie die SPI nicht mehr bedienbar bei zu niedriger Spannung, denn er ist anders als bei vielen anderen Chips High-Activ.
      Ohne High, kein Reset.

      Heißt: Ohne P-FET zwischen Vcc und Resetpin direkt am RFM69 bekommt man das Teil in diesem Zustand nicht gezämt.
      Und das auch nur in der Hoffnung das bei einer Restspannung von 1,6V (wo er noch sendet!) die Reset-Auswertung überhaupt noch funktioniert.

      Wie oscar hier schon eingeschmissen hat, sind andere warscheinlich schon an diesem Teil verzweifelt.

      Daher, wenn ich mit den Teilen mal durch bin, werde ich mich mal an nen Admin wenden um eine Freischaltung für das Lexikon zu bekommen. Im Internet findet man zu diesen Teilen nämlich fast gar nix.

      Meine nächsten Baustellen bei dem Projekt in lockerer Folge:

      Als erstes kommt ein Modul für die Sensoren dran.
      Denn die senden derzeit noch ohne Timeslot-Protokoll einfach stur Testpakete ohne Sensordaten aus.
      Da ich in der LCD-Test1 aufgrund des Paketfehlers aus diesem Thema eine Fehlerkorrektur eingefügt habe welche im FIFO-Inhalt das gültige Paket suchen soll, funktioniert das bisher nur halb:
      Einfach nur ein 25Byte großes Paket suchen welches vin Byte 1-24 eine gültige CRC8 als Byte 25 hat geht nicht.
      Denn an Ende des FIFO's stehen alle Bytes auf h00, und die korrekte crc8 von 24Bytes h00 ist eben auch h00.
      Von daher suche ich in der letzten Fehlerkorrektur nach den zu erwartenden Zeitstempel Byte 2 und Byte 3 (Jahr + Monat des Zeitstempels).
      Funktioniert bei Fehlauswertung des Repeater wunderbar, bei den Sensoren noch nicht weil sie keinen Zeitstempel haben.

      Als zweites kommt im Terminal erstmal eine Auswertung der Sensordaten, um im LCD eben auch Temperatur, Luftfeuchtigkeit und Luftdruck stehen zu haben.

      Frühestens an dritter Stelle kommt dann das AVR-DOS mit der SDHC.

      An vierter Stelle käme dann der ESP via UART0 dran.
      In erster Linie eine Auswertung von eingehenden Webaufrufen und das senden einer Index.html von der SDHC sowie dem übertragen von Logdateien.

      Und zum Schluss dann die grafische Ansteuerung des zweiten EADOGM mit den Diagrammen.

      Irgendwo dazwischen oder zum Schluss auch noch irgend eine Art von Menuesystem, um die Darstellung der einzelnen Sensoren und der Meßkanäle aus zu werten.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Und das auch nur in der Hoffnung das bei einer Restspannung von 1,6V (wo er noch sendet!) die Reset-Auswertung überhaupt noch funktioniert.
      Im Datenblatt steht, dass der Betriebsspannungsbereich 1,8 bis 3,3 Volt sein soll.
      Wenn da dann nur 1,6V dran sind, darf das Modul auch "spinnen"!

      Aber wie tief fällt denn deine Spannung ab und warum?

      DG7GJ schrieb:

      Einfach nur ein 25Byte großes Paket suchen welches vin Byte 1-24 eine gültige CRC8 als Byte 25
      Ich würde Pakete in einem Frame senden. Heißt da gibt es ein definiertes Startbyte und ein definiertes Schlussbyte. Checksumme (CRC) ist das letzte Byte vor den Schlussbyte.
      So könnte man, wenn man schon im Fifo suchen will, einfach nach dem Startbyte suchen. Ist das gefunden, zu prüfen, ob das Schlussbyte auch vorhanden ist (Offset 25). Dann die Daten nehmen und mit CRC verrechnen.

      Diese Vorgehensweise würde vermutlich weniger Rechenleistung (Zeit) abverlangen, als zig mal eine CRC-Berechnung durchzuführen, bis die CRC-Summe stimmt.