Se stai leggendo questo articolo e, per caso, hai già provato a sviluppare qualche applicazione per Uebbi/Webby, allora puoi comprendere perché ho messo la parola "impazzire" nel titolo!

Sia chiaro, il procedimento di programmazione con Uebbi, non è più complesso che con altri dispositivi ed è anche ben documentato - vedi a questo proposito l'ottima guida sul sito di Franco Bersani Uebbi – Indicazioni su come sviluppare il firmware - ma, a meno che non siate dei geni della programmazione e siate in grado di scrivere un programma al primo colpo senza errori che funziona esattamente come vi aspettavate, allora (anche solo per cambiare una virgola) dovrete ripetere un numero innumerevole di volte tutto il processo di:

• Conversione del filesystem in un archivio in formato cramfs o yaffs2 (a seconda dei casi).
• Trasferimento del file su supporto SD o USB
• Riavvio, aggiornamento, riavvio.
• Test.

Il tutto, mediamente, richiede una decina di minuti.
Fate un pò il conto di farlo per una trentina di volte e, se alla fine non vi è venuto un esaurimento nervoso, allora eravate già pazzi prima!

Il problema fondamentale è che il filesystem in cui sono installate le applicazioni è in sola lettura e, da questo, derivano tutta una serie di complicazioni.

Se però potessimo creare una copia di "debug" delle nostre applicazioni in un filesystem scrivibile dove ci sia abbastanza spazio ed avviare da qui la GUI del Webby? Vediamo come si fa:

Per prima cosa occorre disporre dei privilegi amministrativi sul dispositivo (utente "root"). Vedere la guida per attivare le "Opzioni sviluppatore" di Webby.

Una volta entrati nel sistema come "root", facciamo una copia dei file presenti in /usr/prizm_mid mantenendo i permessi originali (opzione "-p").

# cp -rp /usr/prizm_mid /root/DEBUG

Ora creiamo un nuovo script di avvio della Webby GUI dedicato al debug. Personalmente io utilizzo il "vi" come editor ma, se non avete dimestichezza con il vi, potete anche usare il comando "cat > nomedelfile" e fare copia/incolla del testo nella finestra, chiudendo poi il file con [CTRL+D]
NOTA: Potete trovare eventuali aggiornamenti dello script qui: DEBUG.sh

# cd /root/DEBUG/milano
#
# cat > DEBUG.sh
#!/bin/sh
################################################################################
# file: /root/DEBUG/milano/DEBUG.sh
# auth: andreoidb64
# date: 20160429
#
#
################################################################################
 
case $1 in
-start) cd /root/DEBUG/milano
        while sleep 2; do sync; done &
        ./run.sh
        exit
        ;;
 -stop) killall python2.5
        killall msd
        killall fbserver
        exit
        ;;
     *) ;;
esac
 
### Edit your project and remove ".PYC" compiled before run Webby in debug env.
# vi /root/DEBUG/milano/launcher/manager/netmgr.py
# rm /root/DEBUG/milano/launcher/manager/netmgr.pyc
 
### Remove logs before run Webby in debug environment (if needed)
# rm /root/user_data/log/*
 
$0 -stop
sleep 2
nohup $0 -start 1>/root/user_data/log/WebbyDebugMode.log 2>&1 &

[CTRL+D]

Quindi diamo i diritti di eseguibilità al file:

# chmod a+x DEBUG.sh

Per riavviare Webby in modalità "debug", basta eseguire lo script

# /root/DEBUG/milano/DEBUG.sh

Il programma arresta tutte le istanze attive di python e della GUI per riavviarle dal filesystem di /root/DEBUG che abbiamo creato.

E' IMPORTANTE SAPERE CHE:
Quando Uebbi si avvia, l'interfaccia di rete viene arrestata e riavviata. Di conseguenza, anche la nostra sessione telnet si chiude. Per questo motivo lo script di avvio "./run.sh" non può essere avviato banalmente da telnet, altrimenti Uebbi andrebbe in crash per l'interruzione del processo padre.
Occorre adottare alcuni accorgimenti particolari per evitare che vada in crash (vedi l'avvio in modalità nohup e background "&").
Per lo stesso motivo, anche i log di esecuzione (std-out e std-err) vengono redirezionati su un file di appoggio (/root/user_data/log/WebbyDebugMode.log) per evitare di perdere queste informazioni per la mancanza di connessione.
Ancora, sempre per evitare di perdere informazioni di log dovuti a crash del sistema, viene eseguito il comando "sync" ogni 2 secondi. Se non si è troppo sfortunati, anche in caso di crash, al riavvio successivo potremo andare a vedere nel file di log gli eventi registrati prima del crash.

Un altro problema che si ha con Uebbi è quello di riuscire a reperire la versione dell'ambiente di sviluppo compatibile con l'ambiente di esecuzione, questo se si vogliono compilare i programmi.
Se però il programma sorgente (estensione ".py") viene salvato su un filesystem scrivibile, allora è lo stesso python che si occupa di creare il corrispondente file compilato (estensione ".pyc") alla prima esecuzione del sorgente.
In pratica, con questo metodo, nella maggioranza dei casi, non abbiamo necessità di procurarci e installare un ambiente di sviluppo dedicato.

NOTA: Se esiste il file ".pyc", le modifiche fatte al corrispondente file ".py" vengono ignorate. Ricordatevi di cancellare il file compilato quando modificate il sorgente!

Buon divertimento!