Raspberry & TouchScreen KumanTech 35

Recentemente ho acquistato un display con touchscreen da integrare sul Raspberry Pi che mi controlla la stampate 3D. Così, giusto per poter fermare la stampa lanciata da web senza dover riprendere il computer.
Seguendo questa guida, con il touchscreen in mio possesso si arriva ad avere un sistema non funzionante, ovvero un bellissimo quanto affascinante schermo bianco.
Sul sito del produttore c’è un laconico “non aggiornate il kernel” ma, senza aggiornamento, addio browser Chromium.
Leggendo i log del kernel si nota che sia lo schermo che il touch cercano di prendersi lo stesso GPIO 17

pinctrl-bcm2835 3f200000.gpio: pin gpio17 already requested by spi0.1; cannot claim for spi0.0

e da qui è partita la mia ricerca.

Ho scoperto che succede la stessa cosa con un altro schermo di fascia economica, del tutto simile a questo: un’anima pia ha fatto un’analisi del driver di quest’ultimo con l’ultimo kernel disponibile per raspbian (4.9) e ha scoperto che esso prenota l’interrupt per il touchscreen e poi, quando il kernel carica nuovamente il driver del touchscreen come gli viene imposto nel file config.txt, tenta nuovamente di occupare lo stesso interrupt, non completando il caricamento dello schermo e nemmeno quello del touch.

La stessa cosa vale per questo touchscreen della Kuman.

In definitiva è bastato commentare la riga incriminata e tutto ha iniziato a funzionare come si deve!!

Ovvero:

dtoverlay=tft35a:rotate=90
#dtoverlay=ads7846,cs=1,penirq=17,penirq_pull=2,speed=1000000,keep_vref_on=1,swapxy=1,pmax=255,xohms=60,xmin=200,xmax=3900,ymin=200,ymax=3900

MySQL e Cronjob

Spesso capita di dover eseguire delle azioni ripetitive e, generalmente, ci si affida a Cron.
Cron è affidabile senz’altro ma, se l’operazione ripetitiva riguarda la manutenzione di alcune tabelle piuttosto che l’eliminazione di alcuni record (temporanei, di sessione), significa dover creare un script (in php, in python, in bash) che stabilisca una connessione al database ed esegua la query.
Ma fare questo significa impegnare il processore in tre processi:

  1. Crontab, che deve tener conto dell’azione da eseguire e di quando eseguirla
  2. L’interprete dello script, che dovrà leggere ed eseguire le vostre istruzioni
  3. MySQL, che eseguirà il vero e proprio lavoro

Ma non si potrebbe ridurre tutto a un singolo processo? Sì, basta delegare MySQL a fare tutto da se, ovvero con il suo scheduler. Leggi tutto “MySQL e Cronjob”