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

    • Hallo Mitch64!

      Mitch64 schrieb:


      DG7GJ schrieb:

      Tja, wieder ein Argument für ein Redesign.
      Oder über Vorschlag 3 in Post #11 mal nachdenken.Dann könne alles mit aktueller Verdrahtung als Hardware-SPI-laufen.
      Auch die beiden Displays.
      Tja, angelesen habe ich das bereits.
      $LCDPUTCTRL und $LCDPUTDATA definieren Subs in denen man mittels ASM direkt ins R24 schreibt.
      Prinzip verstanden, aber noch nicht gemacht.
      Eventuell traue ich mich demnächst mal da ran - jetzt bin ich erst mal froh das dieses Projekt auch was am LCD ausgeben kann, und ich nicht permanent über die UART den HTerm im Blick haben muss.

      Somit sitze ich noch am ungewolltem Scroll-Effekt.
      Also habe ich alle LCD-Schreibbefehle nun mal zusammen in eine Sub gepackt die im Sekundentakt das LCD befeuert.

      BASCOM-Quellcode

      1. If Timezone = 1 then
      2. Lcdat 2 , 1 , Wochentag
      3. Lcdat 2 , 17, Date$ ; " " ; Time$ ;"w"
      4. else
      5. Lcdat 2 , 1 , Wochentag
      6. Lcdat 2 , 17, Date$ ; " " ; Time$ ;"s"
      7. end If
      8. 'Lcdat 3, 1, Hex(RX_0(1));" = "
      9. 'end if
      10. 'If RX_0(1) = &hA0 then
      11. 'lcdat 4, 40, "Repeater"
      12. 'end if
      13. 'If RX_0(1) = &hA1 then
      14. 'lcdat 4, 40, "Sensor 1"
      15. 'end If
      16. Lcdat 7, 1, "Akku: ";AkkuS;"V"
      17. Return
      Alles anzeigen

      Zeilen 1-7 waren zuerst in Lcdat 1,1, habe ich nun in Zeile 2 um einen Sicherheitsabstand von 8 Pixeln zum oberen Rand zu bekommen.

      Zeile 20 spuckt mir die aktuelle Akkuspannung (Fusing "#.###") an, die habe ich von Zeile 8 aus auf Zeile 7 gepackt, um auch von der Unterkante 8 Pixel Sicherheitsabstand einhalte.

      Diese beiden Sachen haben das Problem aber nicht gelöst.

      Die Ursache liegt im auskommentierten Zeilenbereich 9-18:
      Je nach Sensorkennung (hA0 oder hA1) sollte entweder "A0 = Repeater" oder "A1 = Sensor 1" ausgegeben werden.
      Das erste Zeichen sitzt wie zu erkennen ebenso ab Pixel 1 (Zeilenbeginn). Das jeweilige Wort "Sensor 1" oder "Repeater" landete mit Lcdat 4, 40 ziemlich exakt mittig des LCD's mit reichlich Abstand zum rechten Rand.

      Dennoch ist es genau diese Ausgabe welche mir die Anzeige verreißt:
      Es tauchen plötzlich wilde Zahlenketten hinter der Akkuspannung (z.B. 3.652V70) auf, im nächsten Augenblick springt die Zeit-Zeile von Zeile 2 in Zeile 8 und alles verschiebt sich.

      Mit den auskommentierten Zeilen 9-18 läuft es deutlich besser.
      Zumindest verreißt es mit nicht mehr alles, aber störende Zeichen die da nicht hin gehören gibt es weiterhin *grübel*

      Aber was andere Grafik-LCD's und TFT's angeht, habe ich auf der Suche nach diversen Controllertypen eine zwar nicht topaktuelle, aber zumindest schon brauchbare Zusammenfassung gefunden:

      mcselec.com/index2.php?option=…59&page=viewtopic&t=13074

      Grüße

      Jürgen
      Dateien
      • DSCF5249_M.jpg

        (85,53 kB, 1 mal heruntergeladen, zuletzt: )
      • DSCF5250_M.jpg

        (90,28 kB, 2 mal heruntergeladen, zuletzt: )
    • DG7GJ schrieb:

      Lcdat 3, 1, Hex(RX_0(1))
      Solche verschachtelten Anweisung machen oft Probleme.
      Entweder Zerpflücken und und 2 Anweisung aufteilen.

      etwa so:
      tmpString = Hex(RX_0(1)
      Lcdat 3,1,tmpString


      Zuerst würde ich aber man die Stackwerte überprüfen.

      Kannst du dazu mal nach dem Compilieren ein Screenshoot machen von deinem Code-Explorer mit geöffneter Info-Struktur und dazu angeben, welche Stackwerte du eingestellt hast?
      in den
    • Hallo Mitch64!

      Mitch64 schrieb:

      Solche verschachtelten Anweisung machen oft Probleme.Entweder Zerpflücken und und 2 Anweisung aufteilen.

      etwa so:
      tmpString = Hex(RX_0(1)
      Lcdat 3,1,tmpString


      Zuerst würde ich aber man die Stackwerte überprüfen.

      Kannst du dazu mal nach dem Compilieren ein Screenshoot machen von deinem Code-Explorer mit geöffneter Info-Struktur und dazu angeben, welche Stackwerte du eingestellt hast?
      in den
      Ahja, gut zu wissen. Bislang bei meinen Projekten mit ASCI-LCD's 2x16/4x20usw. ging sowas problemlos.
      Aber gut, dann demnächst nur noch Strings.

      Beim öffnen des Code-Explorers war ich erstaunt über reichlich Fehlermeldungen.
      In dem Meldungsfenster von Bascom werden mir weder beim Syntax-Check noch beim Compilieren irgendwelche Fehler angezeigt.
      Die Fehlermeldungen im Code-Explorer meckern meine ausgelagerten Sub's an:

      BASCOM-Quellcode

      1. $Include Z02_Sensoren.bas
      2. $Include Z05_RxPacket.bas
      3. $Include Z20_RFMinit.bas
      4. $include Font16x16.font
      5. $include Font8x8TT.font
      6. $Include Font8x8.font
      Ausserhalb des Code-Explorers wird nix davon angemeckert und funktioniert auch alles.

      Im Screenchot ist der Header mit den Stackwerten enthalten.
      Das sind wie so häufig bei mir grob gewählte Werte von denen ich mutmaße das sie eher zu groß als zu klein sind.

      Grüße

      Jürgen
      Dateien
      • Screen1.jpg

        (255,3 kB, 16 mal heruntergeladen, zuletzt: )
    • Du hast da überall 400 Byte als Stackgrößen drin.
      Ist ziemlich übertieben, aber am Stack liegt es mal nicht.

      Ich denke für deine Anwendung würden 64 Byte für alle Stackwerte reichen.

      Wo jetzt die Fehlermeldungen im Code-Explorer herkommen weiß ich jetzt nicht.
      Ich kenne das so nicht.

      Hast du das Projekt mit einer Projektdatei als Projekt laufen?
      Oder sind das alles einzelne Dateien ohne Projekt-Datei?

      Im letzten Fall geht Bascom vermutlich davon aus, dass die einzelnen Dateien unterschiedliche Programme sind.
      Das könnte die Fehler verursachen.

      Aber wie gesagt, ich vermute hier nur.

      Auf jeden Fall sollte den Fehlern nachgegangen werden.

      Hast du eine Projektdatei angelegt?
    • Hallo Mitch64!

      Im Header habe ich normalerweise Werte zwischen 100-120.
      Bei diesem Projekt habe ich die absichtlich höher gesetzt.

      Beim zukünftigen AVR-DOS weis ich noch nicht wieviele offene Dateien ich parallel brauche, oder ob ich die sequentiell abarbeiten kann. Auch beim ESP via UART-AT weiß ich noch nicht wieviel ich da an Stackwerten brauche.

      Eine Projektdatei hatte ich noch nicht angelegt.
      Habe die ganze Geschichte jetzt aber mal als Projekt geseichert.

      Die Fehlermeldungen blieben dabei unverändert.
      Jedoch konnte ich diese beheben indem ich die Dateinamen in Anführungsstriche setzte:

      BASCOM-Quellcode

      1. $Include "Z02_Sensoren.bas"
      2. $Include "Z05_RxPacket.bas"
      3. $Include "Z20_RFMinit.bas"
      4. $include "Font16x16.font"
      5. $include "Font8x8TT.font"
      6. $Include "Font8x8.font"

      Das frist nun auch der Code-Explorer.

      Grüße

      Jürgen
    • Die Projektdatei...damit muss ich erst noch warm werden...

      Also nachdem ich alle Include-Dateinamen in Anführungsstriche setzte, waren alle Fehlermeldungen im Code-Explorer weg und die Info-Werte zu Stack und RAM waren alles noch die selben wie im Screenshot.

      Dann allerdings ist mir die Projektdatei beim neu brennen über ISP abgeschossen:
      Der "STK500 native driver" ist zwischen Write und Verify eingefrohren.
      Nach einem Neustart war die zuvor gespeicherte Projektdatei kaputt.
      Also wieder zurück zur ursprünglichen *.bas, erneut als Projekt gespeichert, und dann wurd es richtig wirsch:
      In der neuen Projektdatei zeigt er mir wieder die selben Fehler.
      Allerdings diesmal in einer *BAS die nix mit dem derzeitigen Projektstadium zu tun hat:

      /Projekte/Terminal/Terminal 2/Terminal_2.bas war der letzte Status von vor ner Woche.
      /Projekte/Terminal/LCD-Test/LCD-Test_1.prj
      /Projekte/Terminal/LCD-Test/LCD-Test_1.bas
      Ist der aktuelle Ornder der letze Woche neu erstellt wurde.
      Aus mir unverständlichen Gründen meckert der Code-Explorer aus der LCD-Test_1.prj nun die alte Terminal_2.bas an.

      Habe die alten "Terminal_2.*" eben mal alle umbenannt, da ich keine Funktion in bascom fand dem Projekt bei zu bringen welche Dateien nun zum Projekt gehören, und was nicht.

      Hmm...Projekt Files ist was...ich forsch da nochmal bissel rum.
    • Unter Menü -> "Anzeigen" - > musst du "Projektfiles" aktivieren.
      Dann taucht rechts im Editor eine Sitebar auf.

      Dort kannst du die Dateien bestimmen, die zum Projekt gehören.
      Übrigens musst du dort auch zwingend die Haupt-Datei angeben.
      Also die Datei mit den Stackwerten und der µC Angabe.
      Das ist i.d.R die Bas-Datei.
      Include-Dateien sollten INC-Dateien sein (Code-Dateien).

      Ich geb zu man hätte das Feature anders gestalten können.
      Aber wenn man durchsteigt ist es echt eine Hilfe!

      Übrigens musst du wenn die Projektdatei geändert wird diese speichern.
      Menü: Datei -> Project - Save.

      Sonst sind die Änderungen nach dem Neuladen des Projekts weg.
    • Ja, so langsam scheint das Projektfile konsistent zu sein.

      Dann kann ich morgen mal schauen was es mit dem Display noch auf sich hat.

      Bislang nichts geändert...der auskommentierte bereich mit dem Hex(RX_0(1)) ist weiter deaktiviert.
      Also nur die Zeitzeile oben auf Lcdat 2,1und die Akkuspannung als formatierter String unten auf Lcdat 6,1.

      Je länger das Teil läuft, um so schlimmer wird der Fehler...nach etwa 30 Minuten liegt jegliche Ausgabe ausserhalb des aktiven Bereiches.
      Da gerade der Laderegler probe läuft und ich die Akkuspannung vom ADC regelmässig checken will, musste ich mir was einfallen lassen.

      Auf eine Taste ein CLS gelegt...löscht das LCD, aber die falsche Ausrichtung der Ausgaben bleibt falsch.
      Auf der nächsten Taste brutal ein Initlcd gelegt, das zeigt die gewünschte Wirkung für die Notlösung.

      Grüße

      Jürgen
    • Das Verhalten kommt wir irgendwie so vor, als ob falsche Daten an das Display gehen (als Command).
      Als Daten wäre ja ein Zeichen erscheinen.

      Kannst ja mal die CS-Leitungen beider Displays checken, ob die immer zu richtigen Display bei den Ausgaben gehen.
      Also ob die richtige CS-Leitung aktiv ist, wenn du Ausgaben auf das Display machst. Auch bei der Initialisierung würde ich das mal prüfen.
    • Hallo Mitch64!

      Mitch64 schrieb:

      Das Verhalten kommt wir irgendwie so vor, als ob falsche Daten an das Display gehen (als Command).
      Als Daten wäre ja ein Zeichen erscheinen.

      Kannst ja mal die CS-Leitungen beider Displays checken, ob die immer zu richtigen Display bei den Ausgaben gehen.
      Also ob die richtige CS-Leitung aktiv ist, wenn du Ausgaben auf das Display machst. Auch bei der Initialisierung würde ich das mal prüfen.

      Tja, du meinst das der SPI-Verkehr da zum LCD durchflutscht? Habe ich auch schon dran gedacht.
      Mir ist nur noch nicht eingefallen wie ich das konkret messen kann.
      Also Oszi an /CS und A0 ist klar, nur das triggern in Abhängigkeit des Schleifendurchlaufes der Software ist soeine Sache..:-)

      Prinzipiell sollte da streng genommen nichts durcheinander kommen, weil die SPI-Kommunikation getrennt läuft:
      Wenn ich aktiv was vom RFM69 will, steuere ich manuell den /CS vom RFM auf Low, ziehe die Daten über den Bus und schalte den /CS danach wieder auf High.
      Während dessen läuft keinerlei LCD-Ansteuerung.

      Umgekehrt ähnlich:
      Das LCD befeuern mache ich nun nur noch in einer einzigen Sub die durch die Sectic der RTC angesprungen wird.
      Da kann normaler weise, solange diese Sub ausgeführt wird, nichts mit dem RFM kommunizieren wollen.

      Auch die INT-Leitungen DIO0 und DIO4 des RFM werte ich nicht als Interrupt aus, sondern über eine If-Then-Funktion in der Hauptschleife.
      Ob da also der RFM was zu sagen hat oder nicht wird halt erst abgefragt wenn der Programmablauf wieder die Hauptschleife abfährt.

      Was ich noch machen könnte wäre eine zeitliche Trennung indem ich vor und nach den LCD-Zugriffen ein waitms 50 oder so setze.

      Habe das Projekt mal angehängt.

      Grüße

      Jürgen
      Dateien
      • LCD-Test 1.zip

        (19,8 kB, 19 mal heruntergeladen, zuletzt: )
    • DG7GJ schrieb:

      Prinzipiell sollte da streng genommen nichts durcheinander kommen, weil die SPI-Kommunikation getrennt läuft:
      Wie du sagtest: Streng genommen!
      Der Teufel steckt oft im Detail.
      Was ich meinte war, ob du ganz sicher bist, absolut sicher, dass du immer nur den CS runter ziehst von dem Gerät an das du senden willst und danach wieder ordentlich CS High setzt?
      Messen mit Oszi braucht man da nichts. Nur Routinen kontrollieren.


      DG7GJ schrieb:

      Das LCD befeuern mache ich nun nur noch in einer einzigen Sub die durch die Sectic der RTC angesprungen wird.

      Und was ist da mit der Sectic-Routine?
      Ist das eine ISR?
      Greifst du da vielleicht auf die SPI zu?

      Wenn ja könnte das der Grund sein.

      Besser auch nur Flag setzen und und der Hauptschleife abarbeiten.
    • Halli Mitch64!

      Mitch64 schrieb:


      DG7GJ schrieb:

      Prinzipiell sollte da streng genommen nichts durcheinander kommen, weil die SPI-Kommunikation getrennt läuft:
      Wie du sagtest: Streng genommen!Der Teufel steckt oft im Detail.
      Was ich meinte war, ob du ganz sicher bist, absolut sicher, dass du immer nur den CS runter ziehst von dem Gerät an das du senden willst und danach wieder ordentlich CS High setzt?
      Messen mit Oszi braucht man da nichts. Nur Routinen kontrollieren.

      Achso, du meinst die Steuerungen im Programm, freilich. Genauer gesagt:
      Die ChipSelect-Steuerung des LCD's überlasse ich aktuell noch der LCD-Lib.
      Daran könnte es liegen, aber meine Hoffnung liegt darauf das die Lib nach der Initialisierung des LCD nur noch dann an der ChipSelect rumwackelt, wenn ich aktiv mit LCD-Komandos das LCD anspreche.
      Also eben sowas wie Lcdat x,x "Text" aufgerufen wird.

      Allerdings, falls es daran liegen sollte das doch die glcdEADOGM128x6.lbx da "interruptartig" ohne Rücksicht auf andere SPI-Verkehre rumzuckelt, wäre es mal interessant zu ergründen warum und was da übertragen wird.

      Denn da der Config GraphLCD nicht mehr als ein einzelnes Display verwalten kann, wollte ich später wenn das zweite LCD bestückt wird die /CS-Steuerung manuell steuern.

      Also den /CS in der Config GRAPHLCD auf den letzten noch freien Portpin ins Nirvana umleiten, und statt dessen:

      Vor Initialisierung Config Graphlcd die /CS von LCD1 und LCD2 low ziehen,
      nach der Initialisierung die /CS beider wieder auf Low,

      und dann nur bei den LCD-Ausgaben, je nach dem was ich auf welchen LCD ausgeben will, im Programmablauf jeweils nur den /CS des gewünschten LCD's aktivieren.

      Hmm, das probiere ich mal als nächstes.

      Alles andere, aktuell eben nur der Verkehr mit dem RFM steuere ich manuell und korrekt:
      Immer

      CS_RFM = 0
      SPIOUT...
      SPIIN...
      CS_RFM = 1

      Mitch64 schrieb:


      Und was ist da mit der Sectic-Routine?
      Ist das eine ISR?
      Greifst du da vielleicht auf die SPI zu?

      Wenn ja könnte das der Grund sein.

      Besser auch nur Flag setzen und und der Hauptschleife abarbeiten.

      Wäre mir zumindest nicht bewusst:

      BASCOM-Quellcode

      1. Sectic:
      2. LCDtime = 1
      3. If _sec = 30 then Gosub LCDadc
      4. return

      Die einzige Gosub dort:


      BASCOM-Quellcode

      1. LCDadc:
      2. adcwert1 = getadc(3)
      3. adcwert2 = getadc(3)
      4. adcwert3 = getadc(3)
      5. adcwert1 = adcwert1 + adcwert2
      6. adcwert1 = adcwert1 + adcwert3
      7. adcwert1 = adcwert1 / 3 'Mittelwertbildung
      8. Akkuspannung0 = adcwert1 * 0.0017578125 'AVref = 1,80V
      9. Akkuspannung1 = Akkuspannung0 + 2.50 'Differenz = 2,49 - 2,50V
      10. AkkuS = Fusing(Akkuspannung1, "#.###") 'Formatierung für LCD-Ausgabe
      11. Return
      Alles anzeigen

      Diese könnte ich auch über ein Flag ansprechen.

      Die offensichtlichen LCD-Zugriffe, also die Config Graphlcd inkusive der Initlcd sowie die Sub in der ich alle LCD-Ausgaben zum LCD schicke, habe ich nun eingeramt in waitms 100 vor und nach diesen Bereichen.

      Das hat den Fehler schon deutlich vermindert. Die Anzeige läuft nun 1-2 Stunden durchweg ohne Fehler, nach über 2 Stunden passiert es aber dennoch wieder das die Anzeige verhuntzt wird.
      Also anfangs irgendwelche Zeichen die ich nicht ausgegeben habe, bis hin zum leeren LCD wo nix mehr im Anzeigebereich liegt.

      Grüße

      Jürgen
    • DG7GJ schrieb:

      Vor Initialisierung Config Graphlcd die /CS von LCD1 und LCD2 low ziehen,
      nach der Initialisierung die /CS beider wieder auf Low,
      Du meinst danach wieder High ziehen.

      DG7GJ schrieb:

      und dann nur bei den LCD-Ausgaben, je nach dem was ich auf welchen LCD ausgeben will, im Programmablauf jeweils nur den /CS des gewünschten LCD's aktivieren.
      Du kannst mal versuchen, ob der Compiler meckert, wenn du bei Config GraphLCD die CS-Leitung weg lässt.
      In dem Fall könntest du tatsächlich die CS-Leitung manuell bedienen.

      DG7GJ schrieb:

      Sectic:
      Dieses Label sagt mir, dass du entweder eine DCF-Uhr on Board hast oder eine Soft-Clock konfiguriert hast.
      Die Routine wird nicht von dir aufgerufen nehme ich an, sondern von der Lib.

      Da bin ich jetzt nicht sicher, ob in der Routine alle Register gesichert werden müssen, bevor man da mit Basic-Befehlen arbeiten kann.

      Also so:

      sectic:
      PushAll
      ' Hier dein Code
      PopAll
      Return

      Ich mache wenig bis nix mit Uhr und daher wissen bestimmt die Kollegen hier besser Bescheid.

      Wichtig ist aber, dass du per Interrupt (z.B. "sectic:") keine Zugriffe machst auf die SPI-Schnittstelle,
      denn wenn da gerade was vom Hauptprogramm geschrieben / gelesen wird und dann kommt der sectic-Interrupt und greift auch zu, der bringt natürlich alles durcheinander.

      Ob dein Fehler von dem sectic-Interrupt her kommt kannst du ja mal ausprobieren.
      Dazu die Uhren-Konfiguration remmen.
    • Hallo!
      Eher weniger, denn da steht auch nur das, wenn ich Initlcd verwende gezielt an diesem Punkt das Display initialisiert wird. Ob da aber in der jeweiligen Routine irgendwelche Timer laufen die während der Programmlaufzeit alle xxxms was zum LCD schicken wollten, steht das da nicht. Und genau das meinte ich.
      Aber das ist ein Thema, welches ich schon häufiger hatte. Diverse Funktionen und Libs sind bis auf wenige Grundinfos in der Bascom-Hilfe nicht wirklich tiefgründig dokumentiert.
      Glegentlich z.B. das aufkommende Thema der DCF77-Lib und deren inkompatibilität mit dem Asynchronen Timer als RTC.

      Mitch64 schrieb:


      DG7GJ schrieb:

      und dann nur bei den LCD-Ausgaben, je nach dem was ich auf welchen LCD ausgeben will, im Programmablauf jeweils nur den /CS des gewünschten LCD's aktivieren.
      Du kannst mal versuchen, ob der Compiler meckert, wenn du bei Config GraphLCD die CS-Leitung weg lässt.In dem Fall könntest du tatsächlich die CS-Leitung manuell bedienen.

      Hmm, kann ich nachher sicherlich mal probieren.
      Allerdings würde ich schon erwarten das er meckert wenn ich ein SPI-LCD definiere ohne solch eine wichtige Signalleitung die den /CS...
      Daher ja mein Plan den auf einen unbenutzten Ausgang ins Nirwana zu leiten.

      Mitch64 schrieb:


      Sectic:
      Dieses Label sagt mir, dass du entweder eine DCF-Uhr on Board hast oder eine Soft-Clock konfiguriert hast.Die Routine wird nicht von dir aufgerufen nehme ich an, sondern von der Lib.

      Da bin ich jetzt nicht sicher, ob in der Routine alle Register gesichert werden müssen, bevor man da mit Basic-Befehlen arbeiten kann.

      Also so:

      sectic:
      PushAll
      ' Hier dein Code
      PopAll
      Return

      Ich mache wenig bis nix mit Uhr und daher wissen bestimmt die Kollegen hier besser Bescheid.

      Wichtig ist aber, dass du per Interrupt (z.B. "sectic:") keine Zugriffe machst auf die SPI-Schnittstelle,
      denn wenn da gerade was vom Hauptprogramm geschrieben / gelesen wird und dann kommt der sectic-Interrupt und greift auch zu, der bringt natürlich alles durcheinander.

      Ob dein Fehler von dem sectic-Interrupt her kommt kannst du ja mal ausprobieren.
      Dazu die Uhren-Konfiguration remmen.

      In diesem Projekt sitzt eine RTC mit 32kHz Uhrenqarz am asynchronen Timer.
      Die reale, aktuelle Uhrzeit kommt über den RFM69HW von einem Repeater, welcher ein DCF-Modul eingebaut hat.
      Das Terminal empfängt zu jeder vollen Minute ein Zeitstempel und Qualitätsmerkmal:
      In den 25byte großen GFSK-Paketen ist nach dem Timestamp ist noch ein Stundenzähler der die Stunden seit der letzten DCF77-Synchronisierung im Repeater mitzählt.

      Alle anderen Geräte (Sensoren und das Terminal worum es hier geht, das einzige Teil mit LCD) erkennen den Zeitstempel anhand der Absender-ID und synchronisieren ihre 32kHz-RTC mit der empfangenden Zeit, wenn der DCF-Stundenzähler auf 0 ist.

      Ich kann mir mal überlegen wie ich die RTC-INT ausremmen kann ohne mir das komplette Programm ab zu würgen.
      Denn LCD-Ausgabe sowie auch viele andere Funktionen werden durch die Sectic getimet.

      In so fern:
      Unmittelbar nach einem Sectic-INT werden dadurch angestoßen weitere Funktionen angestoßen, welche zum Teil SPI-Verkehr sowie auch UART-Protokollausgaben (115200Bd) rausschießen.
      Das sind aber alles Sachen im Bereich von Sekundenbruchteilen.

      Selbst die bislang größte Sub im Worst-Case Fall (Reparaturversuch eines RFM-Paketes mit korrupter crc8) wird innerhalb von 60ms abgearbeitet, die ADC-Messung (3 fach zwecks Mittelwertbildung) sollte rechnerisch im Bereich von 2-3ms durch sein.

      Allerdings, wo ich wieder bei der lückenhaften Dokumentation ankomme...wie arbeitet die Config Clock=Soft wirklich?

      Normaler weise arbeiten Uhren mit 32,768kHz Uhrenquarz Prescaler /128 und den 8Bit-Counter dahinter = 1s INT-Zeit.
      Das hoffe ich doch bei der Bascom-Softclock ebenso, nicht das die irgendwo bei xxms mit Int's feuert und im Hintergrund die Sekunden daraus abzählt.

      OK, in diesem Gedanken könnte ich versuchen die RTC komplett selbst zu schrauben...Config Clock = User.

      Grüße

      Jürgen
    • Was ich dir versuche die ganze Zeit zu sagen ist folgendes:

      Ein Interrupt wartet nicht, bis irgend eine Sub abgearbeitet ist, sondern startet die ISR nach Abarbeitung des aktuellen ASM-Kommandos. Also unter Umständen auch wenn gerade was vom RFM-Modul rein kommt.

      Du hast dann z.B. in der Hauptschleife die Routine zum auslesen des RFM gestartet, die Select gesetzt und dann kommt der Interrupt.

      Wenn 2 Routinen gleichzeitig an der SPI was machen wollen, was meinste, kommt da noch was gescheites dabei raus?
    • Hallo Mitch64!

      Mitch64 schrieb:

      Was ich dir versuche die ganze Zeit zu sagen ist folgendes:

      Ein Interrupt wartet nicht, bis irgend eine Sub abgearbeitet ist, sondern startet die ISR nach Abarbeitung des aktuellen ASM-Kommandos. Also unter Umständen auch wenn gerade was vom RFM-Modul rein kommt.

      Du hast dann z.B. in der Hauptschleife die Routine zum auslesen des RFM gestartet, die Select gesetzt und dann kommt der Interrupt.

      Wenn 2 Routinen gleichzeitig an der SPI was machen wollen, was meinste, kommt da noch was gescheites dabei raus?

      Das ist mir schon klar, das da nichts kollidieren darf.
      Deshalb achte ich penibelst darauf im Programmablauf alles einzeln und sauber getrennt zu machen. Nicht nur auf dem SPI sondern auch dem I²C-Bus der da noch drauf ist.

      Ich kann aber, und genau diesen unwarscheinlichen Fall meine ich, nichts dafür wenn Bascom meint da undokumentierte Interrupts laufen zu lassen.
      Von der DCF77-Routine her weis ich z.B. das dort Timer1 alle 20ms einen Timer-Int feuert, was manch zeitkritische Sachen ziemlich aus der Bahn werfen können.

      Von daher hoffe ich das die RTC bei diesem Projekt mit Config Clock = Soft so funktioniert wie es eigentlich Standard ist.
      Also Timer0 mit Prescaler /128 und 8Bit-Counter exakt die 1s aus dem 32,768kHz-Quarz zu teilen.
      Und eben nicht der Timer z.B. alle 20ms feuern lässt um in Hintergrund zu zählen "alle 50 Int's den Sectic auslösen".

      Sollte dem wider erwarten so sein, würde mich so manches nicht mehr verwundern.

      Und selbstverständlich ist mir klar das Interrupts hardwaremäßige Echtzeitsignale sind.
      Eben drum habe ich in dem an Post 31 angehängtem Projekt in der Hauptschleife z.B. den DIO0-Int vom RFM (Sinngemäß "neues Paket mit korrekter CRC empfangen") zwar hardwaretechnisch am PinA.0 / INT0 angeschlossen, werte ihn in der Hauptschleife aber über eine "If DIO = 1 then Gosub" aus.
      Denn da kommt der Programmablauf alle 2 - 300ms vorbei, was mir und dem RFM69W ausreicht.

      Würde ich den als INT anfragen während ich gerade im E²PROM-Datenlogger (2x M24M02) schreibe, demnächst aus SD-Card offene Schreibvorgänge usw habe, würde das Chaos ausbrechen.

      Von daher: Im gesamten Projekt (überschaubar bisher weil auf die aktuellen Grundelemente gekürzt) aus Posting 31 verwende ich bis auf Clonfig Clock - Sectic und gelegentliche UART-Ausgaben selber keinerlei willentlich-bewust gesetzten Interrupts.

      Und was ich in Posting 36 am Ende aussagen wollte:
      Wenn die Sectic die einzige "willkürliche" Int ist feuert sie anständiger weise exakt zum Sekundenwechsel, also alle 1000ms.
      Genau von diesem Sectic-Int werden die verschiedenen Funktionen gestartet.
      Die kürzeste fürfte bei knapp 2ms liegen, die längste im Worst-Case Fall 60ms.
      Da liegen dann also mal eben 940ms Lerlauf dazwischen wo einfach nur stupide und anspruchslos die MainLoop mit ihren 7 If-Then-Zeilen abgespult wird.

      Gut - nach änderung des SPI von Hardware aus Soft-SPI habe ich die Geschwindigkeiten noch nicht mit Oszi gemessen.
      Das LCD scheint relativ flink zu reagieren, und bei der RFM-Kommunikation merke ich zu vorher keine Änderung.
      Beim Empfang eines Päckchens 11 Register auslesen und anschließend (aktuell 66) Bytes aus dem FIFO ziehen dauert << 12ms inklusive des ganzen CRC und Paketweiterverarbeitungszeit.
      In der "Z05_RxPacket.inc" sieht man am Anfang und am Ende der Sub RxPacket jeweils ein auskommentiertes "Toggle Licht" womit ich das LCD-Backlight zum flackern gebracht habe.
      Auskommentiert weil ich mögliche Spannungsabfälle als Fehlerursache ausschließen wollte.

      Grüße

      Jürgen
    • OK, dann wäre das mit dem Sectic-Interrupt erst mal geklärt.

      DG7GJ schrieb:

      Ich kann aber, und genau diesen unwarscheinlichen Fall meine ich, nichts dafür wenn Bascom meint da undokumentierte Interrupts laufen zu lassen.
      Für das Display werden keine Interrupts verwendet. Das ist ganz normaler linearer Code.
      Und die SPI hast du ja auch ohne Interrupts konfiguriert. Die löst also auch einen Interrupt aus.

      DG7GJ schrieb:

      Und selbstverständlich ist mir klar das Interrupts hardwaremäßige Echtzeitsignale sind.
      Eben drum habe ich in dem an Post 31 angehängtem Projekt in der Hauptschleife z.B. den DIO0-Int vom RFM (Sinngemäß "neues Paket mit korrekter CRC empfangen") zwar hardwaretechnisch am PinA.0 / INT0 angeschlossen, werte ihn in der Hauptschleife aber über eine "If DIO = 1 then Gosub" aus.
      Denn da kommt der Programmablauf alle 2 - 300ms vorbei, was mir und dem RFM69W ausreicht.
      Das nennt man Pollen. Wenn die Hauptschleife mal länger braucht, das Signal vielleicht weg sein?
      Es spricht eigentlich nichts gegen einen Interrupt (INT0). Aber nicht die Auswertung im Interrupt machen, sondern nur ein Flag setzen.

      Ich mach das immer so
      Irgendwo am Codeanfang dimensioniere ich eine Flag-Variable und Konstanten, die die Bits angeben im Flag.
      Dim Flags as Byte
      Const FLAG_RFM69_RECEIVE=0 ' Bit 0
      Const FLAG_SECTIC=1 ' Bit 1

      und in der Hauptschleife fragst du nicht den Pin DIO ab, sondern das Bit im Flag.

      If Flags.FLAG_RFM&)_RECEIVE=1 then
      'deinen Code ausführen
      Reset Flags.FLAG_RFM&)_RECEIVE ' Flag löschen nicht vergessen
      End If

      Wenn du die ISR kurz hältst und nicht auf die SPI zugreifst in der ISR ist alles gut.

      DG7GJ schrieb:

      Würde ich den als INT anfragen während ich gerade im E²PROM-Datenlogger (2x M24M02) schreibe, demnächst aus SD-Card offene Schreibvorgänge usw habe, würde das Chaos ausbrechen.
      Dafür gibts die Möglichkeit den Interrupt für diese Dauer zu deaktivieren
      Disable INT0
      und wieder einschalten, wenn man mit dem EEProm fertig ist
      Enable INT0

      Oder eben global an und aus machen mit Disable Interrupts. Aber das kennste ja nehme ich an.


      DG7GJ schrieb:

      Und was ich in Posting 36 am Ende aussagen wollte:
      Wenn die Sectic die einzige "willkürliche" Int ist feuert sie anständiger weise exakt zum Sekundenwechsel, also alle 1000ms.
      Sectc ist aber eine Interrupt-Routine, die sollten so kurz wie möglich sein.
      Also nicht alle Möglichen Routinen darin starten, sondern Flag setzen.

      Zum Beispiel in der ISR nur:

      sectic:
      Set Flags.FLAG_SECTIC
      Return

      Und in der Hauptschleife das Flag abfragen, Routinen starten und Flag löschen.
    • Hallo!

      Was mir zwischenzeitlich noch eingefallen ist mit nicht geplanten Interrupts:
      Wie lauft das genau mit den UARTS und den dazugehörigen Int's?

      An den zwei UART's habe ich an UART1 ein ESP8266 und an UART2 eine Protokollschnittstelle zur Entwicklung, so zu sagen als LCD-Ersatz.

      Die diversen Protokollausgaben habe ich unter Kontrolle.

      Ich denke da jetzt eher an den ESP8266 an UART1.

      Da der ESP8266 sich sofort einschaltet sobald er die 3,3V Vcc bekommt, zieht er auch gute 100-500mA aus meinem Akku.
      Deswegen sende ich ihm noch in der Initialisierungsphase des µC, kurz nach Definierung der Com1 den Befehl "AT+SLEEP=2", was die Ruhestromaufnahme deutlich reduziert.
      Den RxD werte ich zum jetzigen Zeitpunkt noch nicht aus.

      Hypotetisch aber: Sollte da vom ESP gelegentlich was über den RxD in Richtung µC gehen, dummer weise ausgerechnet in den Momenten wo ich auf das LCD schreibe...

      Lange Rede, kurzer Sinn:
      Löst der Empfang eines Zeichens über den RxD im µC auch dann einen INT aus, obwohl kein INPUT, Inkey oder so definiert wird.

      Aktuell sieht das bei mir nur so aus:

      BASCOM-Quellcode

      1. Open "COM1:" for Binary as #1 ' Öffne Com1 zum ESP-WLAN
      2. Open "COM2:" for Binary as #2 ' Öffne Com2 zur Serviceschnittstelle
      3. .....
      4. Print #1 , "AT+SLEEP=2"
      5. Print #2 , "Sende AT+SLEEP=2"

      Den ESP8266 hatte ich bisher nur nackt direkt an einem FTDI 3,3V-USB Adapter im Testbetrieb.
      Aus der Phase sind mir keine zufälligen Ausgaben bekannt.
      Das Teil antwortet eben nur auf zu ihm gesendete AT-Befehle, und ansonsten eigentlich nur wenn es über WLAN angesprochen wird. Tue ich aber (noch) nicht.

      Grüße

      Jürgen