TiDiGino Contest: la prima soluzione!



Come abbiamo già comunicato, in considerazione della complessità del progetto, abbiamo spostato il termine per l’invio del software del TiDiGino Contest a fine novembre.
Nel frattempo, però, qualche concorrente ha già concluso il lavoro. È il caso del Sig. Daniele Denaro che ci ha inviato sia il firmware che un’interfaccia Java che (addirittura!) un manualetto completo.
Pubblichiamo di seguito la sua spiegazione ed il manualetto, rimandando la presentazione del firmware alla fine del concorso (… qualcuno potrebbe copiare).
Aspettiamo con ansia gli altri concorrenti, sperando che quanto scritto dal Sig. Denaro possa ispirare in qualche modo anche gli altri partecipanti.

Vi allego il software-firmware da me sviluppato sulla piattaforma da voi gentilmente fornita in omaggio.
Nel pacchetto allegato vi è:

  • Il firmware in formato sorgente (sketch Arduino)
  • Una applicazione di interfaccia in Java
  • Documentazione in formato manualetto pdf (+ commenti nei sorgenti)

Il firmware è stato suddiviso in moduli per maggiore maneggiabilità. Infatti è abbastanza complesso per un sistema “Arduino like” (circa 40kbyte l’eseguibile).
Poiché il firmware è sviluppato in ambiente Arduino, si tratta di partire comunque da uno sketch , che in questo caso ha il nome di: “TiDiGinoMain.pde“.
Questo sketch include, come prima cosa, 5 file C dedicati a funzioni specializzate. Mentre lo sketch principale realizza la struttura generale.
A causa del processo di compilazione automatizzato dall’ambiente di sviluppo Arduino, ho dovuto, per semplicità, utilizzare un path assoluto nel nome dei file da includere. Quindi, per prima cosa, questo path va aggiornato prima di compilare.
Gli altri file sono contenuti nella cartella “Moduli” e sono:

  1. Pins.c  :  Mapping dei pin di Arduino con nomi esplicativi utilizzati nei sorgenti e variabili globali.
  2. StateVariables.c  :  Variabili che definiscono lo stato ed il comportamento dell’hardware, mappati anche in EEPROM + le routine dedicate all’utilizzo dell’EEPROM
  3. Commands.c  :  Contiene le routine principali, cioè il parsing e l’esecuzione dei comandi.
  4. Phone.c  :  Routine specializzate all’utilizzo del modem GSM
  5. Utility  :  Routine utilizzate dagli altri moduli (in particolare da Commands.c)

L’applicazione Java (TiDiGinoW32.jar o TiDiGinoW64.jar), fornita a corredo, realizza una interfaccia di programmazione e gestione del controller TiDiGino.
Infatti, anche se nella filosofia del firmware, si può gestire il controller tramite un semplice terminale seriale (oltre che ovviamente tramite SMS), questa applicazione è predisposta per un più agevole controllo, gestendo in più un protocollo specializzato con il firmware per l’aggiornamento della configurazione. L’applicazione è in Java ma è utilizzabile solo in ambiente WINDOWS a causa della libreria ddl per la porta seriale. (Ci sono due versioni : per Windows32 e Windows64)
Ovviamente se non si vuole un reset ad ogni apertura del collegamento seriale, bisogna eliminare il ponticello JP2.

Caratteristiche principali del firmware:

  • I parametri del controller sono mantenuti in copia in EEPROM. In particolare le variabili di configurazione ed gli 8 telefoni manager sono caricati in copia anche in RAM. Mentre i 200 telefoni abilitati alla funzione di apri cancello sono gestiti solo in EEPROM perchè la copia in RAM portava a saturazione degli spazi dedicati allo stack. Ma, visto il tipo di utilizzo, i diversi tempi di accesso non hanno alcun impatto. La scrittura in EEPROM è eseguita in modalità “update condizionato”. Ovvero la riscrittura di un byte è effettiva solo se il byte è veramente cambiato. L’aggiornamento di un parametro è sempre eseguito contestualmente anche in EEPROM (non c’è una fase di aggiornamento cumulativo). Il tasto P2 è stato utilizzato come reset verso i valori di default. Ciò accade solo nel momento di startup , quando viene verificata la pressione sul tasto.
  • I comandi possono arrivare da SMS o da linea seriale (potrebbe essere in futuro anche WI-FI o Bluetooth). Il formato è lo stesso a meno del numero telefonico di provenienza, che nella seriale deve essere simulato premettendolo al comando con il separatore “#” (l’applicazione Java lo fa automaticamente). I comandi sono formati da un acronimo fisso di 3 caratteri, più un eventuale parametro e più una password in alcuni casi. La password deve essere separata dal comando con il carattere “:”. Nel caso di comandi da SMS, questi possono essere multipli (fino a 10) ma devono essere separati dal carattere “;”. (vedi manuale per maggiori dettagli)
  • Il parsing dei comandi utilizza un array di strutture composte da: codice comando + indirizzo della funzione dedicata (vedi Commands.c). Oltre ai comandi di utilizzo comune esistono 6 comandi specializzati utilizzati solo dall’applicazione Java su linea seriale per il downloading della configurazione ed il successivo uploading. Le funzioni per il controllo del numero telefonico originante e della password sono contenute in Utility.c.
  • Le password sono due. La prima serve per abilitare alcuni comandi in cui non è fatto il controllo del numero chiamante (per esempio per permettere l’inserimento di numeri abilitati). La seconda è stata aggiunta per permettere l’auto inserimento del proprio numero nella lista degli apricancello. In questo modo è possibile consegnare una password ai candidati che possono provvedere da soli (ma solo per questo). La seconda password può essere disabilitata in ogni momento ponendola a “000000”. La password principale agisce in alternativa al controllo del numero originante (in questo modo è possibile inserire i primi numeri), ma solo per alcuni comandi. In ogni caso è possibile abilitare una funzionalità di extra sicurezza in cui viene fatto anche il controllo sul numero originante (ma per default ciò è disabilitato). L’abilitazione può essere fatta solo tramite l’applicazione Java.

Problemi e varie:

  • Naturalmente il testing è sempre una attività notevolmente “time consuming” , per cui ho cercato di provvedere da solo come potevo. Mi sembra che non ci siano errori, ma mi aspetto un feed-back.
  • In realtà alcuni problemi sono tuttora presenti e riguardano il modem GSM ma non sono in grado di risolverli senza una attrezzatura adeguata a meno di spendere molti soldi in bollette telefoniche :-). In sostanza ho verificato che, con chiamata dal mio telefonino, il controller non riesce ad aprire la comunicazione per il controllo DTMF, mentre non ho nessun problema con il fisso. Ovvero non riesce il comando “ATA”, anche se la telefonata è stata correttamente rilevata in arrivo. Anche la verifica del ring dà esito negativo. Usare una sim originariamente inserita in una “pennetta GPRS” può spiegare? Ma allora perchè non da fisso? In ogni caso la modalita SMS non ha problemi come pure le chiamate originate dal controller per gli allarmi o la modalità apricancello. Non ho avuto modo di controllare con altri telefonini. Per favore fatemi sapere qualche cosa. Non sono propriamente un esperto di TLC e non usavo i comandi AT dal tempo dei primi modem per computer. Problema minore sono i toni DTMF prodotti dal controller. Non avendo un monitoraggio diretto dei toni prodotti, questi, forse, sono un po’ approssimativi (mi sarebbe piaciuto usare una codifica più precisa, magari utilizzando potenzialità che ho intravisto in alcuni comandi del SIM900, ma occorrerebbe una possibilità di ascolto diretto ed il tempo è poco).
  • Un altro problema è lo start-up. Nell’ottica di un controller che dovrebbe ripartire senza problemi nel caso di  mancanza di alimentazione elettrica,  ci vorrebbe una ripartenza garantita, ma qualche volta ci sono problemi con l’accensione del modem, e va attivato più volte il reset P1. Insomma dovrebbe essere garantita la ripartenza automatica, ma ancora non è così (va migliorato lo start-up del modem). (una curiosità: nel manuale SIM900 è prescritto obbligatoriamente di non lasciare libero il pin dell’alimentazione del RTC contenuto; ma non sono riuscito a capire se è collegato ad un condensatore; può essere un problema?)
  • Per sviluppi futuri, ho già accennato alla possibilità di ulteriore utilizzo tramite collegamento WI-Fi o Bluetooth. Inoltre si potrebbe sfruttare anche l’orologio interno del SIM900 a patto di alimentarlo con una batteria sulla linea dedicata. Rimane inutilizzata la memoria seriale EEPROM. (Avviso vocale invece che toni?). Infine  il sensore di temperatura forse è troppo vicino all’hardware. Infatti rilevo che dopo alcuni minuti di funzionamento segnala una temperatura un po’ sovrastimata (un paio di gradi) (anche se l’hardware non dovrebbe scaldare molto).

Qui è possibile scaricare il manuale fornito.

Complimenti vivissimi da parte di tutta la Redazione!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ricevi un avviso se ci sono nuovi commenti. Oppure iscriviti senza commentare.