ESP8266 – Quando un double è un double…..

Una ulteriore comodità messa a disposizione da queste piccole schede ESP8266 rispetto agli Arduino è che sono più flessibili e “precise” nel calcolo in virgola mobile. Mi spiego: in tutte le schede della famiglia Arduino (tranne Arduino 2) le variabili di tipo float o double sono comunque memorizzate in 4 bytes. Il che significa che hanno comunque la precisione tipica di un float (5 o 6 decimali, non di più). Se abbiamo bisogno di far girare codice che usa intensivamente variabili a doppia precisione questo può essere un problema. E’ pur vero che esiste per Arduino una libreria a precisione arbitraria chiamata BigNumber (https://github.com/nickgammon/BigNumber) ma se si ha necessità di far girare un bel po’ di codice scritto in C bisogna apportare significative modifiche al codice stesso, che perde di ogni portabilità, senza contare il degrado di prestazioni su un microcontrollore che gira a 16MHz.

L’alternativa poteva essere dotarsi di un Arduino 2 che ha le sue variabili double a 8 byte (quindi con 15-16 decimali significativi nel migliore dei casi) oppure, meglio ancora, usare un ESP8266 che ha le double a 8 byte e che “gira” a 80MHz, il che non guasta.

Se qualcuno si stesse domandando cosa ci facciamo con delle variabili double “vere” basti pensare a calcoli di fisica applicata, inseguitori solari, calcoli di sorgere e tramonto astri, e altre cose che in un progetto di controllo elettronico possono benissimo capitare. E che l’ESP8266 sembra possa gestire piuttosto bene sia come velocità di esecuzione che in termini di memoria.

 

ESP826612-e e sensori analogici. Risolto.

Ci ho messo un po’ a capire, ma credo di aver risolto. Dopo aver provato ad installare il supporto per le schede ESP versione 2.0.1-rc2 e non aver notato progressi sono andato a rovistare nel codice in cerca di qualche ispirazione. In effetti la gestione della analogRead() è rimasta la stessa:

se si usa un Mac come nel mio caso, cercando in

 un file chiamato core_esp8266_wiring_analog.c  non ho trovato particolari indizi

se non quello che nella chiamata di questa funzione è vietato distrarsi e immettere come parametro di input ‘0’ invece di ‘A0′. 🙂

L’illuminazione mi è venuta guardando il codice di debug che io metto come testata nei miei sketch ESP e che ha avuto un effetto stabilizzante nei runtime dei moduli. Ecco qui il colpevole:

Anzi, il colpevole era questa maledetta riga:

che ha il compito evidentemente di mettere in output il pin ADC per leggere il Vref e che inibisce l’uso dello stesso pin come porta analogica….

Dopo aver dato qualche testata contro il muro per non averci fatto caso prima, ho tolto solo questa riga lasciando il resto, ho ricaricato lo sketch e il mio fotoresistore GL5539 ha miracolosamente preso a misurare correttamente fotoni, facendo il suo sporco lavoro.

Due cose soltanto mi lasciano un po’ perplesso: il pin ADC lasciato “a vuoto” non ritorna  0 ma un valore flottante compreso tra 10 e 15. Vabbè, ci posso anche stare. Ma la cosa più strana è che, multimetro alla mano, ho misurato che la porta satura (ovvero ritorna valore 1023) non a 1V come dichiarato, ma a 3.3V, il voltaggio di alimentazione. Tanto è vero che al di là della resistenza di pull-down (10Kohm) che ho lasciato, non c’è stato alcun motivo di usare nel circuito un classico partitore di tensione.

Verificherò questa cosa anche sulle altre schede in mio possesso, se così fosse sarebbe anche meglio, non perderei risoluzione sui sensori analogici. E’ strano, ma le misure dicono che è così…..

 

ESP8266-12e e sensori analogici

esp8266-12e

Finora i miei tentativi di dare un senso a quella benedetta “porta analogica” AD0 presente nei miei ESP8266-12e sono stati piuttosto frustranti. Almeno nella versione che ho io, quella con il chip CH340, la analogRead() ritorna invariabilmente un valore 1023 sia con la porta “a vuoto” che con un qualsiasi voltaggio nel range 0-1V applicato. La cosa assurda è che a vuoto il pin risulta elettricamente a 0V verso massa, ma la lettura è sempre e comunque 1023.

Ho cercato ovviamente su Internet di trovare informazioni ed effettivamente ho trovato diversi articoli che parlano di “valori random” su questa porta tra cui il mio 1023, imputabili probabilmente alla libreria che interfaccia la IDE di Arduino. D’altronde io sto utilizzando la versione “certificata”, la 1.6.5, e la trovo estremamente comoda visto che non ho il tempo di provare a programmare questa scheda con altre interfacce.

Spero che sia solo un problema dell’attuale interfaccia che sta alla versione 2.0.0, e che comunque ha più di 300 issues aperti. Ho visto che la prossima versione in fase di sviluppo è alla Release Candidate 2, quindi prossima all’uscita, e  mi auguro che questo fastidioso problema venga risolto.

Arduino e fotoresistori GL55XX

fotoresistenza

In precedenza ho illustrato come utilizzare il sensore TLS2561 per misure di luce in Lux di buona qualità, ma nella maggior parte dei casi possono essere utilizzati i più comuni fotoresistori della famiglia GL55 che, a fronte di una più bassa qualità costruttiva offrono tuttavia un “lavoro” più che decente oltre a costare enormemente di meno. Si tratta comunque di componenti passivi (a differenza dei fototransistor) che possono presentare variazioni dei valori caratteristici da esemplare a esemplare anche abbastanza importanti, ma se non abbiamo in mente di costruire un luxmetro di precisione ci possiamo anche accontentare. Per ottimizzare il codice che presento in seguito sarà bene tenere sott’occhio il datasheet di tutta la serie, che si può scaricare QUI, da cui andranno prelevati i valori della Dark Resistance e Light Resistance, tipici del modello. Nel mio caso, essendomi procurato dei GL5539, avrò rispettivamente come valori 5Mohm e 50Kohm.

Nel circuito ho utilizzato una resistenza di Pull-Down (o stabilizzatrice verso massa, come vogliamo chiamarla) di 10Kohm, che mi sembra un buon compromesso nel caso di una scheda Arduino generica che abbia come voltaggio di riferimento 5V. Ecco lo schema di collegamento su breadboard:

gl5539

Nello sketch andranno quindi valorizzati correttamente nella funzione di calcolo in Lux della lettura sensore i valori RD e RIF, deducendoli dal datasheet. La formula utilizzata per la conversione in Lux è decisamente migliore di quella che ho utilizzato in passato per il Keyes KY018 e ritorna un valore -1 in caso di saturazione del sensore, il che accadrà solo in presenza di forte luce solare diretta sul GL55XX. Al confronto con un Luxmetro vero le letture mi sono apparse sempre decenti, a conferma della bontà dell’algoritmo.

Ecco qui lo sketch di test. Ho utilizzato per l’output oltre l’uscita seriale anche uno dei miei LCD di cui ho parlato in precedenza, ma si può bypassare il codice sostituendo all’inizio la definizione #define LCD false a quella esistente.

SKETCH DI TEST: