Telecontrollo con GSM Shield: il nostro shield per moduli SIMCom e Quectel (parte 1)

Emuliamo i telecontrolli della serie TDG utilizzando il GSM Shield.

Non è passato molto tempo da quando abbiamo presentato il nostro shield GSM per moduli GSM/GPRS SIMCom, QUECTEL, FIBOCOM ecc. che nasce per essere inglobato in progetti basati su Arduino che implicano la connettività cellulare; ora è venuto il momento di passare alla prima applicazione pratica, che nel caso specifico consiste nel replicare il funzionamento del telecontrollo GSM bidirezionale TDG133, pubblicato nel fascicolo n° 148 del lontano luglio 2010, il quale permette di gestire due uscite a relé e due ingressi a livello di tensione. Per l’occasione abbiamo sviluppato una serie di comandi utili a impostare le funzioni base sia attraverso l’invio di SMS sia attraverso l’invio di comandi attraverso il monitor seriale dello IDE Arduino. Sia l’elettronica che lo sviluppo firmware sono basati sulla scheda Arduino Mega 2560 o Fishino Mega 2560. Questo per motivi di memoria Flash e SRAM disponibile per l’applicazione ma soprattutto per la disponibilità di pin di I/O liberi per lo sviluppo del progetto.

La piattaforma su cui andremo a sviluppare la nostra applicazione è Arduino Mega 2560, ampiamente supportata dallo shield GSM, in quanto è l’unica a poter fornire una serie di I/O necessari alla gestione dei segnali di ingresso e uscita; nello specifico, l’applicazione qui proposta necessita di:
• due I/O per gestire le uscite digitali, almeno nell’applicazione base, però il progetto supporta fino a otto uscite digitali e quindi considera l’uso di otto linee di I/O;
• due I/O per gestire gli ingressi digitali, che possono essere configurati per lavorare come attivi a livello alto o basso o sulla variazione; in realtà si rendono disponibili fino a otto linee di ingresso;
• per quanto riguarda i LED di segnalazione si sfruttano quelli già presenti sulla demoboard GSM.

Per la logica di funzionamento si fa riferimento al telecontrollo TDG133, del quale replicheremo le funzionalità compatibilmente all’hardware disponibile. Ricordiamo che TDG133 è un modulo di telecontrollo bidirezionale che permette di controllare da remoto lo stato di due uscite a relé, in modalità bistabile o monostabile, mediante l’invio di appositi SMS completati da password. Inoltre consente di acquisire lo stato di due input optoisolati.

I comandi possono provenire da numeri telefonici memorizzati in una lista di un massimo di otto numeri ai quali il dispositivo invia SMS e chiamate vocali quando ritiene attivati, in base alle impostazioni effettuate in fase di configurazione, gli ingressi digitali. Il telecontrollo TDG133 può anche funzionare da apricancello, modalità alla quale possono essere abbinati fino a 200 numeri di telefono.

Schema a blocchi hardware

Stabilito cosa faceva il TDG133 sappiamo anche cosa deve fare il nostro progetto, che quel sistema deve emulare mediante hardware Arduino o compatibile. Lo schema a blocchi in Fig. 1 fornisce un’idea dell’elettronica da cui è composto il nostro telecontrollo basato sul GSM Shield.

Come il TDG133, anche questo telecontrollo mette a disposizione due ingressi digitali e due uscite a relé. Nella nostra applicazione mettiamo a disposizione fino a otto ingressi digitali, che possono essere attivi a livello alto o basso e otto uscite digitali utili a pilotare fino a un massimo di otto relé; in realtà tale disponibilità è hardware, perché il firmware attuale dell’Arduino Mega 2560 permette di gestire solo due ingressi digitali e due uscite digitali e chi desidera sfruttare tutte e 8 le linee dovrà mettere mano al codice.

Fig. 1 Schema a blocchi hardware.

Lo schema a blocchi evidenzia la logica con cui è stata sviluppata l’applicazione.
• La scheda Shield Telecontrollo, evidenziata con un quadrato verde, viene montata sul GSM Shield, il quale a sua volta è innestato sulla Arduino Mega 2560.
• Lo Shield Telecontrollo mette a disposizione fino a otto ingressi digitali e mediante jumper board-to-board è possibile selezionare se l’ingresso è attivo a livello logico alto, quindi si deve inserire il pull-down, oppure è attivo a livello logico basso e quindi si deve inserire il pull-up. È possibile generare l’evento portando l’ingresso desiderato a GND o a +5Vdc. Per fare ciò si possono usare i soliti cavetti jumper da laboratorio come ad esempio il codice FuturaShop “7300-JUMPER50”.
• Lo Shield Telecontrollo mette a disposizione fino a otto uscite digitali con le quali si possono comandare le schede con due, quattro o otto relé; tali schede montano tutte relé con tensione di bobina +5V. In questo caso si fa riferimento ai prodotti “2846-RELAY2CH”, “2846-RELAY4CH” e “2846-RELAY8CH” della Futura Elettronica. Anche per collegare le schede a relé vanno utilizzati cavetti jumper.
• L’alimentazione allo Shield Telecontrollo può arrivare sia dalla Arduino Mega 2560 tramite cavo USB type B, oppure dalla presa micro-USB del GSM Shield, tramite cavo micro-USB.
• Il collegamento tramite cavo USB type B permette anche la programmazione della scheda Arduino Mega 2560, nonché di mandare i comandi di configurazione tramite il monitor seriale dello IDE Arduino. Tramite il monitor si possono anche ricevere informazioni sullo stato degli eventi intercettati durante il funzionamento, invio e ricezione SMS ecc.
• Se si desidera monitorare i comandi AT inviati dalla Arduino Mega 2560 al modulo GSM si può utilizzare il consueto convertitore USB/TTL (cod. FT782) collegato ad apposito connettore presente sul GSM Shield. L’elettronica dell’FT782 permette anche di portare l’alimentazione a 5Vcc al GSM Shield.

Schema elettrico

Lo schema elettrico del GSM Shield è stato già pubblicato nel fascicolo n° 231, quindi qui descriveremo solo il circuito dello Shield Telecontrollo, il cui schema elettrico è mostrato in queste pagine; si tratta di qualcosa di molto semplice che prende le connessioni della porta PA0÷7 di Arduino Mega 2560 e tramite jumper on-board le distribuisce per la gestione delle linee digitali di uscita usate per pilotare i relé. Inoltre prende i segnali della porta PL0÷7 della Mega 2560 per la gestione delle linee digitali di ingresso. Queste linee si trovano tutte sul connettore da 36 poli (18 poli x 2 linee) di Arduino Mega 2560 al quale sono anche connessi i sei LED montati sullo Shield Telecontrollo e destinati a scopi generici (Porta PC0÷7).

Per quanto riguarda gli ingressi digitali è possibile impostare se devono essere attivi con livello logico alto o basso. La selezione della modalità di funzionamento avviene tramite jumper (J1÷8) e in particolare se il jumper è inserito nella posizione 1-2 si inserisce il resistore di pull-up da 10 kohm e quindi l’ingresso è attivo a livello basso, mentre se il jumper è nella posizione 2-3 si inserisce il resistore di pull-down da 10K e quindi l’ingresso è attivo a livello alto.

Per ogni ingresso è stato predisposto un punto di contatto riportato sul connettore CN5 da utilizzare, tramite i cavetti jumper, per attivare l’ingresso corrispondente ovvero +5V se attivo alto o GND se attivo basso. Abbiamo quindi predisposto altri due connettori da 8 poli ciascuno, siglati CN1 e CN2, ai quali abbiamo portato rispettivamente le linee +5Vcc e GND. In questo modo, per ognuno degli otto ingressi esiste un corrispondente punto +5Vcc o GND da utilizzare per la simulazione della variazione di stato sull’ingresso.

Per quanto riguarda le uscite queste sono state semplicemente riportate sul connettore CN4 assieme alla linea +5V e GND necessarie ad alimentare le schede relé ausiliarie da utilizzare per questa applicazione.

Per completare la scheda demo abbiamo inoltre riportato le linee libere, presenti sugli altri innumerevoli connettori di Arduino Mega 2560, in modo da dare all’utente finale la possibilità di utilizzarne la funzione ad essi associata. Tutte le linee già occupate per la gestione della scheda GSM non sono riportate.

Al fine di rendere più versatile la scheda demo abbiamo anche predisposto una sezione sul PCB che funge da sezione di sviluppo prototipale dove gli utenti possono montare dei componenti a piacere per sviluppare le proprie applicazioni. Il passo tra un pad e l’altro è il consueto 2,54mm. Tale zona mette a disposizione oltre 315 pad singoli liberi da potenziale, più una serie ridotta di pad cui sono state portate le linee +3V3, +5V e GND.

Fig. 1 Schema a blocchi hardware.

Realizzazione pratica

Per il progetto bisogna preparare lo Shield Telecontrollo, ovvero realizzare il relativo circuito stampato partendo dalle tracce lato rame scaricabili dal nostro sito www.elettronicain.it insieme ai file del progetto. Durante la fase di montaggio dei pochi componenti presenti si consiglia di partire dalle resistenze SMD 0603 per poi passare ai connettori a 3 poli dei jumper, seguiti dai connettori CN1, CN2, CN4 e CN5. Infine montare e saldare i connettori di interfacciamento schede ovvero CN3, CN6, CN8, CN10, CN12, CN14 e CN15.

Con questi si conclude l’assemblaggio della scheda prototipale non resta che montarla sopra la nostra scheda GSM e procedere con l’implementazione dello sketch da caricare nel microcontrollore Atmega 2560 della Arduino Mega 2560.

Piano di montaggio

Elenco Componenti:

R1, R2, R3, R4, R5, R6, R7, R8, R9,
R10, R11, R12, R13, R14, R15, R16:
10 kohm (0603)
CN8, CN10, CN12, CN14, CN15:
Strip Arduino 8 vie (5 pz.)
CN6: Strip Arduino 10 vie (1 pz.)
CN3: Strip Ardunio 2x18 vie (1 pz.)
CN1, CN2, CN5: Strip maschio 8 vie
(3 pz.)
CN7: Strip femmina 10 vie (1 pz.)
CN9, CN11, CN13, CN16: Strip
femmina 8 vie (4 pz.)
CN4: Strip maschio 10 vie
(1 pz.)
J1, J2, J3, J4, J5, J6, J7, J8:
Strip maschio 3 vie (8 pz.)
Varie:
- Jumper (8 pz.)
- Circuito stampato

Lo sketch

L’architettura su cui si basa la nostra applicazione prevede di sfruttare la EEPROM presente sull’ATmega 2560 per la memorizzazione di una serie di parametri, tra cui gli SMS da inviare in caso di allarme e la memoria della SIM, inserita nel modulo GSM, per quanto riguarda la memorizzazione dei numeri di telefono abilitati alla gestione del sistema di telecontrollo.

Abbiamo fatto questa differenziazione perché, anche se ben ampia, la EEPROM dell’ATmega 2560 non è abbastanza capiente da memorizzare tutti i 208 numeri di telefono gestibili dal telecontrollo. Si è quindi deciso di sfruttare la memoria messa a disposizione dalla SIM per la memorizzazione in rubrica dei numeri di telefono, con relativa descrizione, come si fa nei comuni telefoni cellulari. Questo approccio ci offre anche l’opportunità di mostrare come sfruttare le funzioni di libreria create per la gestione dei comandi AT necessari alla lettura, scrittura o cancellazione della rubrica telefonica.

Due sketch in un unico file

Fatta questa breve premessa possiamo iniziare con la descrizione di come è stato strutturato lo sketch che contiene il codice di gestione del telecontrollo. Per prima cosa osserviamo che il codice in realtà contiene non uno ma ben due sketch che, ovviamente, non funzionano in simultanea. Questo è reso possibile dal fatto che esiste una direttiva al compilatore che ci permette di selezionare se utilizzare il codice di programmazione dei parametri di fabbrica nella EEPROM dello ATmega 2560 oppure se si desidera attivare il codice di gestione del telecontrollo. La direttiva che ci permette di selezionare quale sketch fare girare è la seguente:

#define WRITE_DEFAULT_DATA_EEPROM

Tale direttiva si trova in testa al file “GSM_TDG133.ino”. Quando questa direttiva è commentata viene compilato ed eseguito il codice del telecontrollo, viceversa viene compilato ed eseguito il codice inerente la programmazione dei parametri di default nella memoria EEPROM. Il codice di programmazione dei parametri non resetta la rubrica presente sulla SIM inserita nel modulo GSM. La cancellazione di eventuali numeri di telefono presenti nella rubrica viene fatta inviando apposite stringhe di comando le quali vengono interpretate e gestite dal codice del telecontrollo che di conseguenza invierà appositi comandi AT per cancellare uno o tutti i contatti presenti nella SIM.

La mappatura della EEPROM

Il codice che si occupa della programmazione dei parametri di fabbrica sulla EEPROM si trova nel file “_SetupEeprom.ino” dove in testa allo stesso troviamo, in forma tabellare, la mappatura della memoria EEPROM con indicato dove sono memorizzati i dati e quanto occupano in memoria.

Questa mappatura è pensata per gestire i testi dei due allarmi di ingresso (Ingresso 1 e 2) e i relativi parametri di gestione degli stessi nonché la abilitazione/disabilitazione di invio SMS ai primi otto numeri in rubrica. Vediamo la mappatura nella Fig. 2. Come si può notare, avanza dello spazio per aggiungere nuovi messaggi di testo nel caso in cui si decida di espandere la sezione di ingresso da due a otto ingressi totali.

Fig. 2 Contenuto della memoria EEPROM.

Il flow-chart di programmazione

La Fig. 3 propone il diagramma di flusso dello sketch di programmazione della EEPROM, dove si susseguono gli step di seguito descritti:
• Tramite apposite funzioni di libreria si ricavano gli indirizzi di partenza in EEPROM per la gestione dei codici PIN, PUK ecc. usati dalla nostra libreria per moduli GSM; guardando la tabella con la mappatura della EEPROM si vede che i codici in esame si trovano in testa.
• Segue un’altra funzione di libreria per attivare la seriale usata per il debug. Ovvero la seriale che permette, tramite il monitor seriale di Arduino IDE, di ricevere una serie di informazioni da parte dello sketch in esecuzione ed eventualmente inviare stringhe di comando allo sketch.
• Prima di impostare i valori predefiniti viene eseguita una funzione che resetta il contenuto della memoria EEPROM ovvero pone a 0x00 tutte le locazioni di memoria che hanno in essa memorizzato un valore diverso.
• L’impostazione dei parametri di fabbrica inizia quindi con la scrittura dei codici PIN, PUK ecc.
• Segue la funzione per memorizzare la password di sistema (valore predefinito “12345”).
• Segue il salvataggio dei flag.
• Infine vengono memorizzate le stringhe usate per l’invio degli SMS.
• Il sistema attende due secondi e poi esegue una rilettura completa di tutta la EEPROM al fine di verificare che il suo contenuto corrisponda ai valori di fabbrica appena programmati; per prima cosa vengono stampati sul monitor seriale i parametri predefiniti in formato stringa con una breve descrizione del contenuto, cui segue una rilettura della EEPROM e relativa stampa sul monitor seriale in formato esadecimale + ASCII.

Fig. 3 Flow-chart del firmware di sistema.

Il contenuto della EEPROM

Come si vede nella Fig. 2, in testa al contenuto della EEPROM ci sono i codici PIN, PUK ecc. necessari alla nostra libreria GSM, segue la password di sistema (Indirizzo di partenza in EEPROM: 0x0050). Infine vengono visualizzate le stringhe da usare per l’invio degli SMS. Sotto ai dati esposti viene poi riportato tutto il contenuto della memoria EEPROM a partire dall’indirizzo 0x0000 fino all’indirizzo 0x0FFF. Ora se la direttiva:

#define WRITE_DEFAULT_DATA_EEPROM

viene commentata, viene compilato ed eseguito lo sketch principale contenente il codice del telecontrollo che andremo ora ad analizzare.

L’inizializzazione: void setup()

