CPUStick: testing per il progetto di antismarrimento

Relazione descrittiva che riassume le prove effettuate su due CPUStick con lo scopo di valutare la fattibilità del progetto “anti-smarrimento” Studio di fattibilità. Un altro passo avanti verso la realizzazione del progetto anti-smarrimento precedentemente descritto in questo articolo.

Studio di fattibilità

La risposta è semplicemente “si può fare”!

Voglio ricordare brevemente a tutti le specifiche di progetto, citando di seguito il post di AndreaD a riguardo:

1. un dispositivo master (da tenere con se) capace di tenere sotto controllo più slave (da inserire negli oggetti da non smarrire)

2. superata una certa distanza tra master e slave, il master lo segnala

3. normalmente lo slave è trasmittente ed il master ricevente

4. anche il master può trasmettere un segnale ad uno degli slave per volta (che quindi può ricevere) per consentire la localizzazione

5. è possibile definire distanze differenti per ogni slave (quindi il rapporto tra master e slave dovrebbe essere configurabile)

6. aggiungo il master dovrebbe poter attivare/disabilitare il rapporto di controllo con ciascuno slave associato (a volte si portano con se solo certi oggetti a volte altri, a volte ce ne allontaniamo volontariamente e non vorremmo essere perseguitati da segnali acustici)

7. dimensioni il più ridotte possibili sia per il master ma ancora di più importante per gli slave.

Come si può subito notare, le dimensioni della CPUStick non sono volutamente ridotte per ragioni di praticità nella prototipazione di schede di interfacciamento con essa. Secondo me tutti i dispositivi necessari alla realizzazione di un master/slave (microcontrollore, transceiver, antenna), possono risiedere su un pcb grande almeno la metà della CPUStick. Il transceiver in questione è il MC13201 della Freescale e lavora tramite il protocollo ZigBee. Esso può lavorare in differenti modalità operative, sia attive che in low-power. Quelle di nostro interesse sono TX-mode (sola trasmissione), RX-mode (sola ricezione) e ED/CCA-mode (energy detection e clear channel assessment). In particolar modo quest’ultima sembra essere studiata proprio per il progetto anti-smarrimento, ma più avanti ne descriverò i dettagli. Il microcontrollore è il MCF52259 sempre della Freescale e permette diverse modalità operative in low-power che , insieme alla frequenza del PLL, giocano un ruolo importante sull’assorbimento totale della scheda. Anche questo aspetto lo descriverò meglio più avanti. Tra le sua varie funzionalità , il microcontrollore presenta un’interfaccia SPI (serial peripherical interface ) che sulla CPUStick costituisce il ponte di comunicazione con il transceiver. Durante lo svolgimento delle prove purtroppo ho dovuto scontrarmi con i limiti di StickOS , il sistema operativo fornito insieme alla CPUStick. StickOS infatti non permette di sfruttare le modalità low-power che il microcontrollore offre e non permette la trasmissione/ricezione di un singolo pacchetto dati e la lettura contemporanea dell’RSSI dal transceiver. In generale si può dire che StickOS usufruisce delle potenzialità dei dispositivi ad un livello alto (come è giusto che sia), ma non le sfrutta tutte.

Assorbimento di corrente

La foto di seguito illustra la modalità di misura della corrente che la CPUStick assorbe. Ho fatto semplicemente uso di un tester in modalità amperometrica con i puntali messi ai capi del jumper j2.

Ho utilizzato del nastro adesivo perché sul momento non avevo altro. All’accensione la CPUStick consuma circa 206 mA e per la nostra applicazione sono davvero tanti. Questo consumo si rivela giustificato dal fatto che il transceiver si trova in RX-mode in cui il consumo tipico è di 37 mA e il massimo è di 45 mA. Il microcontrollore è impostato per lavorare ad una frequenza del PLL pari a 80 MHz e in questo caso il suo consumo è di 118 mA, ma può arrivare ad un massimo di 185 mA. È possibile stabilire la frequenza del PLL sapendo che la scheda ha un oscillatore al quarzo di frequenza pari a 48 MHz, e inoltre andando a leggere i valori di setting nei registri SYNCR (Synthesizer Control Register), CCHR (Clock Control High Register), LPDR(Low Power Divider Register). Scrivendo in questi registri valori opportuni, è possibile cambiare la frequenza di oscillazione del PLL. StickOS permette di fare ciò semplicemente definendo delle variabili ad un determinato indirizzo, aggiungendo “at address” nella definizione e poi impostando il valore della variabile con il comando “let”. Ad esempio:

> dim cchr as byte at address 0x40120008
> let cchr=0x2

