Iniziai a scrivere del firmware circa 40 anni fa, mentre lavoravo su una telescrivente militare. Quel tipo di macchina era dotato di una CPU a logica cablata (!). La programmazione del brevissimo firmware di gestione veniva fatta in ottale. I dati venivano visualizzati su cinque display LED a sette segmenti e potevano essere scritti tramite un tastierino numerico.

Inutile dire che fantastica esperienza possa essere stata. Gli spostamenti da un accumulatore all'altro, le semplicissime operazioni logiche tra registri, il tasto di "Enter" per memorizzare la singola istruzione. Eppure quella semplicissima macchina semplicemente "funzionava". Io ero progettista junior in una piccola azienda  ad alto contenuto tecnologico. Solo successivamente tale macchina fu sostituita da una a microcontrollore, il celebre 8051 della Intel. Iniziai allora ad utilizzare l'assembler. Mi sento di suggerire a chiunque di fare esperienza creando una semplice macchina a logica cablata.

Per quanto possa aver efficacemente studiato tale argomento a scuola, iniziai veramente a comprendere il funzionamento dei microcontrollori solamente quando ebbi modo di scrivere il primo codice professionale in assembler. Sino ad allora tutto quanto era rimasto un puro esercizio teorico. La programmazione in assembler è senz'altro quella che maggiormente fa comprendere la vera essenza di un controllore. Non si può prescindere da una profonda conoscenza del funzionamento della CPU e delle sue periferiche, sia che venga utilizzato l'assembler e sia che si programmi in C. E' solo andando a studiare ed a gestire i singoli bit di un registro interno, ad esempio di un Configuration Register di una periferica USART o I2C o SPI che ci si impadronisce a pieno della macchina. Evito di utilizzare librerie pre-compilate di cui il web è pieno e che, a mio avviso, oltre ad essere di discutibile affidabilità, aggiornabilità e manutenibilità, in genere non consentono di capire a pieno ed impadronirsi del necessario know-how circa il funzionamento di un processore.  

Approfondii la tecnica di programmazione studiando un testo di un prestigioso autore inglese riguardante la programmazione strutturata.

Ritengo che uno dei migliori modi per scivere un programma in C sia utilizzando la cara vecchia programmazione strutturata. Il fimware, più di ogni altra cosa, deve essere ben leggibile, strutturato in maniera chiara. Evito accuratamente di scrivere funzioni di lunghezza esagerata o "criptiche" (esempio return b ? function (a ^ b, (a & b) << 1). Pur se il C rende disponibili infiniti modi per compattare una riga di codice (secondo me troppi) credo che il modo migliore per scrivere un programma chiaro e ben leggibile sia di utilizzare le classiche istruzioni strutturate if-then-else e for, con le quali si può scrivere praticamente tutto. Il programma appare più lungo in termini di righe, vero, ma se ne guadagna in termini di leggibilità e manutenibilità. Utilizzo sempre con estrema prudenza le strutture Do While o While Do. 

Vedo spesso codici reperiti nel web, che fanno un larghissimo uso di cicli iterativi Do While o While Do, soprattutto quando si vuole che il proprio software crei un ritardo nella propria esecuzione.

Non dimentico mai che normalmente un processore possiede un solo program counter (a meno che non sia un multicore o multithreading) e quindi è in grado di eseguire una sola istruzione alla volta. Alcuni riescono ad eseguire più istruzioni contemporaneamente (nel caso di architetture VLIW) ma in ogni caso l'esecuzione di un programma è di tipo sequenziale.

Un ciclo while fa ripetere determinate istruzioni sino a che una determinata condizione non viene verificata.

Creare un ritardo di 100mSec utilizzando un semplice ciclo while significa "bloccare" la macchina che in quel momento si sta occupando della complessa funzione di "realizzare un ritardo". Una macchina funzionante magari a 2GHz (due miliardi di cicli al secondo...) bloccata per contare magari sino a 1000.

Cerco sempre di ricordarmi che ogni processore ha a disposizione una serie di timer ed interrupt, ad esempio, con i quali posso creare e gestire infinite temporizzazioni. Questo problema ovviamente nasce anche utilizzando un ciclo For.

Il vero problema è quando la condizione che deve verificarsi è, ad esempio, un dato da ricevere da una periferica, un flag che deve attivarsi. E se il dato non arriva mai perchè la periferica si è improvvisamente bloccata? Dato che quasi mai ho visto cicli While che prevedono time-out o condizioni di uscita, il pericolo è in agguato.

Pensandoci bene, ora forse mi spiego perchè il bluetooth della mia moto (di un marchio prestigioso), oppure la connessione WI-FI del mio sistema domotico (altrettanto prestigioso) oppure il sistema operativo del mio p.c. durante una stampa, si piantano in maniera definitiva al punto che l'unica soluzione è spegnere e riaccendere la moto, il sistema domotico ed il p.c.

Che c'entri in qualche modo un ciclo Do While maldestro?...

Ormai mi viene spontaneo: piazzo un dispositivo sullo schematico et ... voilà, automaticamente compaiono per incanto i famigerati condensatori da 0,1uF sulle alimentazioni.

Al punto che se non vengono messi, il committente è portato a domandare: "ma come mai qui non c'è il condensatore di disaccoppiamento?".

E nascono così board con enormi capacità equivalenti sulle alimentazioni, capaci di innescare inrush corrent da far saltare il più dotato dei magnetotermici, se non problemi più insidiosi, come indesiderate oscillazioni.

Cerco sempre di valutare per bene questo aspetto, inserendo i condensatori di disaccoppiamento solo dove effettivamente servono o raccomandati dal data sheet del costruttore. In linea del tutto teorica, considerando la ESR dei condensatori ceramici multistrato, se il layout del p.c.b. presentasse sezioni adeguate alle correnti in gioco e le masse fossero correttamente collegate, probabilmente tali condensatori sarebbero necessari solamente in casi molto particolari.

Ormai ogni board che vedo in giro ha il piano di massa diffusa.

Sono dell'idea che ciò possa essere in molti casi addirittura controproducente.

Lo dovetti interamente rimuovere da una LED strip da 1200mm in quanto evidentemente introduceva capacità parassite che innescavano oscillazioni acusticamente udibili sul buck converter.

Ora limito i piani di massa solamente in prossimità di regolatori DC/DC, o in altre parti circuitali dove ci sono alte correnti in gioco che possono generare spike positivi o negativi, controproducenti per il normale funzionamento del dispositivo.

Ovviamente non tutti dei cento progetti che ho realizzato sono arrivati in porto.

Ho analizzato in maniera razionale più volte le cause di ciò, arrivando a delle prime conclusioni.

Nella maggior parte dei casi l'insuccesso di un progetto è generato dall'incapacità (non me ne vogliano) dei committenti, rappresentati soprattutto dalle aziende più piccole o da privati, di trasmettere al progettista TUTTE le informazioni, i requisiti, insomma i desiderata, riguardanti l'idea da sviluppare.

Il piccolo committente ha la convinzione che il progettista abbia la capacità di "indovinare" quelle che dovranno essere le caratteristiche tecniche, le modalità di funzionamento, i test di accettabilità che il prodotto oggetto della progettazione dovrà rispettare. Ma non è così. Chi fa questo mestiere ha a che fare con una moltitudine di richieste enormemente differenti l'una dall'altra.

Purtroppo il piccolo committente raramente ha a disposizione una specifica di progetto o un capitolato tecnico al quale il progettista potrà fare riferimento. Le informazioni vengono trasmesse il più delle volte verbalmente, o tramite messaggistica, raramente via e-mail.

Inevitabilmente questa mancanza di informazioni, contro la quale beninteso non ci sono costromisure che il progettista può mettere in atto, dal momento che quello che non si conosce non lo si può pianificare e prevedere, alla fine genera insoddisfazione da parte del committente.

E' fondamentale quindi che il committente si metta nei panni del progettista che non conosce NULLA della sua idea, trasmettendogli quante più informazioni possibili, soprattutto riguardo alle aspettative.

Spesso vengo contattato da persone (per lo più privati od hobbisti) che, con la sola intenzione di risparmiare sull'acquisto di un dispositivo elettronico, pensano bene di contattare un progettista elettronico, piuttosto che acquistare lo stesso bell'e pronto sul web.

Il proliferare di prodotti esteri a basso costo effettivamente funzionanti, ha fatto nascere l'idea che ormai l'elettronica sia diventata un giochino accessibile a tutti.

Noi progettisti sappiamo che non è così. Arrivare ad un prodotto finito partendo il più delle volte da un'idea di base del cliente, è tutt'altro che facile. 

E' necessaria, oltre che la dovuta competenza, anche il giusto tempo e le giuste risorse economiche.

Quindi amici appassionati, la prossima volta che vedrete un prodotto elettronico a 100 euro sul web, fate una cosa: acquistatelo.

Queste sono due modalità con le quali portare avanti una progettazione, profondamente differenti l'una dall'altra.

La scelta di quale delle due proporre al cliente dipende sostenzialmente dalla completezza o meno dei requisiti iniziali.

Nel caso sia presente una Specifica di Progetto o Capitolato Tecnico, nel quale siano chiaramente indicati, oltre alla caratteristiche tecniche e di funzionamento, anche tutti gli altri requisiti  (meccanici, ambientali, prove di accettazione) il progettista è in grado di elaborare con una dicreta precisione un preventivo da sottoporre al cliente.

Ovviamente in questi casi il progettista deve tenere conto anche di eventuali costi dovuti ai rischi, alle revisioni necessarie, per cui il preventivo ne dovrà necessariamente essere influenzato.

Tale caso è, ahimé, quello meno frequente. Come già detto in un precedente argomento, il più delle volte le informazioni vengono passate al progettista verbalmente, via messaggistica o e-mail. Ed il più delle volte tali informazioni cambiano o vengono ampliate, completate col passare del tempo.

Da qui quindi l'impossibilità di elaborare un preventivo mirato e giusto, sia per il Cliente che per il progettista.

Per evitare quindi di passare i mesi successivi a discutere su richieste di revisione degli ordini, master change etc, in genere propongo al Cliente una collaborazione con consuntivo periodico ad ore, con tariffa oraria fissa e rendicontazione periodica. In tal modo il cliente ha modo di verificare lo stato di avanzamento periodico dei lavori ed intervenire, interrompendo anche la collaborazione nel caso lo ritenesse opportuno senza ulteriore aggravio di costi.

Spesso tale soluzione è quella più conveniente per il Cliente perchè non deve tenere conto degli inevitabili rischi legati alla progettazione.

Argomento ben trattato e conosciuto dai progettisti.

Tuttavia ci sono alcuni aspetti legati alla dissipazione di potenza dei componenti discreti (transistor, mosfet, IGBT) che spesso non vengono tenuti nella giusta considerazione.

Si tratta di:

• potenza istantanea
• coppia di serraggio del dissipatore

Può succedere che pur dimensionando correttamente il sistema di raffreddamento, nel caso ad esempio di inverter o alimentatori di potenza particolarmente elevata, i dispositivi non riescano a sopportare il picco di corrente e si guastino rapidamente.

La trasmissione del calore non è ovviamente immediata, e soprattutto quando ci sono forti picchi istantanei associati a sistemi di dissipazione isolati (con mica o pellicole termoconduttive) può accadere che il calore non faccia in tempo a dissiparsi e ad evitare il superamento della Tjmax.

Si tratta della costante di tempo termica.

Ho individuato nel tempo una soluzione particolarmente efficace in tali casi. E' sufficiente applicare direttamente senza interposizione di isolamento termoconduttivo tra il dispositivo ed il dissipatore un piastrino in alluminio. Questo equivale sostenzialmente ad aumentare la superficie dissipante del dispositivo (riduzione della resistenza termica junction-ambient) ed a scongiurare guasti. Se poi tra il dispositivo ed il piastrino in alluminio si interpone del grasso termoconduttivo la situazione migliora ulteriormente.

Altro aspetto fondamentale di cui spesso non si tiene in considerazione è la coppia di serraggio del sistema con il quale si ancora il dispositivo al dissipatore.

La resistenza termica di contatto tra il dispositivo ed il disspatore è fortemente influenzata dalla forza con la quale i due oggetti sono accoppiati. SI può passare da pochi decimi di K/W a valori decisamente fastidiosi di qualche K/W. Serrare fortemente con viti il dispositivo è spesso la soluzione migliore. Le varie mollette di tenuta che si trovano associate a molti dissipatori, spesso non consentono di poter modulare tale forza. Vanno benissimo per applicazioni standard ma possono non essere l'ideale per applicazioni di alta potenza.

Ricordo un'applicazione professionale che faceva uso di grossi diodi a disco per correnti fino a 1000A, in cui la coppia di serraggio andava regolata mediante utilizzo di apposite clamp di serraggio regolabili, in grado si applicare una forza di serraggio di oltre 10KN! 

La realizzazione di un buon prodotto, indipendentemente dalla sua complessità, parte da idee ben chiare.

E' necessario rispondere bene a queste domande:

• A cosa servirà il prodotto?
• Chi dovrà utilizzarlo?
• Quale dovrà essere il suo funzionamento nel dettaglio?
• In che ambiente dovrà funzionare?
• Che dimensioni fisiche dovrà avere?
• Quale dovrà essere il peso complessivo del sistema?
• Che verifiche bisognerà eseguire per essere certi che quanto realizzato soddisfi a pieno le aspettative?

Saranno semplici risposte che normalmente l'ideatore del progetto avrà senz'altro in mente, anche se non tutte, ma che il progettista al quale ci si rivolge non può in alcun modo conoscere.

Cercherò di rendere il più possibile chiara questa esposizione facendo un esempio pratico di realizzazione di un sistema apricancello automatico.

1. A cosa servirà il prodotto? Il sistema dovrà essere in grado di aprire e chiudere automaticamente un cancello in ferro delle dimensioni di 3m x 2m a doppia anta, del peso di 180Kg. L'apertura / chiusura sarà attivata mediante un radiocomando alimentato a batteria a 433MHz che dovrà possedere due pulsanti, uno per l'apertura ed uno per la chiusura. Un LED posto sul radiocomando dovrà segnalare l'avvenuta pressione del tasto. Il cancello dovrà aprirsi e chiudere in un tempo massimo poredefinito. La movimentazione delle due ante del cancello avverrà tramite due motori da 220Vac 500VA dotati di finecorsa meccanico.
2. Chi dovrà utilizzarlo? Il sistema dovrà essere utilizzabile da chiunque, anche non in possesso di conoscenze tecniche, pertanto i due pulsanti di apertura / chiusura dovranno essere ben visibili e dovranno essere chiaramente identificati. Un sistema di sicurezza a fotocellula dovrà interrompere il movimento delle due ante qualora un ostacolo di qualsiasi genere interrompa il fascio tra le due fotocellule. Le due fotocellule dovranno essere posizionate ad un'altezza tale che sia possibile individuare, oltre che veicoli di altezza pari a 1m, anche bambini di altezza 60cm.
3. Quale dovrà essere il suo funzionamento del dettaglio? Il sistema dovrà pilotare i due motori in AC da 220V 500VA mediante inverter in grado di modularne la velocità e la coppia massima applicabile. Tali due parametri dovranno essere regolabili tramite due trimmer posti in posizione facilmente accessibile in fase di installazione, ma non raggiungibili in alcun modo dall'utente.

Spesso il potenziale committente che ha avuto una idea ed intende realizzarla, mi pone la classica domanda: quanto sarà il costo finito della scheda elettronica? Fermo restando che sto cercando di organizzarmi con un buon tendone da mago e, soprattutto, con un'ottima sfera di cristallo, è quasi impossibile rispondere a questa domanda quando ancora il prodotto non è stato progettato, salvo buttare a caso cifre non ragionate e che molto probabilmente non risponderanno poi alla realtà.

Molto più corretto parlare di "budget" a disposizione, o di "forbice di costo", inserendo tale dettaglio nei requisiti iniziali del progetto. Il progettista cercherà, nei limiti del possibile e conoscendo il quantitativo di schede che si intenderà realizzare, di raggiungere l'obiettivo.