Torniamo ora allo schema di flusso di Fig. 3 e studiamolo a partire dalla funzione “void setup()” la quale serve per inizializzare la libreria GSM e a pre-caricare in memoria una serie di parametri memorizzati in EEPROM. Quindi durante l’inizializzazione:
• tramite apposite funzioni di libreria si ricavano gli indirizzi di partenza in EEPROM per la gestione dei codici PIN, PUK usati dalla nostra libreria;
• avviene la configurazione del timer 5 usato dallo sketch per la gestione delle variabili temporali come i timer usati per il debouncing degli ingressi digitali, timeout per la gestione dei tempi di attesa ecc. (la base dei tempi usata per il timer è di 2ms);
• avviene la configurazione degli ingressi digitali usati per la realizzazione dello sketch;
• si esegue la configurazione delle uscite digitali usate per la realizzazione dello sketch, nonché le uscite digitali usate dalla libreria GSM per la gestione dei LED ad essa collegati;
• si esegue la routine di test sui LED presenti sul GSM Shield;
• si impostano gli interrupt sfruttati dalla libreria GSM per il suo corretto funzionamento;
• si abilita e si configura l’interfaccia UART usata per il debug tramite Arduino IDE Serial Monitor;
• si abilita e si configura l’interfaccia UART usata per l’invio dei comandi AT al modulo GSM;
• si accende il modulo GSM e si avvia la macchina a stati necessaria alla sua corretta gestione.

Segue la lettura in EEPROM dei parametri usati nello sketch, come ad esempio:
• password di sistema; valore predefinito “12345”;
• flag di sistema tra cui l’abilitazione agli SMS di notifica allarme e relative chiamate vocali;
• tempi di inibizione degli ingressi digitali;
• tempi di osservazione degli ingressi digitali;
• numero massimo di SMS da inviare in caso di allarme ingressi;
• numero di telefono cui inviare gli SMS ECHO;
• timeout funzione apricancello.

Sempre durante l’inizializzazione, si esegue l’impostazione iniziale dello stato degli ingressi digitali di allarme e l’impostazione di tutte le macchine a stati usate per la gestione dello sketch e relative funzioni. Conclusa l’inizializzazione, il sistema entra nel main e viene eseguito all’infinito il contenuto della funzione “void loop()”.

Il ciclo principale: void loop()

Vengono quindi eseguite:
• lettura stato ingressi digitali di allarme e relativo debouncing;
• gestione delle funzioni associate agli ingressi digitali di allarme;
• gestione delle uscite digitali usate per la gestione dei relé;
• gestione delle macchine a stati inerenti la libreria GSM sia durante la fase di inizializzazione del modulo GSM sia durante la gestione a regime per l’invio dei comandi AT necessari al funzionamento dello sketch.

Seguono tutte le funzioni e macchine a stati per la gestione di tutte le funzioni messe a disposizione dal telecontrollo:
• comandi per la configurazione del telecontrollo inviati attraverso il monitor seriale;
• comandi per la configurazione del telecontrollo inviati tramite SMS;
• invio degli SMS a seconda dell’evento registrato;
• esecuzione chiamata vocale a seconda dell’evento registrato;
• gestione della funzione ECHO, se abilitata;
• gestione delle funzioni apri cancello;
• gestione dei LED a seconda dell’evento registrato.

La gestione della macchina a stati GSM

Nel dettaglio, esaminiamo il funzionamento della funzione “void ProcessStateMachineGsm(void)”. In testa alla funzione abbiamo il codice, già usato in passato, per la gestione della libreria GSM e le sue funzionalità il quale, tramite un costrutto condizionale “if – else”, determina se sta eseguendo l’inizializzazione del modulo GSM o se è a regime e quindi pronto all’elaborazione dei comandi AT inviati dallo sketch al modulo GSM. Quindi, guardando lo schema a blocchi, se è in esecuzione l’inizializzazione, tutto il codice a valle del blocco condizionale non verrà eseguito.

Conclusa l’inizializzazione il processo potrà quindi avanzare e processare le funzioni di libreria per la gestione dei comandi AT necessari allo sketch più tutte le altre funzioni necessarie alla realizzazione dell’applicazione in esame. Di seguito il codice che distingue il processo di inizializzazione dal processo a regime:

Gsm.ExecuteUartState();
if (Gsm.GsmFlag.Bit.GsmInitInProgress == 1) {
Gsm.InitGsmSendCmd();
Gsm.InitGsmWaitAnswer();
} else {
Gsm.UartContinuouslyRead();
Gsm.ProcessUnsolicitedCode();
Gsm.GsmAnswerStateProcess();
**** User code used to develop the sketch ****
}

Come si vede il costrutto “if – else” contiene una serie di chiamata a funzione di libreria tra le quali una è chiamata sempre perché si trova fuori dal costrutto “if – else” ovvero “Gsm.ExecuteUartState();” che si occupa di gestire la macchina a stati della comunicazione seriale tra Arduino Mega 2560 e il modulo GSM montato sulla board. Le altre funzioni sono dipendenti dal valore assunto dal flag “Gsm.GsmFlag.Bit.GsmInitInProgress”. Una parte del codice utente, dipende che cosa si deve fare, può essere posta all’interno della sezione “else”. Di solito si mettono tutte quelle funzioni che necessitano di inviare un comando AT al modulo GSM e che quindi devono per forza di cose essere eseguite quando il sistema è arrivato a regime e non prima.

La registrazione del primo numero di telefono

Continuiamo con l’analisi del flow-chart; superata l’inizializzazione ci si trova a dovere gestire una serie di possibili situazioni tra cui la prima chiamata vocale in ingresso per la registrazione del primo numero di telefono della lista. Lo sketch, all’avvio analizza la rubrica della SIM alla ricerca di un numero di telefono valido nella prima locazione di memoria. Se non trova niente, per cinque minuti resta in attesa di una chiamata fonica in ingresso, da un numero qualsiasi, il quale verrà registrato nella rubrica del telefono come “ADMIN”.

Non è obbligatorio ma è sempre buona norma registrare un numero di telefono in rubrica abbinato a un testo descrittivo in quanto quando si riceveranno SMS o chiamate foniche in ingresso in automatico il modulo GSM ci ritornerà una stringa di testo con in testa la dicitura “+CLIP” a indicarci se il numero di telefono è presente o no in rubrica. Se la stringa, oltre al numero di telefono, contiene anche la descrizione abbinata avremo la conferma che tale numero è registrato. Con queste informazioni poi diventa facile stabilire in quale locazione di memoria si trova il numero per capire se fa parte dei primi otto o se invece è uno dei numeri di telefono con solo funzione apri-cancello. Il fatto di ricevere un “Unsolicited Result Code” da parte del modulo GSM dipende dal tipo di configurazione che la nostra libreria adotta durante l’inizializzazione del modulo, altrimenti non si riceverebbero tali informazioni (Comandi AT+CRC e AT+CLIP).

I LED gialli LD6 e LD7 lampeggiano alternativamente durante l’attesa della prima chiamata fonica in ingresso. Se scadono i cinque minuti prima che sia arrivata una chiamata fonica il sistema entra a regime e per configurare i numeri di telefono in rubrica si utilizzeranno appositi comandi stringa da inviare o via SMS o tramite monitor seriale.

I comandi AT generici e specifici

Superato il test sulla necessità di attendere il primo numero di telefono, il sistema si trova a processare delle funzioni che hanno lo scopo di inviare dei comandi AT al modulo GSM in determinate condizioni. Vediamo quali: i comandi AT di uso generico inviati a ciclo continuo al GSM con pausa di un secondo da un comando al successivo. Questi comandi AT hanno lo scopo di acquisire una serie di informazioni dal modulo GSM, le quali vengono utili al sistema per il suo funzionamento. Il flusso può essere interrotto nel momento in cui si manifestano degli eventi come un allarme o altro che necessitano l’invio di altri comandi AT più prioritari. I comandi AT generici usati sono:

AT+CREG → informazioni registrazione rete GSM;
AT+CSQ → informazioni qualità segnale GSM;
AT+CPAS → informazioni stato del modulo GSM (serve per sapere se è occupato oppure no);
AT+COPS → informazioni operatore telefonico;
AT+CPMS → preferenze memorizzazione SMS ingresso/uscita;
AT+GMI → informazioni sul costruttore del modulo GSM;
AT+GMM → informazioni modello modulo GSM;
AT+GMR → informazioni revisione FW caricata nel moduli GSM;
AT+GSN → codice IMEI;

Vi sono poi comandi AT specifici inviati a seguito dell’invio di stringhe di comando. Ad esempio:
AT+CPBR → comando AT per la lettura di una cella di memoria della rubrica telefonica;
AT+CPBF → comando AT per la ricerca di un numero di telefono nella rubrica telefonica;
AT+CPBW → comando AT per la scrittura/cancellazione di un numero di telefono nella rubrica telefonica;
AT+CMGD → comando AT per cancellare un SMS dalla memoria della SIM.

Le funzioni di notifica dello sketch

Segue la porzione di codice per la gestione delle stringhe di comando necessarie a configurare il telecontrollo, inviate sia dal monitor seriale che tramite SMS. Le stringhe inviabili (che esporremo a breve) sono le stesse a prescindere che le si mandi attraverso il monitor seriale o tramite SMS. A seguire abbiamo una serie di blocchi condizionali al fine di verificare se si devono eseguire particolari funzioni rese disponibile dallo sketch se opportunamente configurate e abilitate. In particolare abbiamo:
• invio, se abilitato, dell’SMS al power-up del sistema (ritorno alimentazione); tale funzionalità deve essere abilitata da apposita stringa di comando ed il contenuto dell’SMS può essere quello predefinito in EEPROM oppure una stringa programmata dall’utente tramite apposito comando stringa;
• invio, se abilitato, dello SMS di start-up; tale funzionalità deve essere abilitata da apposita stringa di comando; il contenuto può essere quello predefinito memorizzato in EEPROM oppure una stringa diversa programmata dall’utente tramite apposito comando stringa;
• invio di SMS di allarme a seconda dello stato degli ingressi digitali; il contenuto dell’SMS da inviare può essere configurato dagli utenti tramite apposito comando stringa; gli SMS di allarme possono essere inviati ai soli primi otto numeri presenti in rubrica sempre se si è abilitato il numero a ricevere tale SMS (oltre a inviare un SMS di allarme ai primi otto numeri in rubrica il sistema, se abilitato, potrà eseguire anche una chiamata vocale a tali numeri se abilitati);
• invio di un SMS di report contenente lo stato degli ingressi e delle uscite (tale funzionalità va programmata);
– abilitare/disabilitare la funzione con apposito comando stringa;
– settare ogni quanto deve essere inviato l’SMS di report;
– il messaggio viene inviato solo al primo numero della rubrica;
• invio SMS ECHO. Se si abilita tale funzione, tutti gli SMS ricevuti che non hanno nessuna attinenza con le stringhe di comando usate dal telecontrollo verranno inviati a un numero della rubrica precedentemente selezionato;
• invio di SMS di risposta ai comandi stringa inviati via SMS;
• infine seguono le funzioni per l’elaborazione degli SMS in ingresso e eventuali chiamate vocali sempre in ingresso.

L’organizzazione dei file dello sketch

Quanto appena esposto è l’ossatura dello sketch realizzato, il quale, come di consueto, è suddiviso in più file, che sono descritti qui di seguito.
• GSM_TDG133 → file principale contenente tutte le dichiarazioni di variabili, costanti, direttive al compilatore, comandi stringa memorizzate nella Flash del microcontrollore e relativi codici numerici univoci, stringhe di testo usate per le stampe sul monitor seriale ecc. nonché le funzioni “void setup()” e “void loop()”.
• AT_CmdFunction → file contenente il codice di gestione dei comandi AT generici usati nello sketch e gestione delle funzioni della libreria GSM;
• DigitalInput → file contenente il codice per la gestione degli ingressi digitali;
• DigitalOutput → file con il codice per la gestione delle uscite digitali (relé);
• OutComingSmsVoc → file con il codice di gestione degli SMS e delle chiamate vocali in uscita;
• ProcessStringCmd → file contenente il codice per la decodifica dei comandi stringa ricevuti dal monitor seriale o via SMS;
• SerialStringCmd → file con il codice per la gestione delle stringhe ricevute dal monitor seriale o via SMS;
• TimerInt → file contenente il codice per la gestione del TIMER 5 usato per le variabili temporali necessarie allo sketch;
• _SetupEeprom → file contenente il codice per la gestione della programmazione della configurazione di fabbrica della EEPROM.

Inoltre la suddivisione su più file permette di mantenere il codice più ordinato e di suddividerlo in sezioni ben definite.

Conclusioni

Bene, per il momento ci fermiamo qui; nella prossima e ultima puntata approfondiremo gli aspetti della programmazione, spiegheremo l’utilizzo e la sintassi dei comandi da impartire e concluderemo descrivendo le segnalazioni fornite dai LED del GSM Shield.

Lascia un commento

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

Menu