Interrupt vom Touch umstellen

IC-Cruncher · July 2, 2026 at 7:44 PM

Hallo Zusammen,

ich komme bei einem Thema einfach nicht weiter und bitte um Eure Unterstützung.
ich weiß auch nicht, ob meine Vorgehensweise richtig / sinnvoll ist.

ich habe an einem PICO 2 (SPI) ein TFT-Touch-Screen angeschlossen.
Soweit funktifunktionieren das TFT und der Touch.
Ich habe die Konfiguration der SPI, des TFT's und des TOUCH in eine separate Datei ausgelagert.
Ich kann in der main.py Elemente erstelllen und auf dem TFT darstellen. Auch der Interrupt von Touch funktioniert. Leider nich so wie er soll.

Mein angedachter Programmaufbau:
main.py

Python

from hardware.py import *
import programm

TFT = config_tft()
TOUCH = config_touch(TFT)

def touch_main_press(x, y):
	print(f"MAIN: X: {x}, Y: {y}")
	
	# wenn x,y in einem bestimmten Bereich liegen
	print("Programm starten")
	programm.prog_start(TFT, TPUOUCH)

# Interrupt für den Touch umstellen auf "touch_main_press"
TOUCH.int_pin.irq(trigger=Pin.IRQ_FALLING | Pin.IRQ_RISING,
                  int_handler = touch_main_press)

print("main-prog")

Display More

hardware.py

Python

from machine import Pin, SPI

from ili9341 import *
from xpt2046 import *

spi = SPI(0, baudrate=10000000, bits=8, firstbit=SPI.MSB, polarity=0, phase=0,
            sck=Pin(18), mosi=Pin(19), miso=Pin(16))

class config_tft(Display):
    def __init__(self):
    	super().__init__(spi, cs=Pin(9), rst=Pin(21), dc=Pin(20),
                width=240, height=320, rotation=90, mirror=False,
                bgr=False, gamma=False, x_offset=0, y_offset=0)
   
        TFT = Display(spi, cs=Pin(9), rst=Pin(21), dc=Pin(20),
                width=240, height=320, rotation=90, mirror=False,
                bgr=False, gamma=False, x_offset=0, y_offset=0)
            
        TFT_BL = PWM(Pin(15, Pin.OUT))
        TFT_BL.freq(1000)
        TFT_BL.duty_u16((0xffff * (100)) // 100)
        
        TFT.invert(True)
        
        TFT.clear()


class config_touch(Touch):
     def __init__(self, TFT):

     

super().__init__(spi, cs=Pin(8),
     

   int_pin=Pin(22), int_handler=self.touch_class_press,
     	width=240, height=320, x_min=198, x_max=3979,  y_min=292, y_max=380)


        self.TOUCH = Touch(spi, cs=Pin(8),
     

   int_pin=Pin(22), int_handler=self.touch_class_press,
     	width=240, height=320, x_min=198, x_max=3979,  y_min=292, y_max=380)
     
		def touch_class_press(self, x, y):
        	print(f"CLASS: X: {x}, Y: {y}")

Display More

programm.py

Python

def touch_prog_press(x, y):
	print(f"MAIN: X: {x}, Y: {y}")
	

# Interrupt für den Touch umstellen auf "touch_main_press"
TOUCH.int_pin.irq(trigger=Pin.IRQ_FALLING | Pin.IRQ_RISING,
                  int_handler = touch_prog_press)

def prog_start(TFT, TOUCH):
	print("programm")

Mein Problem:
wenn ich main.py starte, reagiert der Pico auf den Touch, jedoch führt er die Funktion touch_class_press aus der hardware.py und nicht die touch_main_press aus der main.py aus.

Später sollen in der main.py vier Felder erstelt werden.
Wenn eines der Felder angetippt wird, soll ein weiteres Programm gestartet werde.
Der TFT und der Touch wird dann übergeben und der Interrupt für den Touch im Programm neu gesetzt werden.

ich hoffe, ich konnte mich verständlich ausdrücken.

Mein Gedanke ist, den Quellcode der einzelnen Programme (main, Hardwareconfig und Prog...) zu separieren und übersichtlicher zu gestallten.

Meine Fragen:
- Ist mein Gedankenansatz / Vorgehensweise richtig?
- wie kann ich, den Interrupt-handler für den TOUCH, im neuen Programm ändern?
- gibt es eine besser vorgehensweise?

grüße aus dem Sauerland

Stefan

- Imprtiert die hardware.py

Bot · Vor 5 Minuten

Interrupt vom Touch umstellen? Schau mal ob du hier fündig wirst!

__blackjack__ · July 3, 2026 at 2:03 PM

IC-Cruncher Das aufteilen auf Module die dann fast nichts enthalten, macht es eher unübersichtlicher. Was auch so gar nicht hilfreich ist dabei sind die *-Importe. Damit importiert man alles aus einem Modul, inklusive allem was dieses Modul aus anderen Modulen importiert, und wenn das auch per *-Import gemacht wird, stellt sich die Frage warum überhaupt in Module aufgeteilt wird, wenn die hinterher doch wieder alles enthalten zur Laufzeit.

Es macht auch nicht so viel Sinn Programmcode zu zeigen der gar nicht ”echt” ist, also welchen der gar nicht lauffähig ist. Es gibt beispielsweise kein Modul mit dem Namen py in einem Package mit dem Namen hardware. Gleich die erste Zeile würde also schon zu einem ImportError führen. Im hardware-Modul sind Syntaxfehler durch kaputte Einrückung. Das programm-Modul versucht ein TOUCH zu verwenden, das überhaupt nicht definiert ist also auch zu einer Ausnahme führt. TPUOUCH ist auch nirgends definiert.

Namen werden in Python per Konvention klein_mit_unterstrichen geschrieben. Ausnahmen sind Konstanten (KOMPLETT_GROSS) und Klassen (PascalCase). Grundsätzlich lohnt die Lektüre vom Python Style Guide.

Auf Modulebene sollte nur Code stehen, der Konstanten, Funktionen, und Klassen definiert. Das Hauptprogramm steht üblicherweise in einer Funktion die main() heisst.

So etwas wie TOUCH wird durch die Grossschreibung nicht auf magische Weise zu einer Konstanten. Das ist ein Objekt mit Zustand, der sich im Laufe des Programms ändert, also ist das nicht konstant. So etwas definiert man nicht global und greift von überall darauf zu. spi ist auch keine Konstante. Das ist nicht das erste was man in einem Modul definiert, sondern das wäre das erste was in der Hauptfunkion als lokale Variable definiert, und dann überall wo es benötigt wird, als Argument übergeben wird.

Die beiden Klassen sind im Grunde keine Klassen und in der __init__() noch mal ein Objekt vom Typ von dem man erbt zu erstellen, ist falsch. Das macht keinen Sinn, und kann hier konkret sogar zu Problemen führen wenn man beispielsweise zwei Display-Objekte hat, die auf den selben GPIO-Pins operieren.

Neben der Gross-/Kleinschreibung unterscheiden sich Klassen und Funktionen auch darin, dass Klassen Dinge (im weitesten Sinne) repräsentieren, und Funktionen Tätigkeiten. Und die werden deshalb auch entsprechend benannt. config_tft ist kein Ding, sondern eine Tätigkeit. Hier ist der Name aber treffend, also sollte das keine Klasse sein, sondern eine eine Funktion, die das Display-Objekt erstellt und Konfiguriert. Wobei das erstellen aus dem Namen ablesbar sein sollte. Also eher create_tft().

Bei config_touch macht IMHO nicht einmal eine Funktion Sinn, denn die würde ja nur ein Touch-Objekt erstellen. Das kann man aber auch einfach an der Stelle wo der Funktionsaufruf stehen würde, machen.

Namen sollten keine kryptischen Abkürzungen enthalten oder gar nur daraus bestehen. Bei BL habe ich mal geraten, dass das backlight heissen soll.

Zwischenstand (ungetestet):

Python

#!/usr/bin/env python3
from ili9341 import Display
from machine import Pin, PWM, SPI
from xpt2046 import Touch

#
# TODO Magische Zahlen wo möglich als sinnvoll benannte Konstanten definieren.
#


def create_display(spi):
    display = Display(
        spi, Pin(9), Pin(20), Pin(21), rotation=90, bgr=False, gamma=False
    )
    _backlight = PWM(Pin(15, Pin.OUT), freq=1000, duty_u16=0xFFFF)
    display.invert(True)
    display.clear()
    return display


def start_program(tft, touch):
    print("programm")


def on_touch_press(display, touch, x, y):
    print(f"MAIN: X: {x}, Y: {y}")
    # wenn x,y in einem bestimmten Bereich liegen
    print("Programm starten")
    start_program(display, touch)


def main():
    spi = SPI(0, baudrate=10_000_000, sck=Pin(18), mosi=Pin(19), miso=Pin(16))
    display = create_display(spi)
    touch = Touch(
        spi,
        Pin(8),
        Pin(22),
        lambda x, y: on_touch_press(display, touch, x, y),
        x_min=198,
        x_max=3979,
        y_min=292,
        y_max=380,
    )
    print("main-prog")


if __name__ == "__main__":
    main()

Display More

Für die paar Zeilen lohnt es sicher noch nicht, die auf drei Module aufzuteilen.

Sofern man nicht schon mit einer sinnvollen Aufteilung im Kopf startet, schreibe ich erst in einem Modul so lange, bis das zu lang wird. Üblicherweise so bei 1000 Zeilen. Und dann verschiebe ich das erst in ein Package, und da drin teile ich das dann in Module auf.

Ich würde wahrscheinlich auch den Handler nicht ändern, sondern einen universalen Handler schreiben, der eine Beschreibung von Bildschirmregionen + Handler für einen Druck dort, bekommt. Und diese Datenstruktur muss austauschbar sein, nicht der allgemeine Handler.

Edit: Ich habe mir mal die verwendeten, importieren Klassen angeschaut: Default-Werte sind dazu da, das man die nicht angeben braucht, wenn man den Wert gar nicht verändern will.

IC-Cruncher · July 3, 2026 at 9:44 PM

Hallo __blackjack__,

zunächst einmal danke für deine Ausführiche Antwort.
Mit einer so langen Antwort hatte ich nicht gerechnet.

ich habe mir den "Style Guide" angesehen und werde den durcharbeiten und umsetzen.

ich hatte, von meinem Gesamtcode, nur einen Teil herausgezogen.
Ich dachte das reichte, um mein Problem zu beschreiben.
Es ist jedoch ärgerlich, das da kleine Schreibfehler drin sind, die den Code verfälschen.
Sorry dafür.

Den Punkt mir main() kenne ich und im "richtigen" Quellcode setze ich dies um.
ich habe versucht das Thema mit den Klassen anzugehen und umzusetzen.
Deswegen ist das meiste in Klassen gesetzt.

Ich glauche, da ist noch viel (sehr viel) Luft nach oben.

Ich versuche einmal, mein Projekt genauer zu beschreiben.
Was habe ich überhaupt vor.

Ich habe mir eine kleinen "Gameboy" aus einem Pico2, einem TFT+Touch, zwei RGB-LED's und einem Buzzer gebastelt.
ich möchte eventuell auch die vier Taster auf dem TFT nutzen.

Zunächst soll auf dem TFT der Startbildschirm (main) mit vier Schaltflächen dargestellt werden.
Über die vier Schaltflächen soll jeweils ein Spiel (Prog_1, z.B. Memory..) gestartet werden.
Nach Beendigung eines Spiels, sollen wieder der Startbildschirm erscheinen.

Ich wollte den Code für die einzelnen Bereiche (Startbildschirm, Hardarekonfiguration und die Spiele) in einzlene Module aufteilen, damit ich mich pro Modul nur um die eigentliche Aufgabe kümmern kann. Ich dachte es würde den Code übersichtlicher machen.

Damit ich nur an einer Stelle die gesamte Hardeare konigurieren muss, habe ich dies in ein einzelnes Modul separieren. Das starten der Hardwarekonfiguration auf der Modulebene habe ich deswegen durchgeführt, damit die Hartware global zur Verfügung steht und ich nicht immer die gesmte Hardware übergeben muss.
Ebenfalls wollte ich die Spiele in einzelne Module legen, um den Spiele-Code einzeln bearbeiten zu können.
Ich jedem Modul (Startbildschirm und die Spiele), sollte der Interrupt des Touch zu eingestellt sein, das er eine eigene Funktion in dem jeweiligen Modul aufrufen.
So war es zumiondest angedacht.

Sind die Überlegungen falsch?

Wie würdest du prizipiell so ein Projekt aufbauen?
Bitte nicht falsch verstehen, ich möchte keine komletten Quellcode, den Quellcode möchte ich mir schon selber erarbeiten.

Ich habe meine drei Module etwas aufgeräumt und hoch geladen. Die Hardwarekonfiguration habe ich in die main-Funktion verschoben.
Ich habe in deinem Quellcode gesehen, das man eine Übergabe von Parameter mit dem Befehl "lamda" durchführen kann. Den kenn ich nich nicht.
Die Nomenklatur habe ich noch nicht korrigiert.
Ich habe, für mich, viel im Quellcode kommentiert und viele print() zum debuggen verwendet.
Bitte nicht komplett zerreißen.

main1.py
icc_hw_conf_v2.py
prog_1.py

Diese Module funktionieren, bis auf die Sache, das der Touch die Funktion aus der Hardware-Klasse aufruft. Da weiß ich nicht wie ich das machen soll/kann.

Gruß

Stefan

Bot · Vor einem Moment

Interrupt vom Touch umstellen

IC-Cruncher July 2, 2026 at 7:45 PM

Participate now!

Tags

IC-Cruncher July 2, 2026 at 7:45 PM

Participate now!

Tags

IC-Cruncher July 2, 2026 at 7:45 PM