Debug di uno script con due led…


… ovvero la mia esperienza con il modulo GSM/GPRS EZ10 Terminal QUAD-PY della Telit.
Il modulo e’ un bell’oggetto da un centinaio di Euro, con una porta RS232, 4 linee GPIO configurabili via software e, in questa versione, l’interprete Python (versione 1.5.2+) all’interno.
Il contesto di utilizzo e’ il seguente: una scheda elettronica, preposta all’attivazione o meno di uscite in base all’iterazione con l’utente, ha due ingressi di allarme, ai quali e’ possibile collegare degli attuatori che si attivano in caso di situazioni ritenute di emergenza. Il firmware di gestione della scheda controlla lo stato degli ingressi (ovviamente optoisolati) di allarme, e lo riporta su due delle quattro linee GPIO del modulo Telit.
All’interno del modulo gira il mio script Python, script che viene eseguito ad ogni avvio del modulo stesso. Lo scopo dello script e’ il controllo delle linee GPIO di allarme, in modo da notificare via SMS a due numeri di cellulare gli eventi su queste linee con i messaggi di testo relativi.
La comunicazione tra l’interprete Python e parser dei comandi AT avviene internamente tramite una linea seriale virtuale utilizzabile all’interno dello script tramite le funzioni del modulo MDM, quindi ,tempistiche a parte, e’ come se si parlasse direttamente sulla linea seriale fisica del modulo inviando direttamente i comandi AT. L’interprete mette a disponizione altri due moduli, oltre al builtin, e cioe’ SER per la gestione della seriale fisica e MOD con un paio di funzioni per la gestione dei tempi.
La procedura di inserimento dello script e’ piuttosto macchinosa: bisogna collegarsi via seriale al modulo (ho utilizzato Hyperterminal, e fa veramente pieta’…) impostando il baudrate a 115200, N81 per parita’ e stopbit, e controllo di flusso hardware, poi digitare AT#WSCRIPT=”[nomefile.py]”,[dimensioni in byte del file] , attendere il prompt “>>>”, selezionare il menu “Invia file di testo”, selezionare il file da inviare e attendere la risposta di “OK”, poi abilitare il file .py “uploadato” con il comando AT#ESCRIPT=”[nomefile.py]”, e attendere “OK” per la conferma. Per eseguire lo script sul modulo basta chiudere la comunicazione da Hyperterminal e spegnere e riaccendere il modulo.
E ora cominciano i problemi, almeno nel mio caso…
Ho provato il classico “Hello world!”, e cioe’ in questo caso la stampa della stringa sulla seriale fisica del modulo (ovviamente connessa al pc), ma non ho visto arrivare niente, e mi sono chiesto “Ma lo script e’ partito? Ma ho forse fatto qualche errore di digitazione? COME FACCIO IL DEBUG?”. E il punto e’ proprio questo, il debug dello script. Certo, errori di sintassi li posso escludere facendo leggere lo script da un qualche tool di controllo, ma se per caso (come mi e’ successo…) scrivo MDM.sleep(10), che non esiste, al posto di MOD.sleep(10), come me la sbrigo??
La soluzione che ho utilizzato e’ stata quella di collegare esternamente due led alle porte GPIO rimaste libere per avere un piccolo feedback dallo script, ma vi assicuro che e’ stata veramente dura arrivare alla fine, un minimo di informazioni le potevano mettere, almeno per i traceback generati dal Python!
Comunque alla fine ci sono arrivato, lo script si comporta bene, e i messaggi arrivano che e’ una meraviglia.
Nonostante cio’ pero’ non posso esprimere un parere positivo al 100%, ritengo che questo oggetto possa andare bene per un eventuale sistema di dimostrazione, ma la macchinosita’ di programmazione (del modulo, non del Python) non lo rende l’ideale in produzione: una scheda di gestione con una seriale libera e un microcontrollore adeguato avrebbe compiuto meglio il lavoro.

Alla prox