LABijk: bus di comunicazione.

Il progetto LABijk, per la complessità strutturale che lo caratterizza, richiede un’attenta riflessione sulle sue scelte di fondo: il microserver, l’architettura di questo, i microcontroller, lo standard verso attuatori e sensori, i bus di comunicazione, i protocolli di sicurezza, e molto altro.

In uno sviluppo aperto andremo a classificare in modo ordinato ogni punto citato ed altri ritenuti indispensabili.

Continuiamo il nostro dibattito soffermandoci a riflettere sul/i bus di comunicazione da adottare tra il microserver e i dispositivi i al primo livello .

E’ ovvio pensare ad ethernet, ma pesano le seguenti argomentazioni

  • impegnativo in termini infrastrutturali, switch POE, cablaggi strutturati, …
  • in termini di microcontroller comporta costi ed elettronica non trascurabili
  • Arduino in relazione alle porte  ethernet e POE non è così interessante,  anche per costi
  • il codice TCPIP per Arduino è piuttosto debole
  • i dispositivi del primo livello dovrebbero quindi essere schede ARM quali RaspberryPI
  • RPI scalda, richiedono risorse memoria enormemente superiori di Arduino, quindi usa tecnologie fragili come SD

Quindi ethernet è solo per usi specifici e vedrebbe Arduino fuori gioco, precludendo tutta la gestione dell’elettronica in stile Arduino.

I vecchi bus seriali tipo RS232 sono lenti soprattutto se il dispositivo centrale, in questo caso il micorserver,  fa pooling tra i periferici. Ricordiamo che una gestione ad eventi che parta dalle periferiche è esclusa perchè si perde il controllo delle periferiche stesse.

Consideriamo il bus USB:

  • è stabilissimo, robustezza derivata dall’enorme impiego
  • tutti lo usano a tutti i livelli
  • è uno standard: chiunque sa quale sia un cavo USB
  • Arduino con il suo primo microcontroller a bordo implementa la comunicazione USB in modo eccellente
  • i costi sono praticamente abbattuti
  • test di pooling per mesi da microserver verso Arduino via USB alla velocità massima hanno visto una precisione assoluta
  • il microserver, centro stella, può non avere seriali, ma le macchine attuali abbondano di porte USB
  • il cavo USB porta anche l’alimentazione, sufficiente per un Arduino Uno SMD con un po’ di elettronica, quindi abbiamo gratuitamente l’equivalente della POE
  • la massima lunghezza del cavo USB è di circa 5 metri, ma si possono usare estensori USB via cavo tipo rete per lunghezze pari a 50 metri. Il costo di un’estensione è di circa una decina di euro e di cavo standard rete con RJ45, che è molto meno di uno splitter POE

Linux permette il controllo preciso delle porte USB, test verso Arduino, attraverso USB, mediante programma compilato C++ in pooling mostrano il funzionamento ininterrotto in mesi.

Un aspetto delicato da capire per bene è l’adozione, da parte del gruppo di progettazione Arduino, del reset in caso di perdita di connessione del BUS USB. Aspetto che si rivela invece estremamente utile per il recupero eventuale di una periferica fuori controllo: basta chiudere e riaprire la porta USB.

I microcontroller i di primo livello, connessi al microserver centrale tipicamente mediante USB, devono comunicare con gli altri ij del secondo livello.

Le seguenti osservazioni portano alla migliore scelta per queste tratte:

  • serve un bus estremamente robusto
  • che utilizzi cavi comuni, per dire quelli utilizzati dell’impiatistica per i sistemi di allarme, trasportando anche l’alimentazione
  • che permetta tratte fino a 1200 metri
  • che sia preciso, simmetrico
  • che permetta di collegare allo stesso bus di pochi fili molte periferiche
  • che apaprtenga ad  uno standard ampiamente utilizzato.

Quindi la scelta è il bus RS485.

Le ultime considerazioni sono relativa all’ultima tratta ovvero dai dispositivi ij a quelli ijk, che sono sensori, attuatori ed elettronica varia:

  • le schede prototipali sono da escludere, possono essere tollerate in particolari utilizzi
  • rafforzando il punto precedente: le attività di saldatura di componenti, soprattutto se superficiali, sono, tranne in specifici casi,  da escludere
  • serve uno standard che porti i pin delle schede Arduino, tipicamente Uno SMD,  ad insiemi di connettori, tra le molte proposte nel mercato, la forse più ricca è lo standard  Grove
  • Grove implementa bus a 4 fili: due alimentazioni e due pin di segnali
  • il bus Grove è facilmente utilizzabile o mediante cavi patch già pronti oppure estendendo la connessione con cavo tipo quelli adottati nel sistema di sicurezza, ovvero lo stesso che abbiamo indicato per la connessione dei dispositivi i di primo livello i con i dispositivi ij di secondo livello.