-
Hallo,
mach es so wie Vitis
es schreibt :
Zähle in der ISR nur die bytevariable hoch und prüfe ob sie
Größer als (250ms / 16,4ms = ca.) 15 ist, wenn das so ist setzt du die
Variable zurück und setzt ein Bit .
Im Hautprogramm fragst du genau dieses Bit ab ob es gesetzt, ist wenn ja
machst du dein „Ersatz ISR Unterprogramm“ und am Ende Resetest du das Bit wieder
somit hast du für deine Ersatz ISR wieder fast 250 ms zur Verfügung .
Natürlich dürfen dann im Hautprogramm nicht Sachen wie
Wait 2 (oder so) stehen, aber das ist ja sicher auch nicht der Fall .
Gruß
HansHans
-
Hallo,
diese Variante funktioniert - wie gesagt - deshalb nicht, weil das Unterprogramm, das alle 250ms ausgeführt werden soll, länger als der max. Abstand zwischen zwei Interrupts ist. Deshalb kann die Sache mit dem Zähler nicht funktionieren - wie ich ja schon in meinem allerersten Posting schrieb.
Das Unterprogramm dauert nicht wegen eines Programmierfehlers so lange, sondern weil ich einige (leider zeitraubende) Grafik-LCD Befehle ausführe. Das würde ich gerne lassen, muss es aber im Interrupt tun, weil die Grafikausgabe ansonsten durch den Interrupt gestört würde. Wenn also während des Schreibens aufs LCD ein Interrupt ausgelöst wird, stellt das LCD nur noch Müll dar. Ich muss also dafür sorgen, dass die Darstellung immer komplett abgeschlossen ist, bevor ein Interrupt ausgelöst wird. Interrupts während der Grafikausgabe zu verbieten stellt natürlich auch keine Lösung dar, denn dann stimmt das Timing wieder nicht mehr genau. Ich sah also als einzige Variante das Überhnehmen der LCD-Ausgabe in die Interrupt-Routine. Die Routine würde übrigens knapp 20 ms dauern - also auch nicht so viel länger als der mögl. Interruptabstand...
Ich machs jetzt ingesamt anders: ich tune nach dem alles fertig ist den Schleifendurchlauf auf exakt 250ms mit waitms und waitus.
Gruß,
malthy
-
Also ich verstehe zwar nicht warum man das LCD im Interrupt
beschreiben muss, ich mach das immer im Hauptprogramm
wenn ich gerade mal zeit dazu habe. Durch eine
Interrupt Unterbrechung der LCD Routine sollte sich das LCD nicht
stören lassen. Das sind ja nur ein paar Takte
Aber wenn es jetzt so geht ...
-
Hallo HansHans!
ich hätte auch nicht gedacht, dass der Interrupt das LCD stört - ist aber definitiv so. Und das ist der alleinige Grund, warum ich das LCD in der Interrupt-Routine beschreiben wollte...
Gruß,
malthy
-
naja, so kann mans auch machen, aber ne andere Variante ists
die Interrupts während der Ausgabe zu disablen, also
einfach zu Beginn des refresh disabel interrupts, danach
wieder enable interrupts ... nicht schön, aber sollte gehen.
Warum das Display aber durch die Int gestört werden kann
hängt mir aber dennoch zu hoch.
Was ists denn für ein Display und wie ists angeschlossen?
-
Mir geht das mit deinem Display nicht aus dem Kopf .....
ist das ein Display ohne Controller wo du selbst das
Timing und den refresh machen musst ?
(Ich meine jetzt den refresh obwohl sich der Bild Inhalt
gar nicht verändert hat )
-
Hallo,
naja, wie gesagt, Interrupts während der Grafikausgabe verbieten macht auch nicht so viel Sinn, weil dann das Timing wieder ungenau wird...
Es wäre natürlich super, wenn mir noch jemand die Sache mit dem LCD erklären könnte - ich verstehe es nämlich auch nicht so recht. Ich verwende ein 240*128 Grafik-LCD mit einem T6963C als Controller, es ist entsprechend BASCOM-Hilfe an meinen M32 angeschlossen (Controll- und Dataport) Zur Ansteuerung verwende ich ausschließlich die BASCOM-Befehle, vor allem Showpic. Ohne Interrupts funktioniert alles super, mit Interrupts zeigt das Display nur noch Müll...
Gruß,
malthy
-
hmmm, dem Datenblatt nach dürfte es eigentlich keine
Probleme mit den Interrupts geben, der Controller ist nicht
zeitkritisch. Möglich, das es mit den Einstellungen
für Stack und Frame zutun hat, das sich dann eben was überschneidet.
Um genauere Analyse vorzunehmen müsste man den Code sehen.
-
Hallo,
ich werde mal versuchen, ein möglichst reduzierten und dadurch durchsichitgen Code zu erzeugen, bei dem das Problem auftritt. Das könnte einen Tag dauern, habe gerade andere Dinge an den Hacken. Was ich vielleicht noch nachtragen könnte: Die Showpic Aufrufe finden in einer Do-Loop-Schleife sehr schnell hintereinander statt, was letztlich programmiertechnische Gründe hat. Im Endeffekt wird also kontinuierlich aufs LCD geschrieben.
