OpenPicus – Flyport – recensione Review4U

FlyPort rappresenta l’evoluzione per i web server realizzati su microcontrollori PIC basati sullo stack protocollare TCP/IP messo a disposizione dalla Microchip come framework per la gestione e il monitoraggio da remoto tramite il protocollo Ethernet. Con FlyPort si è fatto di più, si sono unite le capacità hardware/software di un PIC a 16bit della famiglia 24F con i vantaggi di disporre di una comunicazione wireless secondo lo standard IEEE 802.11/b/g.

Essenzialmente, se prima per interfacciare un PIC e il relativo web server ad una rete locale occorreva un cablaggio fisico, ora in modalità WiFi ci si svincola completamente dai cavi aumentando di conseguenza la flessibilità di disposizione dell’interfaccia realizzata(se la nostra interfaccia corredata di web server dovesse trovarsi sufficientemente lontana dal router a cui vogliamo connetterla, con la connessione WiFi il problema della posa dei cavi e quindi del cablaggio decade immediatamente).

Tralasciando gli indubbi vantaggi dell’utilizzo di un modulo di questo tipo, mi accingo a recensire quanto ho avuto modo di constatare testando tale hardware. In particolare, le schede che andrò a considerare nel seguito della recensione sono due, la scheda FlyPort vera e propria e la “Nest” che si presenta come uno schedino di supporto al quale connettere il modulo Flyport ottenendo un vero e proprio starter kit su cui testare codici e soluzioni hardware per proiettarsi successivamente su un web server creato adhoc. Le regole di creazione della pagina web e la modalità di interfacciamento tra questa e l’hardware sono le stesse documentate dalla Microchip per web server su microcontrollori PIC fisicamente cablati tramite Ethernet.

In effetti, ciò che cambia non è il protocollo TCP/IP ma il solo livello fisico e di collegamento dello stack OSI, quindi agli occhi del progettista di firmware non cambia assolutamente nulla. Flyport: schema circuitale. Come già annunciato nella premessa, il modulo Flyport è un piccola PCB doppia faccia dalle dimensioni 35x48mm (quindi davvero minime) ospitante il transceiver WiFi MRF24WB0MA e il microcontrollore a 16bit PIC24FJ256GA106, tutto rigorosamente Microchip. Il microcontrollore, nello specifico, conferisce all’hardware le seguenti caratteristiche tecniche: Clock a 32MHZ, più Quarzo 32Khz per RTC a bordo; 256k di memoria Flash, 32k di RAM, 16MIPS; 5 uscite digitali; 5 ingressi digitali; 4 ingressi analogici; 4 uscite PWM (che diventano 9 se si considera che le 5 uscite digitali possono essere pilotate in toggle per generare via software altrettanti segnali PWM); 4 UART fisiche (anche se con il software attuale si arriva a poterne gestire solamente una); 1 SPI (2 SPI se la seconda la si genera via software); 1 periferica I2C nativa.

Essendo un progetto completamente Open Source, gli ideatori di FlyPort mettono a disposizione sul sito ufficiale lo schema elettrico del modulo, dal quale si possono dedurre alcune scelte progettuali anche abbastanza interessanti. Di seguito l’immagine dello schematico.

Tutti i componenti del modulo sono alimentati ad una tensione di 3,3V ma in realtà le possibilità di alimentazione sono essenzialmente due: alimentare il tutto con 5V tanto ci pensa il regolatore lineare LT1117/SOT (U4 nello schema) ad abbassare la tensione a 3,3V oppure alimentare direttamente a 3,3V bypassando completamente il regolatore. Un led verde dislocato in prossimità del transceiver WiFi da informazione sullo stato di alimentazione del modulo. Sul lato microcontrollore ci sono un bel po’ di considerazioni da fare. Innanzitutto quello che compare nello schema elettrico con il simbolo di un diodo zener, U2 siglato ADR5040, in realtà altro non è che un riferimento di tensione di tipo shunt ad alta precisione. In particolare, il modello adottato nel modulo, fissa la tensione di riferimento del pin RB0 a 2,048V (che ricorda molto il numero 2^11) con un’accuratezza iniziale di +/- 0.2% e un coefficiente di temperatura pari a 100ppm/°C.

Anche se nel simbolo circuitale che rappresenta il micro non è specificato, andando a ricercare sul datasheet le funzioni associate al pin RB0 si scopre che questo, opportunamente configurato, prende in ingresso la tensione di riferimento per la periferica ADC a 10bit interna al micro. In particolare, volendo fare due conti molto banali, se il riferimento dell’ADC SAR è pari a 2,048V e il convertitore ha una risoluzione di 10bit, allora la risoluzione in tensione intesa come volt/LSB sarà pari a : 2.048/1024= 2mV/LSB (minima tensione misurabile). Inoltre si osserva la presenza di due quarzi, uno per il core a 32MHz e uno da 32.768kHz per il RealTime Clock (RTC) interno al micro con il quale è possibile far entrare il micro in modalità lowpower e farlo ritornare in modalità operativa tramite interrupt con tempistiche cadenzate su giorni, mesi, anni (come periferica non l’ho mai utilizzata, ma tra le possibilità di utilizzo ci sono anche quelle che ho elencato).