Portando la frequenza di lavoro del PLL a 8MHz, il consumo della scheda si riduce a 70 mA, quindi il microcontrollore consuma circa 35 mA. Si possono raggiungere consumi di corrente più bassi disabilitando totalmente il PLL e utilizzando solo la frequenza esterna del quarzo. A questo scopo bisogna agire sui pin CLKMOD0 e CLKMOD1 riportati sul jumper j4 come si vede dallo schema elettrico. Purtroppo questo jumper non compare sulla scheda, quindi non sono riuscito a portare a termine questa prova. Il microcontrollore prevede delle modalità operative a basso consumo energetico e sarebbe stato interessante far passare il micro in STOP-mode per vedere il suo effettivo consumo (intorno alla decina di mA secondo il manuale). Dico “sarebbe stato” perché dopo alcuni vani tentativi ho chiesto supporto a Rich Testardi chiedendogli se in StickOS fosse stata implementata questa funzionalità e la risposta è stata negativa. Per aggiungere queste funzioni al sistema operativo sarebbe stato necessario modificare in maniera opportuna il file sleep.c del firmware. Questa operazione esulerebbe, in questa fase, dagli scopi stessi del progetto.
L’idea che porterebbe ad un consumo davvero ridotto di un dispositivo slave potrebbe consistere nel tenere per la maggior parte del tempo il transceiver in modalità “idle” (consumo di qualche uA) e il microcontrollore in modalità “STOP” (consumo di minore a 10 mA). Impostare un interrupt periodico (ogni 2-3 secondi ) che porterebbe il micro in modalità “RUN” e successivamente il transceiver in modalità “TX” (sola trasmissione). Giusto il tempo di spedire un pacchetto dati contenente un proprio ID identificativo del dispositivo, basterebbe al nostro scopo. Successivamente lo slave può tornare a “dormire”. Il master, invece, dovrebbe rimanere sempre “sveglio”, quindi la modalità di STOP è da escludere. In questo caso potrebbe risultare utile la modalità di “WAIT” che si può impostare durante l’attesa di nuovi pacchetti. Questa modalità riduce il consumo ulteriormente di qualche mA rispetto alla modalità di “RUN”, tuttavia penso che il consumo totale del master non possa scendere sotto i 40 mA anche spegnendo il PLL.

Estrazione dell’ RSSI

Le prove che ho effettuato con lo scopo dell’estrazione dell’RSSI (Received Signal Strength Indication) non hanno portato dei risultati per i motivi che illustrerò di seguito. Tuttavia mi sembra utile, per chi ha intenzione di fare prove simili, descriverle con lo scopo di condividere osservazioni e problemi. Prima di tutto ho proceduto impostando una cpustick con nodeid 1 e l’altra con nodeid 2. Sulla prima ho mandato in esecuzione il seguente programma:

>10 dim led as remote on nodeid 2
>20 while 1 do
>30 let led = !led
>31 sleep 1000 ms
>40 endwhile end

Sulla seconda ho mandato in esecuzione il seguente programma:

> 10 dim led as pin dtin0 for digital output
> 15 dim rxtxen as pin fec_txclk for digital output
> 20 dim cs as pin qspi_cs0 for digital output
> 30 dim irq as pin irq1* for digital input
> 50 dim cmd as byte
> 60 dim control_a as short, rx_status as short, cca_thresh as short
> 70 dim irq_status as short, value as short
> 80 // start
> 90 let rxtxen = 0
> 100 // setting cca_threshold
> 110 let cmd = 0x4 // writing on 0x4 register (CCA_Thresh)
> 120 let value = 0xa49d //cca_vt=0xa4, power_comp=0x9d
> 130 let cs = 0
> 140 qspi cmd, value
> 150 let cs = 1
> 160 //setting control_a
> 170 let cmd = 0x6 // writing on 0x6 register (Control_A)
> 180 let value = 0x411 // cca_mask=1, cca_type=01, xcvr_seq=01
> 190 let cs = 0
> 200 qspi cmd, value
> 210 let cs = 1
> 220 let rxtxen = 1
> 221 on !irq do gosub read_registers
> 230 while 1 do
> 240 assert rxtxen
> 260 endwhile
> 270 end
> 280 sub read_registers
> 290 let rxtxen = 0
> 310 let cmd = 0x86 // reading 0x6 register (Control_A)
> 320 let cs = 0
> 330 qspi cmd, control_a
> 340 let cs = 1
> 350 print "CONTROL A REGISTER ", hex control_a
> 360 let cmd = 0x84 // reading 0x4 register (CCA_Thresh)
> 361 let cs = 0
> 362 qspi cmd, cca_thresh
> 363 let cs = 1
> 370 print "CCA THRESH REGISTER ", hex cca_thresh
> 380 let cmd = 0xad // reading 0x2d register (RX_STATUS)
> 390 let cs = 0
> 400 qspi cmd, rx_status
> 410 let cs = 1
> 420 print "RX_STATUS ", hex rx_status
> 430 let cmd = 0xa4 // reading register 24 (IRQ_STATUS)
> 440 let cs = 0
> 450 qspi cmd, irq_status
> 460 let cs = 1
> 470 print "IRQ_STATUS ", hex irq_status
> 480 let rxtxen = 1
> 490 return
> 500 endsub

Quello che intendo fare con questa prova consiste nel fare accendere ad intermittenza (con periodo di 1 secondo) un led sul pin dtin0 inviando il segnale dall’altra cpustick. Sulla scheda ricevente (nodeid 2) non mi limito solo a ricevere il segnale ma anche a leggerne la potenza. Per fare questo è necessario impostare il transceiver sulla modalità CCA, Clear Channel Assessment . Mi sembra importante sottolineare che era possibile anche impostare la modalità ED Enargy Detection, ma la modalità CCA permette di settare una soglia (CCA Threshold) che costituisce il limite superato il quale si ha una segnalazione. Le operazioni di lettura e di scrittura con i registri sul transceiver avviene tramite l’interfaccia spi (comando “qspi”) e due variabili di appoggio (“cmd” e “value”). Il programma all’inizio disabilita la rice-trasmissione del transceiver (rxtxen=0) per permettere l’impostazione sulla modalità desiderata (CCA). La prima operazione consiste nello scrivere sul registro CCA_THRESH (indirizzo 0x04) il valore della soglia (cca_vt[7:0]) e un valore di compensazione (power_comp[7:0]) utilizzato in seguito nel calcolo della potenza del segnale. In questa prova scrivo dei valori suggeriti dl manuale perché in questa fase non mi interessa questa particolare funzionalità del transceiver, ma mi interessa solo la lettura della potenza del segnale. In seguito si settano dei particolari bit (cca_mask, cca_type[1:0], xcvr_seq[1:0]) nel registro Control_A_Register (indirizzo 0x06), i quali costituiscono la configurazione desiderata per il transceiver e l’abilitazione alla generazione di un interrupt sull’avvenuto calcolo della potenza del segnale dopo aver ricevuto un pacchetto. In seguito si definisce una subroutine la quale viene chiamata ogni volta che sopraggiunge un interrupt, cioè ogni volta che il calcolo della potenza del segnale ricevuto è stato completato.
La subroutine in questione è scritta per leggere tutti i registri interessati nel processo ed in particolare modo quello dove si trova l’RSSI. Questo registro è chiamato RX_STATUS e si trova all’indirizzo 0x2D. Dopo averlo mandato in esecuzione i risultati non sono purtroppo quelli sperati. L’effetto che si ottiene è di perdere la comunicazione tra i due dispositivi e a volte StickOS si blocca del tutto. Dopo aver “smanettato” un po’ il risultato non è cambiato. Ho fatto anche una prova diversa di cui non riporterò il codice per non appesantire la lettura e perché mi sembra inutile dato che porta allo stesso problema che mi appresto a scrivere.
Accenno solo che questa prova prevede l’impostazione di un transceiver in sola trasmissione (TX-mode) e dell’altro transceiver in sola ricezione (RX-mode). Se qualcuno fosse interessato al codice lo posso sempre fornire. Come ho già detto nemmeno questa prova ha portato dei risultati. Dopo avere chiesto assistenza a Rich Testardi, ho capito che StickOS non prevede tra le sue funzionalità questo tipo di prove. Il punto è che sia il programma in BASIC che StickOS tentano di accedere contemporaneamente ai registri del transceiver , di conseguenza il risultato è poco prevedibile.

Le soluzioni proposte sono due ed entrambe troppo onerose in questa fase del progetto: 1. Fare in modo che StickOS non gestisca il transceiver e occuparsi della rice-trasmissione con programmi BASIC scritti ad-hoc 2. Implementare in StickOS le funzionalità necessarie alla prova modificando il file zigflea.c del firmware. Si tratta di tanto lavoro non giustificabile in questa fase e su una scheda di prova. Insieme a tutta la “crew” si è ovviamente deciso di rimandare questo aspetto fondamentale al momento della realizzazione di un primo prototipo del prodotto finale.

Conclusioni

In questa relazione ho presentato in maniera sintetica le prove che ho effettuato sulla CPUStick. Sicuramente bisogna dare atto che si tratta di una scheda veramente funzionale e che StickOS offre la possibilità di avere un’interfaccia con l’utente intuitiva e abbastanza semplice. Le prove descritte hanno testato i dispositivi che la scheda monta e che a mio avviso sono adatti per il progetto “anti-smarrimento”. Ciò che è importante è valutare se ci sono sul mercato dispositivi più competitivi in termini di assorbimento e funzionalità offerte.

Gianpaolo Gulletta [Zohan85]

Scarica subito una copia gratis

8 Commenti

  1. Avatar photo Piero Boccadoro 12 Dicembre 2012
  2. Avatar photo delfino_curioso 12 Dicembre 2012
  3. Avatar photo Emanuele 12 Dicembre 2012
  4. Avatar photo Emanuele 13 Dicembre 2012
  5. Avatar photo signolo 13 Dicembre 2012
  6. Avatar photo zohan85 14 Dicembre 2012
  7. Avatar photo Emanuele 16 Dicembre 2012
  8. Avatar photo Nino.Molinari 10 Gennaio 2014

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend