Componentistica accessoria
Una qualunque applicazione LoRa ovviamente pur essendo centrata su una radio LoRa, per poter realizzare qualcosa di concreto avrà sempre bisogno di una srie di componenti aggiuntivi in grado di gestire la radio vera e propria e di realizzare specifiche funzioni legate al tipo di applicazione che si intende realizzare.
Un componente che dovrà essere sempre presente è ovviamente un processore in grado di far girare un opportuno SW ; ci potranno poi essere certamente dei dispositivi per implementare una qualche forma di interazione uomo-macchina ( e quindi un display, degli indicatori tipo led, dei pulsanti ed eventualmente una tastiera), ed infine dei dispositivi per l'interazione con l'ambiente esterno in cui il nostro dispositivo dovrà operare: tipicamente qualcosa per implementare un sistema di tenuta del tempo reale del dispositivo, qualcosa probabilmente per acquisire dei dati di posizione ( e quindi un GPS), una serie di sensori per misurare eventuali parametri dell'ambiente esterno.
Tutta questa componentistica oggi si traduce in altrettanti moduli che potranno consistere in dei semplici chips, oppure in piccoli modulini ibridi che integrano i necessari chips specifici di una certa funzionalità.
Ovviamente ognuno dei chips o moduli che si vanno ad utilizzare avranno delle esihgenze di gestione di cui il propcessore presente nell'applicazione dovrà prendersi cura: questo significa che per ogni modulo HW sarà verosimilmente richiesto un equivalente modulo SW di gestione tramite il quale il processore possa implementare le volute funzionalità.
Questa modellazione è tipica di un moderno sistema indipendentemente dalle sue dimensioni, e si traduce nell'avere diversi livelli di funzionalità che sono tra loro “incastellati” e collegati , in genere con una definizione delle relazioni tra i blocchi rappresentate da opportune definizioni di funzioni con associati parametri che appunto concretizzano l'interazione tra i vari blocchi presenti.
Si parla quindi di un modello a strati, di cui quelli più bassi ovviamente sono tipicamnte legati all'HW del sistema, mentre quelli più alti sostanzialmente implementati tramite opportuni entità SW tra loro interagenti. Ogni livello funzionale ovviamente dovrà avere un suo set di documentazione: per i componenti HW questa documentazione è fornita ovviamente dal produttore dell'HW e si traduce in genere in uno o più “datasheet” che descrivono le funzionalità implementate nei vari blocchi funzionali che compongono un certo chip, ed in un insieme di “modulini SW” che vengono in genere etichettati come API (Application Programming Interface): tramite questa API un processore potrà in genere gestire in maniera più o meno completa il modulo HW a cui è associato.
Spesso le API fornite da un costruttore sono troppo “dettagliate” per un uso “ad altro livello” da parte di un processore… è il motivo per cui in gnerale a seconda dell'ambiente applicativo usato per lo sviluppo del SW, vengono create e rese disponibili delle opportune “librerie” di funzioni che consentono di “semplificare” la gestione di un certo modulo HW in un certo contesto applicativo, rendendo evidenti a livello alto solo della “macro-operazioni” mascondendo tutte le micro-operazioni che sono richieste per la gestione del modulo HW tramite le sue API .
Tutto questo sproloquio per dire che parlare della componentistica HW aggiuntiva che si va ad adoperare in un certo contesto applicativo, passa necessariamente per la definizione di un ambiente di sviluppo applicativo e per una serie di “librerie adatte a quell'ambiente .
Tutto questo si incentra sul tipo di processore che si decide di utilizzare in una certa realizzazione: quindi la scelta di un processore è un elemento chaive per poter poi realizzare in maniera appropriata le funzioni volute minimizzando semmai gli sviluppi aggiuntivi rispetto a tutto l'HW ed il SW già disponibile relativamente alla componentistica che si andrà ad usare.
Nel caso speciifico delle applicazioni basate su LoRa una decisione chiave da prendere è il tipo di “libreria” da utilizzare per gestire le varie radio che si vorranno utilizzare: fino a qualche tempo fa era molto diffusa una libreria tagliata sul tipo di chip LoRa SX127x di prima generazione: con l'avvento dei chips lora di seconda generazione è stato chiaro che quel tipo di libreria non era in grado di essere utilizzata per cui è diventato evidente che conveniva utilizzare un diverso tipo di libreia noto come “RadioLib” che pur risultando leggermente più complessa come utilizzo consentiva di gestire una infinità di diversi tipi di radio ( non solo LoRa) con un approccio funzionale uniforme. Oggi la quasi totalità delle applicazioni LoRa note si basa su questa libreria.
Purtroppo la scelta della libreia RadioLib si porta come conseguenza appresso una scelta abbastanza stringente per il tipo di processore da utilizzare: infatti questa libreia è pensata per l'utilizzo da parte di microcontrollori piuttosto che da parte di processori orientati ad applicazioni SW complesse… una immediata conseguenza è per es. che questa libreria NON gira in ambiente Linux che è l'ambiente classico per lo sviluppo di applicazioni “embedded”… Fortunatamente esiste oggi una ampia scelta di microcontrollori in grado di fare egregiamente il tipo di operazioni richieste in un ambiente embedded, e che tra l'altro sono carattrizzati da costi molto contenuti e da un elevatissimo livello di integrazione.
Uno dei processori, o meglio una famiglia di processori particolarmente interessante è la famiglia ESP32 prodotta da Espressif: nelle nostre sperimentazioni abbiamo deciso di utilizzare questa famiglia di microcontrollori in quanto si adatta benissimo a realizzare applicazioni W anche notevolmente complesse grazie alla sua architettura e alla disponibilità di un sistema operativo chiamato FreeRTOS ottimizzato per girare su questa famiglia di processori ed in grado di consentire una implementazione di funzioni anche di tipo RealTime come è tipicamente richiesto in applicazioni che hanno a che fare con la comunicazione anche ad alta velocità.
Esistono svariate altre famiglie di processori in grado di essere utilizzate ovviamente… una classe particolarmente interessante è costituita dai processori ottimizzati per avere consumi bassissimi: questi processori sono quindi particolarmente adeguati a realizzare applicazioni destinate ad essere alimentate con fonti di energia autonome… dato il tipo di sperimentazioni che noi ci proponiamo di svolgere questa situazione non è per noi considerata una funzionalità essenziale per cui la scelta di usare la sola famiglia ESP32 appare ottimale dal punto di vista economico e funzionale.
Una volta decisa quindi l'archietttura ed il tipo di processore che si intende utilizzare diventa abbastanza agevole individuare a cascata il necessario per implementare le rimanenti funzioni richieste caso per caso, facendo attenzione a scegliere componenti HW che siano dotati già di opportune librerie di gestione tagliate per girare sul processore ESP32.
Nel seguito di questa sezione verranno illustrati in dettaglio i principali blocchi funzionali utilizzati per la nostra sperimentazione, con u cenno alle relative librerie SW di gestione.