Il transceiver WiFi, siglato MRF24WB0MA, rappresenta tutto il necessario per implementare con estrema semplicità hardware (perché la configurazione software è tutt’altra cosa) il livello fisico dello stack protocollare OSI secondo lo standard 802.11. E’ alimentato con una tensione il cui range va da 2.7V a 3.6V (3.3V tipico) e comunica con il microcontrollore attraverso SPI a 4 linee. Quindi un setting hardware abbastanza semplice. Tramite la modulazione DSSS, la comunicazione si colloca nella banda di frequenza ISM che va da  2.405 a 2.48 GHz, supporta 14 canali selezionabili via software (quindi comprende anche lo standard americano) e dispone di un algoritmo di criptografia AES128. Supporta le modalità “sleep” e “hibernate” che permettono di abbassare gli assorbimenti in corrente da 150mA in trasmissione a meno di 0.1uA in hibernate mode.

La PCB ospita inoltre un’antenna patch accordata e adattata alla frequenza di lavoro, evitando in questo modo di aggiungere ulteriori ingombri al minimo occupato dal FlyPort. Il pin 20 del modulo WiFi, se portato basso, mette in hibernate mode il modulo stesso portando il consumo di potenza al minimo consentito. Le resistenze da 0ohm siglate R11 e R12 sono riportate nello schema in modo da occupare sulla PCB lo spazio dei due componenti, ma sul modulo solo una delle due è effettivamente montata e in particolare di default è presente R11 mentre di R12 ci sono solo i pad prestagnati. Queste resistenze vanno a connettere il pin di reset del modulo wifi o a massa (R11, quindi il modulo non è mai posto in reset) oppure ad un’uscita del microcontrollore (R12 saldata e R11 assente) per poter gestire via firmware il riavvio del modulo. Oltre al led verde che sta ad indicare lo stato di alimentazione del modulo, ci sono altri due led rossi siglati D1 e D2 connessi a due uscite del micro tramite le relative resistenze di limitazione della corrente.

Scheda Nest: schema circuitale

Il modulo Flyport presenta tutta la componentistica necessaria perché possa operare in modalità stand alone, cioè una volta programmato il web server questo può essere aggiunto direttamente alla nostra applicazione finale tramite il comodo connettore strip a 26 pin. Per poterlo programmare e per poter interagire con maggiore facilità con le connessioni, il team di OpenPicus ha realizzato una board detta “nest” (nido) sulla quale alloggiare il FlyPort. Quelle mostrate di seguito sono le foto del Flyport (a sinistra) e della scheda Nest (a destra) ovviamente non in scala.

 

lo schema elettrico della scheda Nest è sempre scaricabile via internet dal sito ufficiale di OpenPicus e lo ripropongo di seguito per osservare quali possono essere le scelte progettuali affrontate dal team di progettazione (i progetti Open Source sono fatti per essere sviscerati all’osso, altrimenti non sarebbero progetti aperti, o sbaglio?? 😉 ).

Dallo schematico si osserva subito la presenza di un IC FT232RL della FTDI utilizzato come UART – USB bridge e che svolge la funzione di interfacciare la scheda Nest al PC tramite una porta COM virtuale. Infatti, il PIC24F di cui è munito il Flyport non supporta nativamente la comunicazione USB e anche se fosse supportata, la scelta di implementare in separata sede il protocollo di comunicazione è certamente azzeccata perché così facendo non si occupa inutilmente spazio di memoria del micro per qualcosa che sull’applicazione finale molto probabilmente non andremmo mai ad utilizzare.

In altre parole, essendo la scheda Nest un supporto hardware per la sola prototipazione, si è deciso di affibbiare a questa l’onere di gestire la conversione da USB a RS232. Restando sempre sul FTDI, il pin 14 siglato CBUS3 va a comandare l’accensione del mosfet TR1 il quale porta l’alimentazione dei 5V della USB verso il diodo D1 diventando in questo modo la Vcc che andrà ad alimentare il FlyPort. Se dall’esterno si andasse ad applicare una tensione di 5V al terminale Vcc, il diodo D1 bloccherebbe il circolo di corrente verso la porta USB, selezionando in questo modo e in maniera automatica la sorgente di alimentazione. Se la scheda Nest si autoalimenta dalla USB, il mosfet TR1 non viene acceso fino a quando non si completa una procedura di instaurazione della comunicazione tra PC e FTDI (praticamente, se il PC ad esempio va in standby, il fatto che non ci sia una comunicazione attiva tra PC e Nest porta quest’ultima a spegnersi).

Sempre sulla Nest trova alloggio il pulsante di reset dell’intero StarterKit con connesso in parallelo il mosfet TR2 che serve a resettare il micro del FlyPort quando deve essere posto in programmazione. Il mosfet citato è gestito dall’uscita DTR dell’FTDI per poter entrare in modalità bootloader. Oltre che per la programmazione, la comunicazione virtuale RS232 serve per il debug TCP/IP restituendo su un terminale appositamente configurato (anche lo stesso hyperterminal di windows va più che bene) dei messaggi indicanti tutti i passi dell’instaurazione della comunicazione TCP.

Scarica subito una copia gratis

2 Commenti

  1. Avatar photo electropower 24 Maggio 2011
  2. Avatar photo Emanuele 24 Maggio 2011

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend