E-book created with OpenOffice Calibre free open source tools.

Cover designed by Colù and edited with Draw Free for iPad, PhotoScape

Ebook sviluppato e redatto nel portale elettronico ElectoYou.

Uno speciale ringraziamento ad Admin, a tutti i forumisti e i blogger che hanno contribuito al progetto.

A zio Kim

I libri sono come i viaggi. Non sai mai cosa ti aspetta, quali cose si troveranno e cosa si vedrà. Ci sono viaggi lunghi, noiosi, insipidi come un bicchiere di acqua tiepida, che ti lasciano così come ti hanno trovato; altri invece sono frizzanti, piccanti come le lacrime da peperoncino, tanto intense nei sensi quanto brevi nel tempo. Ci sono viaggi che vorresti non finissero mai, altri che invece finiscono prima di incominciare. Alcuni cerchi di ripercorrerli ma fastidiosamente ti deludono, altri invece si rinnovano ogni volta e sono inaspettatamente sorprendenti, svelando sempre nuovi aspetti, dettagli che prima non avevamo notato.

I viaggi più belli si scoprono lentamente, con la calma di una volta, infatti il segreto è che non bisogna avere fretta di arrivare.

I viaggi, quelli migliori, non sono semplici e non bisogna arrendersi alle prime difficoltà. All'inizio si farà molta fatica poi pian piano inizieremo ad abituarci e il fastidio si tramuterà in soddisfazione nei risultati.

In questi viaggi, il fine non è la meta, ma il percorso che abbiamo seguito, fatto di tragitti, incroci e magari scorciatoie da scegliere, e i libri ? Ecco i libri... sono come i viaggi.

Indice generale

Premessa 6

L'ora del The. (I/II) 11

L'ora del The. (I//II) 16

Dead Lock. (I/II) 21

Dead Lock (II/II) 24

Il difetto dell'instabilità. (I/IV) 29

Il difetto dell'instabilità. (II/IV) 35

Il difetto dell'instabilità. (III/IV) 39

Il difetto dell'instabilità. (IV/IV) 44

La ventola impazzita. (I/II) 49

La ventola impazzita. (II/II) 53

Lo strappo. (I/III) 59

Lo strappo. (II/III) 65

Lo strappo. (III/III) 70

La temperatura condizionata. (I/III) 76

La temperatura condizionata. (II/III) 81

La temperatura condizionata. (III/III) 89

Silicon Bug (I/III) 96

Silicon Bug (II/III) 105

Silicon Bug (II/III) 111

Premessa

Nelle aziende lo sviluppo di nuovi progetti sono il carburante economico che permette di galleggiare nel burrascoso mare chiamato mercato globale. Se una azienda ha idee nuove da sviluppare può rinnovarsi e dare profitto. Alcune aziende producono cose altre producono servizi. Tutte queste entità sono fatte da persone che hanno mansioni e responsabilità differenziate a seconda delle capacità o delle conoscenze acquisite e tu probabilmente sei una di queste.

Le aziende sono mezzi dall'unico fine, il profitto. Vivono con le persone e di persone, in molti casi si nutrono delle loro ambizioni e se ne fregano di quello che esse pensano e sono.

Alcune aziende si identificano con le persone che le creano, come ad esempio Bill Gates per la Microsoft, Steve Jobs per la Apple o che so io Peter Norton per l'omonima azienda o Mark Zuckerberg per Facebook. Questi mostri del capitalismo nato con la nuovissima e-economy, a cosa devono il loro successo ? Sono le loro idee che hanno fatto la differenza ? Le loro indiscutibili capacità tecniche o commerciali ? Le incapacità altrui ? E' difficile scoprire i fattori che hanno influenzato il processo di creazione e di sviluppo di queste multinazionali create dal nulla e sul nulla.

Tutte queste aziende, che hanno elevati contenuti tecnologici, hanno però sicuramente un fattore in comune. Questo elemento che probabilmente è il valore aggiunto vero è dato dalle persone o meglio da una categoria di persone dai più definita strana e che sono il vero innesco delle fortune aziendali appena citate. Questi personaggi scuri adombrati si vedono entrare e uscire da stanze dall'accesso negato ai più. Dentro ci sono scrivanie piene di strumenti elettronici che lampeggiano istericamente con documenti cartacei sparsi a casaccio da tutte le parti. Questi particolari soggetti sono chiamati Nerd e tu probabilmente non sei uno di questi.

Sono diversamente intelligenti e se ne vantano, per questo non leggono libri ma solo specifiche tecniche e giornali specialistici.

Quando si parla di giornali specialistici però non si parla dei progetti editoriali di informazione mediatica tradizionale. I vari Focus e i programmi alla Quark andrebbero in fallimento se contassero sul loro supporto. Sono odiosamente solitari, sociofobici, spiccatamente egoisti, incapaci di stabilire legami affettivi con alcuno. Questa incapacità comportamentale dipende sostanzialmente dal fatto che un po' non ci riescono per natura e un po' perché non vogliono riuscirci. Insomma in qualche modo ci sono ma tanto ci fanno.

Spesso però sono come il fuoco della paglia che serve solo per accendere il fuoco e finiscono per bruciarsi scomparendo come nebbia al sole rimanendo solo nella memoria delle idee che hanno creato.Il libro purtroppo si rivolge ad un pubblico prevalentemente di tipo tecnico, elettronico e/o informatico per la particolare specificità degli argomenti. Un Nerd vero non lo leggerà mai per tutti sarà comunque un viaggio tortuoso.

Questo scritto nasce nella rete e dalla rete ne prende fortemente le caratteristiche letterarie peculiari, non è un tutorial, ne tanto meno un trattato, le esperienze insegnano poco anche agli addetti ai lavori ma forse comunque ci si può confrontare lo stesso perché un termine di paragone un riferimento, o anche solo un atteggiamento spesso aiuta a chiarirsi le idee, qualsiasi siano i problemi che la vita ci ha donato.

Admin 9/08/2011 ore 11:04

“Vedi, schumy91, quello che hai letto non ha proprio lo scopo di spiegare i concetti della programmazione o della realizzazione di un hardware. E' un racconto che cerca di trasferire al lettore sensazioni, riflessioni, atmosfere di chi svolge professionalmente un determinato lavoro: in questo caso progettista di sistemi embedded. La comprensione effettiva del contenuto è diversa a seconda del lettore. Chi fa lo stesso tipo di lavoro, o lavori simili, si sintonizza bene con terminologia tecnica, problemi e soluzioni, a vari livelli a seconda del grado di vicinanza della sua attività con quella dell'autore.

Chi invece sta iniziando, o sta pensando a quel tipo di lavoro, o svolge lavori diversi, può intuirne le problematiche, avere un'idea delle persone, degli ambienti che ne sono la necessaria cornice, ma, fondamentalmente, vedere o sentire come il lavoro diventi parte integrante della vita del protagonista, come lo è, o diventerà, il suo. E magari avvertire che, pur nella diversità, in tutti lavori c'è uno stesso filo che unisce le persone che interagiscono attraverso le cose.

Quindi se anche non si è compreso appieno il progetto descritto, si può ad esempio, chissà, come Kirkegaard aver attraversato silenziosi il traffico osservando, da una Polo anni' 90 con gli U2 a palla, gli altri, sulle loro automobili, attraversati come lui da pensieri, forse molto diversi nelle specifiche, ma simili ai suoi per la composizione del quadro disegnato da quel filo che traccia la vita di ognuno di noi. E magari cogliere nel Nerd Kirkegaard, il bisogno di una confessione che stemperi una solitudine indotta da opcode che, assorbendo forse troppa parte della sua vita, si rincorrono nella sua mente alla ricerca di un inesistente programma perfetto, confuso a volte con il mondo reale.”

L'ora del The. (I/II)

Pluralitas non est ponenda sine necessitate o meglio non presumere cause inutili o improbabili per spiegare qualsivoglia fattispecie, laddove esistano cause più probabili e verificabili ( Rasoio di Occam )

15/07/2000

Claude era appena entrato in ditta, con la macchina luccicante appena uscita dal carrozziere. Il collega che si era licenziato gli aveva dato il ben servito, prima di andare via, gli aveva sciolto con l'acido le guarnizioni del parabrezza.

Entrò in ufficio ma si notava la particolare tensione nei movimenti. Sapeva benissimo perché era finito in quella situazione visto che era l'autore della spiata al capo che poi aveva portato come conseguenza il licenziamento per furto del collega Franz. Questo era accaduto qualche giorno prima ed era presumibile la conseguenza di subire un atto di vendetta. Lui non voleva parlare e io mi astenni dal fare domande, era evidentemente inutile.

L'azienda dove lavoravo produceva e produce forni industriali per la saldatura di schede elettroniche.
Il sistema progettato per il controllo di queste macchine era composto da un assieme elettronico suddiviso in 3 parti.

C'era una scheda con core ARM ed interfaccia display lcd a 9', dove giravano i vari PID per il controllo in temperatura delle camere termiche. C'era poi una scheda chiamata “di potenza” che attraverso optotriac si parzializzavano alcuni carichi resistivi in modalità burst firing. Infine per ultimo ma non per importanza ( last but not least ) avevamo una scheda di interfaccia a microprocessore ( marca Hitachi, ora Renesas della famiglia H8/300) per la lettura delle temperature che era effettuata con delle tradizionali termocoppie.

Il sistema prevedeva inoltre il controllo di un nastro trasportatore ( che era in realtà una rete in acciaio ), collegato ad un motore a 12 volt in continua. Il motore, installato all'interno del carter laterale, trasmetteva il movimento alla rete attraverso una puleggia che demoltiplicava di un fattore 3 il movimento.

L'albero del motorino proseguiva verso l'esterno del carter, e dal di fuori si installava una ruota in teflon forata con buchi equidistanziati. Un fotoaccopiatore ottico per mouse, un po' "modificato", veniva utilizzato per leggere il movimento della ruota e misurare la velocità del nastro.

La storia di quella specie di encoder nessuno me la raccontò, ma da qualche parte trovai delle ruote in lamina d'acciaio alesate e abbandonate dentro qualche sperduta scatola nelle scaffalature dell'azienda. Probabilmente durante le prime infauste prove qualcosa era andato storto e furono sostituite con le ruote in teflon. Modificando l'interasse tra un foro e l'altro ne allargarono la distanza e quindi diminuirono la frequenza della tachimetrica che poi il microcontrollore avrebbe dovuto leggere. Sicuramente hanno perso in risoluzione però probabilmente nello stesso tempo hanno anche sollevato l'H8 da un interrupt frenetico. L'H8 è un solido microcontrollore molto blasonato ma notoriamente non viene considerato un fulmine di guerra. Passando però dalla lamina d'acciaio al teflon dovettero modificare la larghezza della ruota, in questo modo avrebbero reso impossibile l'uso di quel fotoaccopiatore da mouse così come era stato costruito.

Evidentemente risolvettero l'imbarazzo con un efficace escamotage. Nella procedura di montaggio avevano previsto una voce detta “modifica del sensore ottico”. In cosa consisteva questa modifica ? E' presto detto, un solerte operaio chiamato tizio "segava" il sensore in due per poi montarlo "allargato" su un supporto che veniva installato sotto la ruota forata. Come soluzione era un po' da pezzenti, però indubbiamente funzionava.

Se non ricordo male sussistevano problemi sulla lettura di temperatura delle termocoppie, e rimuginavo su come implementare una eventuale taratura, ma le cose non erano semplici. Avrei dovuto riconsiderare tutto il canale di acquisizione dati che avevano progettato per tale lettura è implementare un bagno termostatato per la calibrazione delle termocoppie . Questo ovviamente era stato sottostimato dalla amministrazione visto che non c'erano specifiche ne tanto meno note tecniche.

Per la commessa in corso avevamo riempito il capannone con un paio di file di forni in collaudo e così, tanto per chiarire, avevamo un centinaio di milioni ( in lire ) di materiale sotto test che dovevano essere evasi.

Come parte del collaudo si manteneva accesa la macchina per l'intera giornata e ogni tanto si dava un' occhiata verificando le funzionalità e segnalando le eventuali anomalie.

Verso le 17 al termine della giornata arrivò la segnalazione che il nastro di un forno ( e solo uno ) aveva un andamento irregolare, accelerava e decelerava fuori controllo e dopo qualche minuto si attivava spontaneamente l'allarme di nastro bloccato.

Il collaudatore del forno, dopo una serie di verifiche circostanziali applicò anche il "metodo windows". Ovviamente non funzionò visto che non avevamo a che fare con il sistema operativo omonimo. Accendendo e spegnendo la macchina non riprese il funzionamento nemmeno temporaneo e non ci fu alcun modo di ripristinarlo. Così un po' esausti dalla lunga giornata di lavoro, e estremamente sconfortati per la presunta disastrosa situazione spegnemmo definitamente il forno sperando che la notte portasse consiglio ( ovviamente al forno ... ).

Il giorno dopo lo riaccendemmo e questa volta, con piacere, constatai che tutto il sistema aveva ripreso il suo andamento regolare.

Tentai di modificare le impostazioni di velocità e testai la parte di allarme blocco nastro in modo casuale e pseudo isterico per vedere se c'erano anomalie, ma non rilevai niente di significativo.

Per tutto il giorno sul forno non ci furono problemi, risollevandomi un po' l' animo ritenni che la cosa fosse un tipico "effetto fantasma" che capita sovente quando siamo ossessionati da un terrore che speriamo non ci accada mai. Ma la sera come una mazzata su un bicchiere di cristallo, mi risvegliai di botto quando nuovamente mi chiamarono dalla produzione per riverificare il malfunzionamento del motore.

In quel momento capii che purtroppo non era un problema fantasma. Guardai il bordo del pc e notai che erano di nuovo le 17...

Ciò che prima era un secondario indizio divenne un incubo terrificante nei giorni successivi.

Il nastro trasportatore smetteva di funzionare tutti i giorni alle 17, il fantasma dell'azienda si manifestava all'ora del tè...

L'ora del The. (I//II)

Non attribuire a cattiveria ciò che puoi facilmente spiegare con la stupidità ( Rasoio di Hanlon )

13/07/2000

Faceva un caldo soffocante in quei capannoni di periferia. L’ufficio era una specie di soppalco con un'unica piccola finestra che dava verso l’interno del capannone, e lì davanti a me, i sei forni in collaudo perenne.

Claude entrò appoggiando il casco sulla scrivania, evidentemente era venuto in moto approfittando della bella giornata. Accese il computer per mettersi in pari con le registrazioni degli interventi avvenuti nell'ultima settimana, le continue telefonate dai clienti negli ultimi giorni l'avevano rallentato.

Fabia era invece la segretaria dell'ufficio anche lei particolarmente introversa come tutte quelle donne che lavorano in aziende di questo tipo. Era alle prese con l'aggiornamento del magazzino e capivo come fosse particolarmente frustrante passare il tempo fra codici e descrizioni di materiale elettromeccanico indecifrabili. Chissà perché il lavoro deve essere vissuto come un percorso di redenzione dal peccato della vita , questo è quello che si chiede la gente, quando si accorge, troppo tardi, di aver concentrato tutte le risorse disponibili per ottenere quell' utopico posto sicuro, alla fine, in grado solo di svilire il personale senso della nostra esistenza. Anche lei, silente, fra correttori a nastro ed evidenziatori si chiedeva se ne valeva davvero la pena, spendere tutta la sua vita con il perenne senso di frustrazione su quel monitor. La sua scrivania era sempre piena di cartelle con colori ormai sbiaditi dal tempo. Un giorno prese un postit dal colore acido e lo attaccò al lato del monitor,

“Almeno diamoci un po' di tono...” pensava.

Il processo di produzione, chiamato con il termine di commessa, l’avevo bloccato per precauzione, non volevo rischiare di spedire altri apparecchi che potessero avere l'infausto problema. Era difficile lasciarsi distrarre dalla parte economica.

Avevo “attraversato” il codice decine di volte partendo dalla lettura della tachimetrica al controllo del PWM per poi analizzare nel dettaglio tutti gli interrupt. Verificai anche il firmware della scheda di temperatura, per poi infine analizzare gli schemi elettrici di tutto l'hardware sviluppato.

Gli schemi li conoscevo ormai a memoria, come pure tutti i componenti, ma intuivo che ero ancora lontano dalla soluzione del problema.

Il giorno prima avevo modificato il firmware facendo stampare su display, in sequenza: lo stato della lettura tachimetrica e il pwm comandato, senza riuscire a trovare niente che giustificasse il malfunzionamento.

Quando poi arrivò l’ora fatidica, notai che effettivamente i valori di tachimetrica cominciavano a variare, così come variavano anche i valori dell’uscita pwm; ma davvero per quanto mi sforzassi non c'era nessun elemento che potevo utilizzare per giustificare una relazione plausibile di causa-effetto.

causa = ore 17

effetto = errore di velocità nastro

Il concetto di causa-effetto è insito in ognuno di noi ed e come se avessimo una sorta di imprinting nella nostra coscienza che ci permette di comprendere autonomamente il suo significato. Diventa quasi una ossessione quando nell'estremo tentativo di conseguire fini, che possono essere legittimi, facciamo diventare tali anche i mezzi più meschini e sordidi. Si dice che Aristotele abbia definito il sapere come la scienza delle cause, se lo dice lui...

Il giorno dopo, erano le 16, mi girai guardando di sotto sporgendomi dalla finestra del mio ufficio che peraltro non potevo aprire. Così notai uno degli operai che entrò da una porta laterale e attraversò il capannone dirigendosi verso l’uscita, per poi aprire il grande portone di ingresso.

Le ore più calde del giorno erano passate, e una leggera brezza lenitiva entrò dentro.

Corrado si girò e salutandomi mi fece il dito. Io contraccambiai mandandolo a quel paese, ma sorridendo più del solito perché in quel momento capii dove era il problema.

Ultimai la documentazione che dovevo spedire, con i disegni del cablaggio interno per un nuovo innovativo forno, e attesi le 17.00.

Scesi quindi dall’ufficio e raggiunsi la zona di collaudo, mentre nel frattempo il nastro incominciò ad aumentare e diminuire di velocità così come faceva tutti i giorni.

Guardai quel maledetto encoder era arrivata la sua ora. Sentivo nel sottofondo una colonna sonora epica di Morricone a mi avvicinai senza toccare il forno, mi spostai quindi di lato, mettendomi proprio davanti all'encoder. Alzai le mani alla Harry Potter e magicamente in quell'istante, il problema svanì come d’incanto.

Il nastro, dopo un secondo riprese la sua velocità regolare senza variazioni e senza mandare in allarme il sistema. Cos'era accaduto ? La punta di luce del sole che arrivava sull’optoisolatore dell’encoder, tutti i giorni alle 17.00, l’avevo coperta con l'ombra del mio corpo.

Avevo finalmente giustificato la legge causa-effetto.

Causa = ore 17

Quindi = Optoisolatore colpito dalla luce del sole perchè il carter laterale non era stato montato e a quell'ora il sole si abbassa penetrando all'interno del capannone grazie anche a Corrado che un ora prima aveva aperto il portellone di entrata.

Effetto = errore di velocità nastro.

Stavo per tornare sopra quando Claude scese con il casco da una parte e i Rayban dall'altra. Dietro c'era Flavia, con la testa sempre rivolta sui piedi e li salutai notando una sorta di perplessità nei loro occhi, evidentemente per l'inaspettata confidenza che stavano prendendo.

Raggiunsi il piano superiore sorridendo e sbloccai la commessa, i forni adesso potevano partire.

Dead Lock. (I/II)

.. il fiume screziato,
che scorre di continuo,
e mai due volte nello stesso modo,
fluendo per molti luoghi,
come se stesse immobile in uno.

... nell'atmosfera
senz'ombra,
la conoscenza delle
cose è dappertutto ma non percepita.

Wallace Stevens

16/04/2001

I forni erano montati all'interno del capannone in fila con un discreto ordine ed erano verniciati di un color sabbia piuttosto neutro. Questo li rendeva tutto sommato abbastanza attraenti, anche se il colore blu dei carter mi lasciava sempre un po’ perplesso.

Il sistema di controllo era il solito trittico di schede: scheda display, scheda temperatura, scheda potenza.
L’interfaccia di temperatura e il display erano collegate via seriale con un protocollo standard jbus ( un tipo modbus modificato ). Il display basato su ARM oltre alla linea di comunicazione dati con la scheda di temperatura prevedeva una linea di allarme dedicata per l'autospegnimento che veniva effettuato direttamente dalla scheda di potenza. Anche quella volta, ricordo, si inziò la produzione verso la fine dell'inverno.

I primi clienti di quella meravigliosa primavera, chiamavano, non chiedendoci come stavamo di salute (ingrati), ma bensì bestemmiando come lupi turchi perché le macchine, dopo mesi di corretto funzionamento, senza alcun preavviso dopo una giornata lavorativa, si spegnevano da sole.

Se la macchina non era presidiata la cosa ovviamente era particolarmente pericolosa, perché proprio per la tipologia di uso del macchinario, spegnere la macchina durante il processo di produzione poteva portare a condizioni estreme con incendi spontanei dovuti dalla permanenza di schede elettroniche all’interno di camere che, per inerzia termica, avrebbero mantenuto elevate temperature.

Gli interventi telefonici non portarono ad alcun risultato. Così fummo costretti ad una sostituzione in garanzia al cliente ed una riparazione in sede.

Come era facile immaginare, il forno fu ritestato e ricollaudato senza rilevare il problema. Pur restando accesa per giorni, il guasto denunciato, come prevedibile, era sparito. Nello stesso momento, dopo alcuni giorni lavorativi, il forno spedito al cliente in sostituzione, cominciò anch’esso a spegnersi spontaneamente nelle stesse modialità del forno precedente.Tutto questo avveniva sempre alla fine della giornata e sempre senza alcun avviso preliminare.

Uno dei bug più celebri che un programmatore "vero" prima o poi dovrà affrontare nella sua vita, è chiamato in gergo dead lock. In italiano il viene tradotto abbraccio mortale ed è un particolare bug che si viene a creare nel nostro software/firmware, quando il sistema prevede più processi concorrenti.

Per capire meglio cosa significa, in questa pagina di wikipedia viene spiegato il termine (link).

Per quale motivo ho pensato subito a questa condizione? Molto semplicemente perché l’unico fattore che poteva portare ad una richiesta di spegnimento istantaneo, era legata solo alla condizione di un deadlock interno al codice rilevato dal watchdog.

Si lo so, molti di voi esausti arricceranno il naso infastiditi per questi termini tipo watchdog, ma la traduzione in italiano cane da guardia è un po' troppo generica. Evito di aggiungere definizioni alle definizioni disponibili, così riprendo la spiegazione di watchdog presa da wikipedia (link) perchè è sufficientemente esaustiva ai miei scopi. Questa mia infausta convinzione però, mi ha portato ad una penosa e faticosa ricerca delle condizioni in grado di generare un dead lock nel mio firmware, distogliendomi però da un fattore importante.

Quello che sottovalutavo era che il sistema elettronico non era fine a se stesso, ma parte integrante di un sistema molto più ampio che era appunto … il forno.

Dead Lock (II/II)

siamo gocce nel fiume del tempo (anonimo)

23/05/2001

Perchè non impariamo dagli errori passati ? Questo mi chiedevo in quei giorni. Le memorie passate a cosa servono se poi non possiamo usufruirne ?

Viviamo come se fossimo in uno stato di sogno permanente gli eventi accadono con l'illusione di poterli controllare e invece ne siamo vittime fagocitati dal sistema che ci circonda e per assurdo anche da noi stessi in un incredibile atto di autocannibalismo.

Il firmware del sistema era collaudato oramai da anni e poche erano state le modifiche.

Il problema più grosso, in questo momento, era il passaggio alla nuova piattaforma ARM. L’evoluzione più importante sarebbe stata implementata di lì a poco. Infatti era in previsione un superforno previsto per le medio grosse produzioni.

Questo mammuth meccanico pesava un paio di tonnellate, e avrebbe avuto più del doppio delle camere termiche rispetto al forno più grande attualmente prodotto. Le dimensioni sarebbero state importanti (quasi 5 metri), e con una nuovissima camera termica che prevedeva l'utilizzo di ventole tangenziali. Il firmware era molto solido. Lo scheletro principale lo aveva progettato un amico diversi anni prima, e da lì in poi replicato nei vari prodotti. Tutte le macchine poi avevano mantenuto le stesse caratteristiche pur cambiando le piattaforme hardware, un altro modo per dire che semplicemente avevano cambiato microcontrollore.

Ma veniamo al nostro hardware ed in particolare al nostro watchdog tentando di descriverlo meglio.

Il watchdog era esterno, ed era fatto così come lo facevano i vecchi con un mutivibratore monostabile (MC74HC4538A).
Funzionava, più o meno, in questo modo: la scheda lcd togglava un'uscita del micro ad ogni ciclo di main del programma, questo avrebbe triggerato tutte le volte il monostabile. Un RC - sezione di circuito composto da una resistenza a da un condensatore - calibrato a 3 secondi definiva il tempo massimo del monostabile se infatti non si retriggerava entro quel periodo, il monostabile faceva scattare l’allarme.

Con un oscilloscopio verificai la frequenza in uscita all’LCD, notando subito qualcosa di anomalo.
L’uscita togglata era molto fitta e di elevata frequenza, ma con alcuni buchi che in alcuni casi arrivavano vicini al secondo. Questi buchi non pregiudicavano il funzionamento perché ampiamente al di sotto del tempo di scatto del monostabile....

Analizzando il codice non mi ci volle molto per capire il motivo di quei buchi.

Il protocollo jbus era, diciamo, abbastanza pesante, più che altro per la scheda di temperatura: era lei infatti che ogni tanto rispondeva con qualche ritardo causando quel mancato refresh dell'watchdog… ma ero di nuovo lontano dal problema.

Ricominciamo.
Per tutto l’inverno non abbiamo avuto segnalazioni, poi, da un paio di settimane, tutti i forni presentavano lo stesso malfunzionamento, ed ora riusciamo a vederlo anche da noi.

Uno dei problemi meccanici principali nella progettazione di un forno, è il controllo del calore.
Il calore è una serpe sinuosa. In un forno progettato male, dopo qualche ora accade che il calore delle camere termiche si distribuisce su tutta la superficie esterna con tutte le conseguenze disastrose che potete facilmente immaginare. Per evitare questo è necessaria una accurata progettazione degli assiemi meccanici in grado di rallentare il più possibile il propagarsi del calore.

Il calore del forno.

E se fosse questa la causa ?

Dovevo provare l’ipotesi.

Mi sono munito di termocoppia e di uno sverniciatore. La termocoppia l'ho fissata sulla scheda con del nastro Kapton, poi ho acceso il forno e con lo sverniciatore al minimo ho incominciato a scaldarla.

La temperatura non doveva essere elevata per non danneggiare i componenti della scheda, ma doveva essere all’interno del range operativo( non superiore ai 70°C ).

Dopo un minuto l’allarme scattò, e misurando rilevai che la temperatura della scheda era di poco superiore ai 50 gradi.

Bingo.
Ripeto i test e verifico l’uscita lcd con l’oscilloscopio.
Cosa c’era nel circuito di cosi sensibile alla temperatura?
Semplice. Il condensatore della sezione RC del multivibratore.
I condensatori in genere derivano molto al variare della temperatura, comunque da datasheet ( ebbene si sono andato a leggermi il datasheet di un condensatore... ) ho visto il grafico capacità/temperatura, si vedeva benissimo come degenerasse decisamente anche solo con variazioni di qualche decina di gradi. Se il nostro condensatore è di bypass sulla alimentazione possiamo chiudere un occhio ma nel caso di un circuito RC dimezzare la capacità porta l'inevitabile conseguenza di variare il tempo di minimo di trigger del monostabile dai 3 secondi previsti a circa 1 secondo... poi i buchi del toggle causati dalla trasmissione jbus facevano il resto.

Dopo un provvido consulto abbiamo risolto il tutto aggiornando la lista parti e sostituendo il nostro condensatorino termopatico con uno della serie x7r che sono estremamente più stabili.

Il difetto dell'instabilità. (I/IV)

Sotto la fragile crosta della civiltà si agita il freddo caos. E in certi posti il ghiaccio è pericolosamente sottile. ( V for Vendetta)

05/10/2004

Un Nerd vive per risolvere problemi. Se non li ha se li crea. Non cerca aiuti e non ne vuole. I problemi l'esaltano, questi infatti, più grandi sono e più grande diventa il suo ego. Sono una pacchia per gli uomini della amministrazione perchè hanno proprio bisogno di un Nerd dal cosmogonico ego che soddisfi i loro deliri...

Uno degli elementi che permette al Nerd di trovare le soluzioni più impossibili e quello di provare le ipotesi che si pone davanti. Per fare un esempio di cosa significa provare un ipotesi vi racconto quanto è accaduto qualche migliaio di anni orsono quando un israelita Nerd mise alla prova il Creatore

Giudici 6

³⁶ Gedeone disse quindi al [vero] Dio: “Se stai per salvare Israele per mezzo mio, proprio come hai promesso, ³⁷ ecco, io tengo esposto un vello di lana nell’aia. Se la rugiada sarà solo sul vello ma tutta la terra sarà asciutta, dovrò quindi sapere che tu salverai Israele per mezzo mio, proprio come hai promesso”. ³⁸ E così avvenne. Quando il giorno dopo si alzò di buon’ora e torse il vello, spremette dal vello abbastanza rugiada da riempire d’acqua una larga scodella da banchetto.

Per risolvere un problema è importante riuscire a dimostrare le ipotesi che si fanno sulle cause del problema. Un errore di valutazione potrebbe essere come minimo fastidioso sino ad arrivare al raro disastro fatale. In questo caso Gedeone nel racconto cercava una conferma divina ma una volta ottenuta si era trovato in una situazione critica perché adesso doveva necessariamente dimostrare che quello visto era davvero un miracolo. Oggi gli eventi miracolosi passano sotto il vaglio dei RIS ma Gedeone non avendo un team laico scientifico a disposizione doveva trovare il modo di provare l'ipotesi e così cercò di ottenere la conferma in un altro modo...

³⁹ Comunque, Gedeone disse al [vero] Dio: “Non divampi la tua ira contro di me, ma lasciami parlare solo una volta ancora. Lasciami fare, ti prego, una prova col vello, solo una volta ancora. Resti asciutto, ti prego, solo il vello, e su tutta la terra ci sia rugiada”. ⁴⁰ Quella notte Dio fece dunque così; e rimase asciutto solo il vello, e su tutta la terra ci fu rugiada.

Raggiungo l'ufficio e accendo il pc. Lo schermo diventa blu e parte in automatico un checkdisk del sistema. Meglio assecondare certe richieste anche se il più delle volte sono inutili.

Questa volta il sistema era relativamente più semplice. La scheda, in questo caso mono processore, era un classico Avr128. C’era un convertitore esterno a 12 bit, un DAC a 8 bit per replicare le uscite di potenza, un paio di interfacce seriali di cui una USB, un modulino esterno che chiamavamo il pentolino, con all’interno un ponte Wheatstone. Nel link viene descritto il circuito classico e le sue implementazioni. Nel nostro caso, in un ramo del ponte c’erano due resistenze note, nell’altro ramo una NTC ( per la misura di temperatura ) e una serie di resistenze per la calibrazione manuale.

Il sistema era una applicazione medicale e doveva occuparsi della termostatazione di 4 tonnellate di uno strano materiale ferromagnetico (Neodimio se non ricordo male ) con precisioni superiori al millesimo di grado.

Un gigantesco magnete permanente attirava tutto quello che gli stava intorno. Cancellava card, resettava PC ed i cacciaviti partivano come proiettili. La prima volta che raggiunsi il macchinario, nonostante gli avvertimenti di prestare cautela, mi avvicinai troppo con la borsa dove avevo il portatile, sentii fisicamente l’attrazione magnetica che tirava il povero portatile alzando la borsa. Rimasi un attimo come allucinato, e quando mi ripresi mi spostai immediatamente pensando di essermi giocato l’hardisk interno.

Una delle prove più belle era quella di prendere una piastra in alluminio e di metterla sotto la verticale del flusso magnetico. La piastra, ovviamente, non era minimamente influenzata dal campo magnetico, ed era possibile girarla su se stessa, ma solo molto lentamente. Se appena appena si tentava di ruotarla più velocemente, una forza nascosta proporzionata alla velocità impediva il movimento. Il fisico, divertito dalla mia scimmiesca curiosità, mi spiegò che l’effetto era il “semplice” fenomeno di induzione magnetica causato dalle correnti che attraversavano la piastra in senso contrario al flusso e creando cosi un campo magnetico che si opponeva al movimento.
Sviluppai lo scheletro del sistema in poco tempo, e dopo un paio di settimane implementai il PID.
Dopo un’altra settimana iniziammo le prove per trovare i parametri idonei. In una settimana avevamo ultimato tutto il controllo e trovato una prima serie di parametri che garantivano la termostatazione prevista.
Di lì a poco misi su tutta una serie di prototipi. E poi passammo alla seconda serie per ultimare tutte le ulteriori funzionalità della scheda.

Bisognava aggiungere infatti una semplice porta seriale.... USB.

La cosa non è che mi piacesse molto, comunque, visto che era prevista nelle specifiche preliminari, implemento mio malgrado i driver per utilizzare l'interfaccia seriale che sfrutta un chippetto della FTDI. Mi invento un protocollo di comunicazione dati in ASCII per leggere lo stato istantaneo delle uscite e degli ingressi, e vi aggiungo anche una serie di comandi in scrittura per la parametrizzazione del PID on fly. Visto poi che il protocollo era un supporto ausiliario non importante ai fini della macchina, implemento nel protocollo anche una semplice checksum finale a somma di XOR. Dopo di che la disabilito istantaneamente per usare i comandi manualmente con un terminale seriale.

Nuovo hardware, nuovo display, si prepara tutto e si mettono su le prime macchine.

Tutto procede a gonfie vele ma dopo un mesetto circa ricevo in ufficio la telefonata del cliente.
"Pronto ? Ciao Flavio... dimmi .. si ... no... ma io non ho toccato nulla... può darsi.... ora ci guardo subito... ti so dire ".

Ebbene sì, passiamo la vita con le solite storie: non ho toccato nulla, prima funzionava, ma ieri funzionava... e così via in un crescendo di triste fantasia; c’è un baco nel compilatore, c’è un baco nell’hardware del microcontrollore ( il famoso silicon bug ) .

Il successo con le stelle della Paramount che giravano intorno crollò, e si trasformò in un nauseabondo caldissimo girone infernale.

La nuova serie di macchine, testata e collaudata per alcuni mesi, sembrava non funzionare più.

Il problema denunciato era proprio sul controllo il PID che smetteva di funzionare, ovviamente casualmente, magari dopo giorni, e senza che nessuno operasse nella macchina.

Le oscillazioni di temperatura superavano abbondantemente il grado, e in queste condizioni le funzionalità dell'apparato erano pesantemente compromesse. L'instabilità della temperatura faceva variare i valori del flusso magnetico in modo inaccettabile.

Il disastro sembrava arrivare al galoppo con tanto di squilli di tromba e un seguito di apocalittiche conseguenze.
Eseguo alcuni test, ma non sono in grado di ripetere le condizioni del sistema perché il mio piccolo simulatore lavora costantemente fuori controllo, visto che la massa da 4 tonnellate non è poi così semplice da replicare.

Così parto per la trasferta, raggiungo la sede di produzione e inizio il mio test.

Il difetto dell'instabilità. (II/IV)

Il carattere complessivo del mondo è il caos per tutta l'eternità, non nel senso di un difetto di necessità, ma di un difetto di ordine, di articolazione, forma, bellezza, sapienza e di tutto quanto sia espressione delle nostre estetiche nature umane. (Friedrich Nietzsche)

13/10/2004

I sistemi di controllo con setpoint controllati con PID, necessitano di una fase delicata chiamata di tuning dove vengono ricercati i parametri che permetteranno al PID di riuscire a raggiungere e a mantenere il valore di target impostato. La fase di tuning si suddivide sostanzialmente in due parti. Nella prima parte si cerca di impostare il PID in modo che raggiunga il setpoint ed inizi ad oscillare intorno ad esso. Nella seconda fase di affinamento, si cerca di trovare la combinazione di parametri in grado di ottenere l’oscillazione più piccola possibile. Come è facile immaginare i sistemi PID hanno molteplici applicazioni. Vengono utilizzati come regolatori di velocità oppure, come in questo caso, come sistemi di termostatazione.
Con l’avvento dei sistemi embedded a microcontrollore attraverso la logica di programmazione del firmware interno, si può arrivare ad ottenere eccellenti risultati con poco sforzo e a costi contenuti. Bisogna anche considerare che i controlli PID originariamente non erano implementati via fimware, ma bensì elettronicamente o addirittura erano meccanici. Uno dei metodi più celebri per risolvere la fase di tuning è chiamato metodo di Ziegler-Nichols. Questo aveva il pregio di semplificare la ricerca dei parametri per la stabilità perché la modellizzazione matematica del nostro sistema è generalmente d' indubbia complessità.

PID è un acronimo creato dagli inglesi e che sta per Proportional Integral e Derivative. In italiano si traduce con gli identici termini Proporzionale Integrale e Derivativo. Queste parole sostanzialmente identificano il tipo di intervento del sistema di controllo in funzione dell’errore rilevato. Cercherò di descriverli in modo semplificato per capire un po’ di più di cosa stiamo parlano.

Termine proporzionale Kpe(t)

Il termine proporzionale è la causa più importante della velocità di stabilizzazione del sistema. Come ci anticipa il termine l’uscita sarà proporzionale all’errore rilevato rispetto al setpoint da raggiungere. Il pregio di questo parametro è quello di riuscire a reagire velocemente in caso di condizioni di instabiltà anche estreme. Se il parametro è abbastanza consistente, può innescarsi una oscillazione ( in genere molto ampia ) intorno al setpoint stesso, se non lo è, e, ad esempio, il nostro sistema ha un errore costante, il setpoint non sarà mai raggiunto.

Termine integrativo

Il termine integrale è invece il termine che possiamo considerare come la parte storica del nostro errore. Dal punto di vista analitico l’integrale dell’errore equivale alla sommatoria dell’errore od anche, per piacere dei matematici, al calcolo dell’area sottesa dalla funzione stessa dell’errore.

Questo termine è in grado di risolvere i problemi che il termine proporzionale non è in grado di fare e che sono appunto le ampie oscillazioni o il mancato raggiungimento del setpoint.

Termine derivativo

Il termine derivativo in pratica rileva la velocità dell’errore o, per i matematici, la pendenza della funzione dell’errore. Identifichiamo così il grado di reattività del nostro sistema. Il suo utilizzo è particolarmente utile quando vogliamo ridurre gli effetti tipici dell’overshot iniziale creato ad esempio dal termine proporzionale.

L’implementazione dei PID li suddivide sostanzialmente in due tipi: PID sequenziali o PID paralleli. Descriverli con un firmware è più o meno difficile a seconda della funzione matematica utilizzata. Indubbiamente però la parte più difficile è appunto quella di tuning.

Nell' applicazione che dovevo implementare, il sistema di controllo temperatura era già collaudato e verificato dalla preserie che funzionava correttamente già da diversi mesi. I problemi come anticipato erano solo sui prototipi della nuova release hardware.

Il difetto dell'instabilità. (III/IV)

What I mean is something like a closed circuit. Everybody on the same frequency. And after a while you forget about the rest of the spectrum and start believing that this is the only frequency that counts or is real. While outside, all up and down the land, there are these wonderful colors and x-rays and ultraviolets going on ( Entropy ? Thomas Pynchon)

28/10/2004

La gente è fatta di sguardi. Migliaia di occhi ti guardano come tu guardi loro. Dietro ad uno sguardo c'è un universo di pensieri ed emozioni che ci dominano e ti dominano. Qualche volta uno sguardo ti salva, molte volte invece ti porta alla dannazione. Gli sguardi sono fastidiosamente silenziosi perché non danno appigli alla tua curiosità, non ti permettono di capire cosa c'è dietro e ti lasciano solo alle tue misere alternative. Alla fine soccombi alla più grossa tentazione di distogliere il tuo presunto prezioso sguardo dalle persone per osservare le povere cose, sperando che questo ti faccia soffrire di meno... ma non servirà. Sei semplicemente uno che non si rende conto di essere immaturo perché non ha ancora capito che la vita è un equilibrio sottile da percorrere continuamente per tutti, sia che apparteniamo a ceti sociali discriminati, sia che facciamo parte della casta di privilegiati. La verità è che nessuno è escluso.

Raggiungo il cancello dell' azienda cliente e chiedo il permesso per entrare all'uomo dentro la recepition esterna che mi prende il nominativo dalla carta di identià e mi consegna il pass. Parcheggio l'auto aziendale e mi carico su le borse con l'attrezzatura tecnica ed il portatile. Noto che uno degli ampi portelloni laterali è aperto, e vedo Flavio che mi stava aspettando. Una persona davvero squisita e disponibile, in grado di affrontare il controllo dello spin di un atomo e, tornando a casa, il ben più complicato controllo di due scatenate figlie adolescenti fanatiche dei Tokyo Hotel. Poi arriva Marco e mi saluta , sempre trafelato, scusandosi per non potersi fermare, cedendo sempre a quel piccolo difetto egocentrico che abbiamo quando ci vogliamo far vedere sempre impegnati.

C’è da attendere un attimo perché devono ultimare il cablaggio di connessione con il rack di controllo. Così Flavio mi porta nel capannone a fianco che apparteneva alla Ansaldo superconduttori per una veloce visita.

Ad una decina di metri c’era una strana struttura alta 3, 4 metri una specie di gigantesco anello informe che mi ricordava gli orologi plasmati del Dalì. La struttura dell’anello era come un wafer con spessi anelli di rame da un cm intervallati da vetronite. Le dimensioni e la forma erano tali da essere davvero estremamente originali e Flavio ebbe la cortesia di anticipare il mio stupore. Quello strana struttura era una piccola parte di un'altra macchina che avrebbe permesso di mantenere sospeso del plasma liquido (Fisica del plasma), e la sua forma era dovuta ad uno studio recente in grado appunto di permettere in modo “efficente” questa miracolosa sospensione, ma mi chiese anche di essere cortese con le domande perché non aveva la più pallida idea di cosa stesse parlando e che wikipedia poteva soddisfarmi maggiormente.

Un po’ dappertutto macchine per il controllo dello zero assoluto, barre conduttive disposte per il cern di Ginevra, e poi infine, nella sezione metalmeccanica, un gigantesco tornio per la creazione delle turbine di centrali elettriche, e un altrettanto impressionante girante di turbina ( che era larga una decina di metri di diametro... )che doveva essere fissata all’albero centrale.
Tutt’intorno camici blu, gente con la faccia scavata dagli anni di lavoro che si incrociava con camici bianchi e scarpini di protezione che fortunatamente Flavio mi risparmiò. Poi il solito gruppo di giapponesi e di americani; quest’ultimi non sono curiosi come i primi, ma si danno un bel daffare ( senza contare che si riconoscono davvero da come si vestono..).

Ritorniamo sul macchinario.

Accendemmo la macchina come pure il mio portatile ( ovviamente mantenendo la debita distanza... ).

La parte di potenza sottostante non serviva attivarla: l’importante era che i riscaldatori iniziassero il lavoro. Ci voleva circa un giorno per scaldare le 4 tonnellate di Neodimio, ma fortunatamente il magnete era già caldo, e dopo circa un ora, arrivò intorno al setpoint.
Attivai il registratore a carta collegandolo alle porte che replicavano le uscite dei ponti. Con la porta usb mi collegai alla scheda e lessi gli istantanei della temperatura e le uscite di potenza. Osservai il pilotaggio del PID e notai che tutto procedeva regolarmente; il leggero overshot preliminare e poi le oscillazioni che lentamente si smorzano sino a raggiungere il setpoint. Cercai di interferire nel sistema sollecitandolo; così staccai una ntc alla volta, prima sul connettore e riverificai tutti gli stati di allarme.
Il PID saturò ma poi dopo qualche minuto si riprese; un nuovo overshot e poi di nuovo la stabilizzazione. Mi riavvicinai alla macchina nuda dove erano posizionati i termistori e li mossi uno alla volta, lentamente, destabilizzando ancora il sistema e così via.
Una giornata di prove.

Flavio alla fine si avvicinò chiedendomi cosa ne pensavo. Capiva che potevo fare ben poco fintanto che la macchina non rientrava in quello stato di oscillazione anomala. Risposi che al momento avevo pochi appigli e che il loop di controllo aveva reagito correttamente in tutte le situazioni e in modo ripetibile. Mi chiese se l’indomani sarei tornato. Dissi che ci avrei pensato su, se mi venivano in mente altre prove gli avrei fatto sapere. Tornai a casa rimuginando cose del tipo: gli overflow sullo stack e altri incubi quali i registri di contesto degli interrupt e via dicendo, ma prima però dovevo rivedere il mio sistema, forse stavo ancora dimenticando qualcosa.

Il difetto dell'instabilità. (IV/IV)

Chi ha giuste intuizioni in mezzo a cervelli confusi si trova
come uno che abbia un orologio che funziona in una città dove tutti i campanili hanno orologi che vanno male. Lui solo conosce l'ora esatta, ma a che gli giova? Tutti si regolano secondo gli orologi della città che indicano l'ora sbagliata, persino chi è al corrente che solo il suo orologio segna l'ora giusta. ( Arthur Schopenhauer )

Sono in ufficio da solo.
Ho il pc acceso con aperto l’editor della IAR, ma non ricordo quale modulo del progetto era aperto; ma non stavo guardando il monitor bensì quel foglio anzi “il foglio” che tengo sempre sulla scrivania.
Lo uso per scrivere note che sono il più delle volte senza senso, ma spesso sono disegni ghirigori vari.
Ripensavo alla seconda trasferta che feci. Flavio, dopo qualche ulteriore prova, mi chiamò, e per la prima volta da quando lo conoscevo, era piuttosto agitato. La macchina era entrata nello stato caotico.
Devo ammettere che mai come in quel momento, pensai di avere qualche chance in più. Ma il peggio doveva avvenire, quando mi accorsi cosa causava quel disastro nel PID.
Inserii l’interfaccia USB, scaricai la configurazione dei parametri PID e non potei fare altro che riconoscere che erano stati aggiornati con valori assurdi.

Se per un verso il PID era scagionato, per l’altro adesso la rogna l’avevo sul resto del codice. Adesso ero sicuro che non era un problema hardware (e bisogna dire anche fortunatamente).

E’ sempre stato un mio difetto quello di pensare troppo; forse ero spaventato da quella pubblicità del collaudatore di materassi che (beato lui) proprio tutto doveva fare, tranne che pensare.

Si è vero, forse il mio grosso difetto era che dovevo imparare a pensare di meno e riflettere di più.
Tutto il core del firmware era collaudato ed era già stato messo in produzione, molte delle macchine stavano lavorando da mesi.

Così iniziai a considerare l’unica cosa che avevo aggiunto nel codice e che era appunto il driver seriale USB.
Aprii il modulo solo per perdere un po’ di tempo. Non aveva senso vedere come pilotavo quella interfaccia, però ricordo di aver fatto qualche ricerca sul protocollo usb. Non mi sarebbe servito a niente, perchè in quel momento avrei potuto fare delle ricerche sui pomodori in serra siberiani talmente ero lontano dalla soluzione, il vero scopo era che sentivo di dover mantenere operativo il cervello. E così, da vero temerario, spostai la sonda dell’oscilloscopio sull’interfaccia lato USB. Notai che staccando e riattaccando il connettore USB, l’oscilloscopio si triggerava e compariva sul display un piccolo burst di dati inesplicabile. E rimase inesplicabile, perchè non volevo certo capire come l’interfaccia comunicava al suo interno.

Però subito notai qualcosa che non avevo notato prima.
Appena staccai il connettore dalla scheda, la parte seriale entrò in uno stato caotico.

Uno tsunami di byte arrivò sull’interfaccia e attraverso una opportuna replica dei caratteri sulla seriale ausiliaria, notai subito il disastro.

I byte sembravano venuti fuori da un generatore di caratteri casuali, una sequenza lunghissima e interminabile.
Ora considerate che il protocollo ASCII che avevo implementato prevedeva due byte di header iniziale, un byte per il comando, poi un numero variabile di parametri o dati successivi ed infine la checksum che avevo però soppresso. Così ad esempio un comando tipo aveva questa sequenza di caratteri.

05 64 03 01 03

Ma proprio in quel momento capii cosa stava accadendo.
Quello che ho appena descritto era appunto il comando seriale per l’aggiornamento del parametro integrativo del PID.

L'interfaccia usb ha tutto un protocollo interno molto articolato che gestisce le connessioni e le disconnessioni. La disconnessione brutale causava lo stato di instabilità che si ripercuoteva sulla linea seriale che arrivava al micro. La sequenza di caratteri casuale che il micro riceveva dalla linea impazzita ad un certo punto replicava il comando di aggiornamento del PID.

Appena il micro riconosceva la sequenza 05 64 03 i dati successivi avrebbero sovrascritto inevitabilmente la costante del termine integrativo con il devastante effetto di rendere il PID instabile.

Il protocollo delle interfacce USB prevede una procedura di connessione ma anche una di disconnessione che dovrebbero essere rispettate e che vengono implementate ad esempio nei pc sotto la voce rimozione sicura dell'hardware. Ripristinai la checksum rafforzando il protocollo per rendere estremamente improbabile che la sequenza casuale crei un comando completo( ma ero anche consapevole che la sfiga fa questo ... ed altro ) Così feci la telefonata.

“Ciao Flavio, ti spedisco il prossimo lotto di cinque schede con il firmware aggiornato. Queste dovrebbero andare molto meglio. Spediscimi poi tutte quante le macchine che hai in azienda perché devo aggiornarci il firmware..... Ecco sì, ti chiedo una cortesia da avere con questa macchina ma che in generale vale per tutte le interfacce USB pennine comprese: prima di staccarle bisognerebbe rimuoverle dal sistema operativo. Devi “sempre” andare nell’icona che compare in basso a destra rimozione sicura dell’hardware, cliccare sul pulsante sinistro, e selezionare l’interfaccia usb della periferica che vuoi staccare. Poi dopo e solo dopo, stacchi il connettore.”

...

“ … Perchè ? Credimi è meglio così... ci sentiamo poi ti spiego.”

La ventola impazzita. (I/II)

Per riacquistare la giovinezza basta solo ripeterne le follie. ( Oscar Wilde )

La scheda era abbastanza semplice.

Monoprocessore, Microchip, PIC 16C65 con risuonatore ceramico, montato su una delle due schede pcb monofaccia ( costano poco... ). Il software doveva prevedere un driver per un motore passo passo ( per il deflettore), uno per il controllo velocità di una ventola con triac a taglio di fase, una interfaccia seriale IR di comunicazione con un telecomando, la lettura di una tachimetrica prevista con frequenze sino a 3/4 kHz, la lettura di un paio di sonde ntc e infine il consueto zero cross della rete. Visto che c'eravamo abbiamo pensato bene di implementare anche un piccolo sistema operativo per gestire meglio tutti i driver, considerandoli come delle task separate e una ulteriore interfaccia seriale di diagnostica.
Tutto il progetto era rigorosamente sviluppato direttamente in assembly perché questo tipo di microcontrollore ha caratteristiche poco digeribili per un compilatore C. Considerate anche che stiamo parlando di un vecchio 16C65 e che a quel tempo era un ricco microcontrollore con 4K di ROM e ben 192 byte di RAM tutte impaginate, come potete ben capire ogni byte risparmiato era un successo progettuale...

Abbiamo terminato il prototipo alla fine dell'inverno e prodotto la prima preserie.

Numerosi i test funzionali e le verifiche hardware implementate. La commessa doveva garantire produzioni da 10000 pz l’anno (uno scherzo in confronto alle produzioni richieste dai lavatriciari ). Questo prodotto, era uno delle decine di progetti sviluppati in una prolifica azienda nel settore dell’elettrodomestico in generale. Entrando nel particolare, questa scheda era prevista per il controllo di un condizionatore, completamente progettato e sviluppato in Italia. Una vera scommessa industriale a quel tempo.

Il progetto prevedeva lo sviluppo anche del telecomando basato su un micretto sempre della Microchip, dove implementava una interfaccia ad un lcd senza utilizzare driver integrati, utilizzando “semplicemente” i pin del micro per il pilotaggio dei segmenti.
Ancora una volta la preserie venne sviluppata senza problemi rilevanti e i primi condizionatori furono prodotti e installati nella sede del cliente e anche nella nostra per effettuare i test funzionali d’uso.
Ovviamente pensarono bene di installare split esterno e condizionatore nella stessa stanza ( per non perdere troppo tempo ). Così producevamo migliaia di condizionatori l’anno ma eravamo privi di aria condizionata come il calzolaio che va in giro con le scarpe rotte...

L'azienda cliente, raggiunta la primavera, incominciò a segnalare vari problemucci tutti di secondaria importanza, fra i tanti sostenevano che la ventola saltuariamente diventasse rumorosa all'improvviso.

Chiedemmo, per scrupolo, maggiori informazioni ( perché siamo sempre preoccupati quando un cliente ci segnala anomalie difficili da spiegare....), ma non avevamo mai trovato problematiche che potessero essere riconducibili ai difetti da loro rilevati.

La segnalazione si ripetè con frequenza crescente e il problema non rimase più un generico rumore della ventola, ma qualcosa di più preoccupante.
Il controllo della ventola era effettuato da un pseudo PID integrativo con setpoint di velocità e le indicazioni che i clienti ci davano denunciavano un serio problema ovviamente non ripetibile. Tutta questa situazione indeterminata, si svelò un giorno quando nel condizionatore installato proprio davanti alla mia postazione, la ventola incominciò ad aumentare e a diminuire di velocità spontaneamente così come ci diceva il cliente.

Era come se la scheda perdesse il controllo del setpoint, facendo rallentare o accelerare la velocità della ventola e giustificando così i problemi denunciati sin dall’inizio dal cliente, che erano appunto la rumorosità anomala. Se si provava a spegnere e riaccendere la macchina il problema spariva per poi ricomparire dopo un po' di tempo.

Driver, task, interrupt, overlay di memoria .... ma sopratutto perché le nostre macchine di test non l'avevano mai fatto?

26/06/95 14.59 Creata nuova task per gestire il buzzer. Visto che sia il buzzer che la task per la lettura delle sonde di temperatura utilizzano la stessa risorsa ( Timer1 ), attraverso il sistema operativo abbiamo fatto in modo da impedire che si ostacolino a vicenda. Il buzzer viene attivato con due consensi uno é l'evento rilevato dalla fine della ricezione telecomando e l'altro dalla attesa lunga fatta fra una lettura di ntc completa e l'altra. Sono state create due costanti ulteriori con l'indirizzo completo dell'evento ( NTC_EXE, TLC_EXE )

La ventola impazzita. (II/II)

"Ragazzi.. non è avendo un plettro satanico che farete un rock migliore. Perchè Satana non è in un plettro per chitarra è dentro tutti noi! E' qui dentro, nei vostri cuori. E' quello che non ci fa avere voglia di lavorare, fare ginnastica o dire la verità. E' quello che ci fa venire voglia di fare festa e fare sesso l'un l'altro tutta la notte.. è quella vocina nella mente che dice vaffanculo alle persone che odiate!" ( Tenacius D e il destino del rock )

Questa storia è stata molto importante nel mio percorso lavorativo.

Proprio in quel periodo iniziai a capire che l’approccio avuto sino a quel momento verso la risoluzione dei problemi non era quello giusto. Ritenevo che i sistemi embedded fossero una sorta di complessi layer sovrapposti che partivano dall’hardware per arrivare alle astrazioni a stati grafici come quelli proposti dalla IAR con il VisualSTATE. Pensavo che ognuno di questi layer necessitasse di competenze particolareggiate da affrontare con application note e studi specifici. Tentavo così infatti di racchiudere tutto il mio lavoro all’interno di quelle pagine di editor della Norton, spendendo molto tempo nello sviluppo di multipli livelli logici che mi potessero svincolare da tutto il resto, non solo dall’hardware, creando appunto moduli driver il più efficienti possibili ma anche dalle tipiche estenuanti richieste del cliente.

In questo caso tentai di superare queste difficoltà creando una struttura modulare a stati all’interno del firmware. Questa struttura si poteva visualizzare con un diagramma grafico, a stati, appunto fatto con tante palle che venivano unite da frecce condizionali. La visualizzazione grafica risultò particolarmente utile perchè questo permetteva al cliente di effettuare tutte le modifiche, semplicemente disegnando sul grafico quello che desiderava ottenere ma senza che il mio firmware diventasse una poltiglia informe di delirio logico.

L’elevata complessità di un sistema embedded non è un pregio anzi molte volte risulta il difetto principale e spesso ricordo il mio vecchio assistente di elettronica che per arrotondare aggiustava televisioni. Un giorno mi diede una dritta appunto per ripararli, che ricordo ancora adesso. Diceva che la metà dei guasti rilevati si risolvevano con un deciso colpo di manico del cacciavite assestato al centro della scheda...

Quella mattina anonima, come sempre, in quel piccolo paesino dove abitavo, che ancora ricordo con affetto, i contadini, gli idraulici, i piccoli immobilieri e tanta genuina spontaneità. Percorrevo con il pilota automatico quei pochi chilometri che mi dividevano dall’azienda dove lavoravo.

In genere noi del laboratorio eravamo abbastanza sincronizzati. Ci incontravamo nell’ampio parcheggio, sempre pieno e sempre di corsa per cercare di evitare la timbratura rossa che sarebbe costata un quarto d’ora di penalità ed anche il pericolo di un richiamo scritto.

Era una giornata molto calda di luglio e salii trafelato in laboratorio salutando tutti come di consueto, Alfio compreso. Alfio era il responsabile della produzione, un nuovo “acquisto” necessario per risolvere i problemi che avevamo con la qualità delle produzioni e con la gestione delle nuove certificazioni ISO, diventate sempre più importanti per le commesse acquisite o ancora da acquisire. Contrariamente al sottoscritto era un ingegnere, classico, silenzioso e burbero.

Ovviamente la produzione era alle porte e così partecipò all’interno dei veloci meeting che facevamo per risolvere i problemi, meglio dire per risolvere il problema della ventola pazza.

Da una parte io lavoravo in solitaria sul prototipo per verificare tutte le funzionalità critiche del firmware ed eventualmente per consolidare tutte le parti deboli, dall’altra c’erano sul condizionatore installato tutti gli altri del laboratorio che un po’ alla volta modificavano qualcosa cercando di capire dove stava l’inghippo.
Le verifiche diventavano frequenti e i brain storming sempre più pressanti, anche il grande capo cominciava a chiamare.

La scheda aveva ripetuto il problema pochi giorni prima e ricordo che, come ipnotizzati, rimanemmo immobili sentendo la ventola aumentare e diminuire di velocità.

Erano circa le quattro del pomeriggio, il momento più caldo della giornata; il condizionatore era acceso dalla mattina e costantemente monitorato. Dalla seriale ausiliaria ricevevo i dati più sensibili del sistema come le temperature lette, le velocità impostate e così via.

Ovviamente io ero ostinatamente all’interno del mio firmware layer assorbito completamente dalla gestione degli interrupt interni, dalle task e dal pilotaggio del triac.

Ricordo che fu come un lampo quando la ventola prese di nuovo quel suo andamento altalenante.

- Se invece fosse l'hardware il problema ? Se fosse l’opto triac utilizzato? Magari surriscaldandosi troppo si poteva attivare spontaneamente.

Se questo era vero come verificarlo? Il mio driver seriale non sarebbe mai riuscito a monitorare una cosa di questo tipo. Avrei dovuto visualizzare lo stato del pilotaggio e contemporaneamente monitorare la fase della 220 sul triac.

E poi ? Anche se mettevo su un banco di test in grado di farlo a cosa sarebbe servito?

No l'ipotesi era l' eccessivo calore e quella dovevamo verificare.-

Qualche tempo prima comprarono una bomboletta di aria compressa che era in laboratorio, così Alfio la prese e velocissimo raggiunse il condizionatore. Prese poi uno sgabello per arrivare meglio alle schede installate all’interno di una scatola in plastica e puntò il beccuccio della bomboletta diritto sull’opto-triac.
Tutti in quel momento capimmo cosa voleva fare. La pressione della bomboletta, creando aria gelida, avrebbe abbassato la temperatura del componente, se l'ipotesi del calore eccessivo era giusta in questo modo potevamo davvero scoprirlo.

Prima lo sbuffo e poi l' interminabile attesa fatta in realtà di pochi, estenuanti secondi, con noi tutti tesi e in ascolto per capire cosa sarebbe successo.
Arrivò poi l’urlo di gioia e fu commovente, era come se fossimo a vedere una finale di champions e così sentimmo la ventola riprendere il suo andamento regolare, silenzioso e preciso, con un errore sulla tachimetrica al di sotto dell’un per cento come da specifica.
Un po’ di chiacchiere qualche insulto scherzoso e poi ben presto si fecero le cinque e mezza così ci salutammo con il sorriso consapevoli che domani sarebbe stata invece una noiosa giornata.

Ma da li seguirono ancora due settimane frenetiche perchè subito con un paio di prove incrociate scoprimmo velocemente che avevamo in sede optotriac che invece non avevano quel problema.

Con una serie di test incrociati e verificando l'innesco del triac abbiamo circoscritto il problema all'interno di quel lotto di optotriac utilizzato per la produzione di quelle schede. In pratica non veniva rispettato il parametro di dV/dt in commutazione così come si dichiarava su datasheet. Dopo aver tampinato il FAE abbiamo scoperto che l'anno precedente la Freescale ( ex Motorola ) aveva ceduto le maschere a QT e la nuova fabbrica non aveva ancora il processo ben sotto controllo.

Il problema era che l'equivalente optotriac della Freesacle se sostituito funzionava correttamente. QT, nonostante l'evidenza negò ogni addebito ( per il danno alla produzione avuto ) ma bontà loro ci sostituì comunque gratis il lotto ( di circa diecimila pz.).

Lo strappo. (I/III)

Le domande di un folle sono più numerose delle risposte di 1000 savi ( anonimo )

I sistemi di controllo PID come abbiamo già detto sono utilizzati in prevalenza nei processi industriali dove si deve mantenere un valore fisico vicino ad un setpoint. Il tipo di controllo dove il pid viene utilizzato maggiormente è quello di temperatura. Questo tipo di sistema per un controllo PID è però fra i più “semplici” ( le virgolette sono d’obbligo) da implementare. Questa facilità è dovuta sostanzialmente dal fatto che le derivate di un controllo in temperatura sono poco ripide e in genere in questi casi il parametro derivativo risulta quindi inutile, rendendo possibile la sua omissione e facendo diventare questi controlli da complessi PID a “semplici” PI.

Uno dei primi progetti firmware che ho sviluppato è stato il più difficile mai affrontato. In questo caso il modulo doveva controllare in velocità un motore asincrono monofase. Che detta così sembra dagli elevati contenuti ingegneristico, ma per molto tempo fra gli amici ero quello che faceva girare i cestelli delle lavatrici....

La complessità di questo controllo era dovuta dal fatto che il motore asincrono ha risposte molto più veloci rispetto a quelle di , ad esempio, una camera termica. Questo rende necessario, meglio dire indispensabile, l’implementazione del terzo parametro derivativo. Questo parametro però tipicamente crea notevoli difficoltà nella fase di tuning perché è fortemente condizionato dallo stato del sistema. In molti casi potrebbe essere necessario avere più set di parametri perchè questo permetterebbe di adattare la risposta a seconda dello stato attivo o disattivo. Tento di spiegarmi meglio entrando in un campo che è più vicino ai fisici che ai sistemisti come me.... Nel caso appunto di un motore asincrono la derivata dell’accelerazione è molto diversa rispetto a quella della decelerazione. Questo è dovuto da diversi fattori che includono l’inerzia del motore stesso, ma non solo. Questa differenza nel sistema è una dissimmetria ed è difficile da modelizzare analiticamente dal controllo, così i parametri del PID dovranno “sopportare” anche questo tipo di situazione.

Le dissimmetrie sono molto fastidiose da vedere, sono poco estetiche, fanno sbuffare nella loro inevitabilità. Troppo spesso passiamo il tempo a cercar di far quadrare il cerchio e magari alla fine ci illudiamo pure di esserci riusciti.

Anche i controlli di temperatura hanno questa dissimmetria ma come abbiamo detto poc'anzi le derivate sono molto più lievi e le risposte del sistema molto più lente e questo agevola non poco il controllo di processo. Ma ritorniamo al nostro motore asincrono perché le sorprese non finiscono. I motori di questo tipo hanno una velocità operativa superiore ai 10000 rpm ( rpm = rotate per minute ). Il mio attuatore era un triac e la regolazione anzichè assere di tipo burst firing era a taglio di fase, o per gli anglofoni phase fired, questo ci obbligava a lavorare all’interno della semionda di rete. Nel nostro paese la frequenza della rete è di 50Hz e così in 10 msec dovevo riuscire a stabilizzare in velocità il nostro motore. Parlare di 10 msec è umanamente un tempo piccolo ( un battito di ciglia sono circa 100 msec... ) ma non per un microcontrollore che può arrivare a qualche nanosecondo per istruzione.

Ogni controllo ha il suo feedback che nel nostro caso era un segnale di tachimetrica che andava dalle poche decine di hertz a qualche decina di kilohertz, anche in questo caso uno scherzo per un tipico ingresso contatore di un micro moderno.

Ma.... e c’è sempre un ma nelle cose che rende la vita così infausta e caotica, tanto da renderla difficile, ostile, però mai noiosa. Dicevamo... In questo momento non parliamo di un micro moderno ma di un micro vecchio (!) di venti anni fa. Gli anni sono sempre stati visti come ere geologiche nel campo dello sviluppo elettronico. Mi chiedevo quindi cosa era davvero accaduto in questi venti anni? Tutto e niente, i microcontrollori di venti anni fa erano più farraginosi i datasheet erano più complicati e le prestazioni alla fine, dico quelle del core, non sono migliorate di molto. Sorrido sempre quando guardo sistemi embedded con Java che vengono utilizzati per accendere dei led...

Quel micro era il nuovissimo microcontrollore della Microchip ed era il PIC16C57. La scrivania era sgombra e sopra avevo due fogli fotocopiati con il pinout del micro. Sergio, il direttore tecnico non ufficiale, mi aveva dato qualche sommaria indicazione per quel progetto parallelo che da li a poco mi avrebbe occupato per i prossimi sei mesi. Non era necessario che si dilungasse troppo in descrizioni tecniche anche perché sebbene fossi un novizio, avevo già precoci e concrete esperienze. Ricordo mi accorsi subito di una caratteristica spiacevole di quel micro leggendo velocemente i fogli fotocopiati. A differenza di quelli che avevo utilizzato fino a quel momento, tipo l’8051 – della INTEL - o il 68HC11 – della ex Motorola - o anche lo z80 – della Zilog e del mitico Faggin- , non aveva interrupt. Ebbene si non aveva e non ha interrupt.

Decidere di mettere un microcontrollore su una scheda lavatrice era una cosa innovativa perché esistevano già integrati che facevano questo autonomamente e molto bene. Sino a quel momento questo tipo di mercato era particolarmente statico e retrogrado. In Italia l'innovazione era solo quella di riuscire a diminuire i costi dell'elettrodomestico. Con l'avvento dei microcontrollori si poteva però incominciare a pensare a qualcosa di meglio e la funzionalità inventata per giustificare il loro utilizzo nel campo del controllo motore era quella chiamata di antisbilanciamento. Questa funzione consisteva nel modulare la velocità di centrifuga a seconda del carico sbilanciato del cestello.

Spieghiamo un pochino meglio. Prima di avviare la centrifuga il modulo doveva fare delle verifiche sul carico calcolando i chili di sbilanciamento. Se questi erano troppi la prova veniva ripetuta per un massimo di tre volte. Alla fine si avviava la velocità di centrifuga più alta possibile. Questa funzione avrebbe evitato le famose passeggiate dell'elettrodomestico nei bagni dei consumatori e anche in qualche caso i danni che l'alta velocità della centrifuga causava sui suppellettili e anche ai sanitari.

Ora però in verità la nostra storia è molto lontana nel tempo rispetto ai tempi dove si ingegnerizzava la scheda e creando il prodotto finito, questa premesse però ci torneranno utili per capire il resto della storia. Il modulo era terminato e funzionante e la ditta a cui stavamo tentando di vendere il controllo motore era la San Giorgio, una storica azienda produttrice di lavatrici. Un giorno i moduli che avevamo già prodotto e che erano in continuo test non superarono una prova.

Il tecnico di laboratorio montò un nuovo set di cinghie sulla lavatrice e queste crearono un fastidioso difetto. Le cinghie servono per collegare l’albero del motore alla ruota del cestello con un rapporto di riduzione di circa 1:10. Con la pressante globalizzazione che li avrebbe da li a poco ingoiati, trovarono un nuovo economico fornitore e così ne comprarono uno stock in prova.

L’esperto tecnico quel giorno chiamò contestando al nostro modulo un fastidioso rumorino, dovuto al leggero slittamento della nuova cinghia sull'albero motore asincrono. Ovviamente questo accadeva nell'elettrodomestico dove lavorava il nostro modulo e non in quello della scheda concorrente, prodotta da quelli della Procond. Imprecare su quelle cinghie era inutile, il nostro modulo diventava istantaneamente non accettabile per la futura produzione e prendendo spunto dal celebre esempio di logica simmetrica resa nota dalla Martini e da Clooney sapevamo bene che ... no produzione no stipendio...

Lo strappo. (II/III)

Cara Roberta Sparrow, ho letto a fondo il suo libro e ci sono molte cose che vorrei chiederle. A volte ho paura di quello che lei potrebbe dirmi. E a volte ho paura che lei mi dica che non è tutto frutto della fantasia. Posso solo sperare che la risposta mi arrivi nel sonno. E spero anche, quando il mondo finirà, di poter tirare un sospiro di sollievo, perché ci sarà tanto da contemplare avidamente.

[Lettera di Donnie Darko a Roberta Sparrow]

Cosa significa lavorare con un micro senza interrupt? Se devo essere sincero all’inizio ero pure contento perché gli interrput, le interruzioni, sono l’elemento di disturbo nel flusso del programma.

Il firmware lo vedevo ancora come se fosse un programma basic monolitico e gli interrupt erano la fastidiosa eccezione. Ma il pic aveva altre sgradite sorprese che lo distinguevano dagli altri micro. La struttura interna è di tipo Harvard modificato e a differenza della architettura Von Neumann questo micro ha i bus della memoria dati e quello della memoria programma separati.

Questa differenza ha permesso, alla Microchip, di ridimensionare la memoria programma differenziandola da quella dati. Così la struttura dati della memoria programma fu portata a 12 bit. Cosa significava questo?

In primo luogo che diminuirono drasticamente gli opcode assembly tipicamente molto numerosi nei micro concorrenti e riuscendo con un singola , ma efficientissima, istruzione ad effettuare tutte le funzioni base del micro.( intendendo quindi le operazioni di spostamento fra registri, le operazioni logiche i test dei bit e così via... ). In questo modo riuscirono a creare una tabella di opcode di solo 33 istruzioni mentre, che ne so, lo Z80 ne aveva più di 150 . In secondo luogo i 2 kb di programma del pic corrispondevano in realtà a più di 3 k di memoria degli altri micro. Quando la Microchip incominciò a pubblicare le analisi sull’efficienza di sviluppo del codice firmware, fece non poco girare les pelotas ( scusate per lo spagnolo... ) agli altri concorrenti ( l’Atmel su tutti ), che a ruota risposero con altre application note sui parametri che si dovevano considerare per ritenere il codice davvero efficiente, nel tentativo di dimostrare che il loro micro era il migliore in commercio. Sembrava di assistere alle pubblicità americane della pepsi e della coca cola...

La doppia pipeline del PIC permetteva di eseguire un'istruzione ad ogni ciclo macchina per tutte e trentatré (33) istruzioni. L’unica eccezione l’avevano i salti condizionati che necessitavano di un ulteriore ciclo macchina per eseguire il salto. Una caratteristica interessante che sembrava una stranezza, ma che poi verificai direttamente con questo progetto, la includo così come l’hanno pubblicata nel datasheet del micro.

“The PIC16C5X has a highly orthogonal(symmetrical) instruction set that makes it possible to
carry out any operation on any register using any
addressing mode. This symmetrical nature and lack of
‘special optimal situations’ make programming with the
PIC16C5X simple yet efficient. In addition, the learning
curve is reduced significantly.”

Si, la curva di apprendimento si riduceva ,vero … ma non gli improperi e le pastiglie di Malox che invece aumentarono esponenzialmente.

Uno dei problemi più rilevanti, era la struttura a pagine sia della memoria dati che della memoria programma.
Quelle maledette pagine rendevano difficoltosa ogni modifica sul codice e tutte le revisioni diventavano una vera tortura.

Una volta consolidato il firmware, rimanevano da mettere a posto solo gli aspetti secondari e la curva dei bachi diminuisce fino a che non si azzera. Si azzera, ma non del tutto, perchè quelle maledette cinghie slittavano, ed era maledettamente vero quello che l’infingardo tecnico rilevò.

Predisposi due lavatrici in modo da vedere il cestello girare, una con la cinghia nuova e una con la cinghia vecchia.
Non potei fare altro che confermare quanto denunciato, almeno una volta su 5 partenze, si sentiva quell’inesorabile suono sibilante della cinghia (nuova) che slittava sull’albero motore, con tanto di evidente vibrazione visiva...

A questo punto il controllo PID entrò direttamente fra gli imputati, così come tutta la parte di controllo del triac, ma quando accadono questi eventi non ripetibili, le cose sono molto più complicate di quello che sembrano, e coinvolgono tutto il sistema embedded.
L’oscilloscopio è stato sempre di valido supporto nelle ricerche di bug e di test dei segnali.

Per questo tipo di scheda era, diciamo, un po’ problematico il suo utilizzo, perché questa elettronica sviluppata nel settore consumer non ha sezioni di alimentazione con trasformatore, quindi non essendo separata galvanicamente, lavora direttamente sulla 230 volt. ( si … ma non ditelo a quelli della ASL... ). Per poter lavorare con un oscilloscopio sulla scheda, abbiamo cosi disaccoppiato l’oscilloscopio con un trasformatore 220/220, e questo mi avrebbe permesso di fare le misure necessarie in tutta sicurezza sulla scheda.... ( ovviamente la sicurezza era solo per l’oscilloscopio e non per il sottoscritto.... ).

Lo strappo avveniva proprio alla partenza del motore, che è un momento delicato per l’attivazione.
In questa fase il PID viene inibito e l’attivazione del motore deve essere fatta accellerando con una certa pendenza.
Se questa accelerazione è troppo lenta o troppo veloce, il PID si attiva in momenti anomali pregiudicando il loop di stabilizzazione. Anche riuscendo a controllare la derivata dell'accelerazione, il controllo ha delle difficoltà intrinseche perchè la tachimetrica in questa fase è molto instabile.

Il segnale per la bassa velocità ha una ampiezza molto piccola che è vicina alle soglie del pin di ingresso del micro, e così spesso si rilevano fronti spurie che non esistono. Questo rende particolarmente difficile per il processore riconoscere il momento per passare dalla rampa manuale al controllo con il PID. ( e si … è dura la vita... )

Con una sonda mi misi sul triac cercando di visualizzare lo strappo, mentre l’altra la misi in uscita dall’operazionale per visualizzare invece lo stato della tachimetrica.
La cosa era preoccupante perchè l’attivazione del triac era molto lineare e la derivata dell’accelerazione era perfettamente controllata. Provai a modificarne la pendenza, ma non c’era verso; la cinghia continuava a strappare con la stessa frequenza.
In realtà quello che ritenevo sistematico era molto variabile e la frequenza presunta non era uno su cinque come credevo.. ma variava.

Provai a implementare qualche strano algoritmo con innesco a scalino ma niente da fare un altro giorno era passato e la soluzione la vedevo lontana...
molto lontana...

Lo strappo. (III/III)

"Embedded in the mud, glistening green and gold and black, was a butterfly, very beautiful and very dead. “Not a little thing like that! Not a butterfly!” cried Eckels. "

A Sound of Thunder by Ray Bradbury

Le temporizzazioni interne per un controllo motore sono vitali, di solito avvengono attraverso gli efficaci interrupt sul timer, ma visto che ne ero sprovvisto implementai un uKernel per gestire delle pseudo task cooperative ( che a me piace dire di tipo Round Robin). Questo tipo di ausilio mi ha permesso di avere delle sezioni di codice che venivano richiamate con tempi predefiniti e che per esempio mi permettevano di gestire la macchina a stati per eseguire le rampe di velocità e nello stesso tempo di tenere sotto controllo il segnale di tachimetrica che doveva essere letta in polling dal core del uKernel.

Sulla tachimetrica poi c’era un altro problema legato all’ampio range di misura. In questi motori il segnale proviene da tre magneti calettati sull’albero motore che creano a loro volta 3 periodi di tachimetrica ad ogni giro. A frequenze molto basse la lettura viene fatta a periodimetro ( misura del tempo fra i fronti ) ma con l’aumentare della frequenza la risoluzione del mio timer diminuisce e quindi bisogna switchare on fly ( mamma mia che termini... ) la lettura in modalità frequenzimetro ( apertura di una finestra a tempo e conteggio dei fronti ). Questa operazione, molto delicata, deve essere fatta cercando di mantenere una certa linearità sulla risoluzione per non avere altri effetti infausti nel controllo PID.

La modalità di innesco a taglio di fase consiste nell’attivare il gate ( magari con una tripletta di zippilli ) del triac, nel tempo stabilito dal nostro PID ( o dalla nostra rampa iniziale ), all’ interno della nostra semionda di rete. Il disinnesco del triac avviene al prossimo cross sullo zero della corrente. La fase della corrente, rispetto a quella della tensione, ovviamente è sfasata di qualche grado per la grossa induttanza del motore stesso e così si doveva fare un po’ di attenzione al prossimo innesco... Questo era un elemento importante di non linearità nel controllo, ma c’era anche un altro fattore di non linearità, che era dovuto appunto al momento di innesco del triac, considerando la variazione non uniforme di tensione fra un innesco e l’altro nelle varie parti della semionda.
Guardavo la serie di moduli che assemblati insieme avrebbero creato il mio programma, non erano molti, una decina in tutto. Sarebbero stati almeno la metà se non li avessi infarciti con tante dichiarazioni, definizioni, rimandi. Per non parlare poi dello spazio preso dai commenti sempre molto generosi ( e un po' prolissi... ). In una directory a parte qualche file mathcad con dentro un po' di analisi sulla tachimetrica sugli errori, un documentino sul filtro di Kalman e i suoi miracoli. I datasheet non erano molti, il micro, l’operazionale usato sulla tachimetrica, qualche fotocopia di una rivista americana illegibile sui motori e le loro caratteristiche elettriche e meccaniche. In un file di history dove descrivevo tutto quello che facevo e che era un po’ il diario giornaliero delle mie esperienze. Come editor utilizzavo quello della Norton perchè era l’unico che aveva la ricerca di stringhe su gruppi di file.

Ora con l’oscilloscopio leggere l’attivazione del triac era problematico, si riusciva a vedere qualcosa se mi triggeravo sulla tachimetrica, ma questa diventava leggibile solo dopo un bel po’ di periodi di rete. Fortunatamente però era uno dei primi oscilloscopi digitali e così dal trigger potevo tornare indietro e vedere la mia rampa. Con questo tipo di oscilloscopi si doveva fare attenzione all’Aliasing ma il problema nasceva solo se avevamo segnali di frequenza molto alta...
Utile per capire l'Aliasing era il teorema di Shannon. Gli inneschi erano graduali lineari perfetti e tutto questo accadeva mentre la tachimetrica prendeva forma. Niente spike né disturbi di nessun altro genere, il problema poteva capitare all’inizio della accensione o dopo decine di cicli di rete o dopo svariati minuti... ma ( e c'è sempre un ma.... ) prima o poi capitava inevitabilmente. Così passai quella mattinata osservando la ruota del cestello che faceva avanti e indietro alzando ed abbassando il trigger dell’oscilloscopio, aumentando e diminuendo i valori di innesco nella rampa, modificando il carico del cestello … e via andare accumulando un insieme di prove tante volte scorrelate ma che insieme potevano aiutarmi.

In uno di quei giorni perduto fra i miei test, per errore, misi tutto il sistema sotto gruppo di continuità, dopo un po' fusi tutto. La puzza e la presa per il culo dei colleghi giustamente, ci volle un po’ a passare...
Ogni tanto mi alzavo, ( Alfio aveva da poco installato la rete aziendale) per raggiungere un pc nella scrivania a fianco, dove stavo provando una delle distribuzioni Linux, ricordo che dovevo cercare il manuale del monitor, per sapere il valore delle frequenze di sincronismo verticale e orizzontale... adeguatamente avvertito che se per caso sbagliavo l’impostazione il monitor si sarebbe danneggiato irreparabilmente... (... altri tempi )

E intanto il motore girava, prima a sinistra, poi a destra e poi quel fastidioso strappo. Guardavo l’oscilloscopio e poi lo strappo.

Presi la traccia dei zippilli sul triac e la sovrapposi alla traccia di innesco del triac.

Il taglio di fase era evidente, dopo lo zippillo si vedeva la fase innescata. Tornai per l’ennesima volta indietro sino all’inizio, quando proprio in quel momeno mi accorsi di un elemento anomalo.

Tutta la rampa era perfetta tranne che per un elemento. Il primo zippillo di innesco del triac era troppo vicino dall’inizio della semionda di rete; e in quella condizione quella piccola parte di fase da 10 ms avrebbe alimentato il motore. Poteva questa essere la causa dello strappo? Poteva un'unica semionda dare abbastanza energia al motore per riuscire a strappare la tensione di quella cinghia? Un furioso brain storming si attivò perchè nella mia mente stavo trasformando quell’unico indizio in una prova. In quel momento l’analisi sul firmware si concentrò sulla variabile di innesco e da li a poco mi accorsi del baco. Quella variabile, nella fase di rampa controllata, non veniva inizializzata. Verificai che all’accensione del micro veniva correttamente inizializzata, ma le volte successive manteneva l’ultimo valore di innesco del triac. ( merd... scusate il francesismo ).
Così aggiunsi un paio di istruzioni per caricare il registro di ritardo del triac con un valore di default coerente.

movlw        STARTUP_TRIAC
movwf        Rit_Triac

La frequenza dello strappo era tale che potevo permettermi di verificare l’effetto della modifica per un paio di giorni e dopo che furono passati rilasciai la nuova release alla San Giorgio.

Per qualche motivo per me oscuro da lì a poco la ricca produzione per la azienda si avviò con vertiginosi lotti da cento moduli al giorno, e il mio capo cambiò la macchina passando da una thema turbo all’audi a8 ( beato lui... )

La temperatura condizionata. (I/III)

"Ho sentito dire che questa mattina un rinoceronte è fuggito lungo il missisipi in un pallone rosa. Che ne pensi ? Il computer potrebbe rispondere in modo misurato. " Mi sembra piuttosto ridicolo ". Fin qui tutto bene . ( La mente nuova dell'imperatore - Roger Penrose )

Il firmware, in particolare, ma tutti i software in generale, possono essere considerati come delle gigantesche macchine combinatorie. Molti, ritornando indietro nel tempo, ricordano quelle vecchie lezioni universitarie quando questo termine veniva utilizzato nelle lezioni di architettura dei calcolatori per identificare oscure reti logiche. Una macchina combinatoria a seconda dello stato di certi ingressi predispone le uscite seguendo percorsi di linee logiche indipendenti nel tempo. Ma questa definizione è solo in alcuni casi associabile ad un firmware, nella maggior parte dei casi nello sviluppo di sistemi embedded medio complessi non è proprio applicabile. Così, forse,sempre prendendo spunto da quella teoria dei calcolatori, i sistemi embedded e i software si possono considerare come macchine combinatorie ma di tipo sequenziale e cioè complesse reti logiche dipendenti nello stato dal Tempo. ( tipo.... la Macchina di Turing per intenderci ).

Il mondo degli elettrodomestici viene anche chiamato white goods. L'Ariete elettrodomestici aveva in progetto un nuovissimo condizionatore portatile molto interessante, che doveva spostare il core business dai piccoli ai grandi elettrodomestici. Era composto da una classica doppia unità. La parte interna aveva la forma di un portatile con un avveneristico lcd e un pannello cromato che faceva tanto Crysler anni 50. Questa unità era poi collegata ad una batteria esterna per lo scambio di calore (...detta di condensazione ).

I condizionatori portatili a quei tempi facevano fresco quanto uno sportello di un frigo aperto ma questo modello sembrava garantire prestazioni equivalenti agli split da parete convenzionali. Il circuito veniva poi alimentato con del gas refrigerante detto Freon poi qualche anno dopo messo al bando vietandone la produzione per salvaguardare il pianeta dal buco dell’ozono. Questa operazione ha scatenando un putiferio internazionale perché illustri detrattori hanno sentito puzza di pasticcio da multinazionale. Pare che l’interesse alla salute planetaria sia avvenuto proprio quando il brevetto del Freon stava scadendo.

L’NTC è un sensore di temperatura resistivo ( detto anche termistore ) così come la PTC. L’andamento delle ntc non è lineare come le termocoppie, così, a meno di brevi tratti, è necessario implementare funzioni di linearizzazione. L’andamento è di tipo esponenziale, ma implementare una funzione di questo tipo per leggere la temperatura con micretti così scarni è troppo complicato. Così spesso si opta per una efficace spezzata in cinque punti. Ora in condizioni normali una ntc inserita in una serie resistiva può essere letta da un ingresso AD del micro, oppure, se proprio sei sfortunato, lo si mette esterno (dico il convertitore AD ) ... oppure, come nel nostro caso, si fa senza, perché microcontrollori con ingressi AD, o peggio l’utilizzo di convertitori AD esterni, era vietato, costavano troppo.

Non inventammo niente, altri ci avevano pensato prima di noi e cosi, l'uovo di Colombo, per leggere la nostra NTC, con un semplice ingresso del micro, era quello di sostituire la rete resistiva con una rete RC. ( metodo ramp rate ). In questo link una più esaustiva application della Texas

Nel nostro progetto le sonde ntc dovevano essere utilizzate per misurare la temperatura dell’aria e quella delle batterie. Un sistema di condizionamento d’aria ha delle particolarità quando, oltre alla semplice funzione di raffreddamento, si vuole implementare anche la funzione pompa di calore. Questa features permette di invertire il ciclo e le funzioni delle due batterie facendo diventare il nostro modesto impianto di raffreddamento un traballante impianto di riscaldamento. Durante la stagione fredda invernale la batteria esterna dopo qualche tempo incomincia a ghiacciarsi compromettendo così la funzionalità di riscaldamento. A questo punto viene avviato un breve ciclo di raffreddamento, con la ventola interna al minimo, che viene effettuato sino a quando il ghiaccio esterno non si è sciolto completamente.
La temperatura della batteria esterna è utile proprio per capire quando avviare questi cicli di raffreddamento e riscaldamento. Il range di temperatura, come è facile intuire, era molto ampio da -20 a +60 e le risoluzioni dovevano essere vicine al decimo di grado.

Il firmware era implementato in un Pic 16c5x del tipo shrinkato, perché questa volta non avevamo abbastanza spazio nella scheda. Ricordo che abbiamo messo anche un fotodiodo per rilevare la luminosità dell’ambiente e regolare così i led di backlight dell’lcd.. ( pensa te... )

Una volta terminato il prototipo, abbiamo steso il cablaggio e collegato le varie utenze. Il condizionatore aveva una interfaccia utente piuttosto complicata. Oltre alle 4 funzioni principali tipiche di un condizionatore, avevano previsto anche quella di timer con l’accensione giornaliera temporizzata al quarto d’ora. La funzione di orologio la facemmo con il sync di rete che varia un po'... ma alla lunga ( ...molto alla lunga ) ritorna preciso.

La programmazione del micro quella volta la feci con la prima release dell'IDE sviluppato dalla Microchip. L’assemblatore del pic permetteva di progettare delle macro che mi agevolavano non poco nella stesura dei programmi.

;-------------------------------------------------------
; SETB       : Macro Set bit in selected byte
;
; Input     Address : Address register
; Output    NONE
; Ram       NONE
;-------------------------------------------------------
SETB    MACRO    Address
    bsf    (Address >> 8) & 0FFh ,Address & 0FFh
ENDM
;-------------------------------------------------------
; CLRB       : Macro Clear bit in selected byte
;
; Input     Address    : Address register
; Output    NONE
; Ram       NONE
;-------------------------------------------------------
CLRB    MACRO    Address
    bcf    (Address >> 8) & 0FFh ,Address & 0FFh
ENDM

Benissimo, eravamo pronti per i test sui prototipi. Le verifiche sull’interfaccia la selezione delle funzioni, le impostazioni del timer, l’attivazione delle utenze del compressore e della ventola. Sia su banco che sul condizionatore monster style.
Dopo una settimana demmo il via alla preserie e poi quella timida telefonata.
“Tutto bene, ho qualche dubbio sulla temperatura esterna.... poi ne parliamo”
Così mi disse e da li la sedia si trasformò in graticola....

La temperatura condizionata. (II/III)

Accetti ogni dettame... senza verificare... ti credi perspicace... ma sei soltanto un altro dei babbei e ti bei …..e ti bei. ( Sogno eretico - Caparezza )

Sviluppare un firmware o un qualsiasi progetto embedded necessita di particolari competenze e di una spiccata qualità da problem solver. Il micro mette a disposizione del programmatore una serie di opcode che permettono alcune funzionalità logiche di base. Questi opcode sono il suo linguaggio di programmazione. In realta ad essere precisi, il linguaggio di programmazione si chiama Assembly e gli opcode del microcontrollore sono ,nel particolare, il “dialetto” di programmazione del micro. Quello che in molti firmwaristi imberbi ha creato fallimentari stati di frustrazione è stato il tentativo di implementare algoritimi seguendo personali e spesso disordinati sviluppi logici. Le cose in effetti sono un po’ complicate, ma forse lo sarebbero molto meno se solo si capisse che il linguaggio Assembly, è del micro e non del firmwarista. Una parte del segreto sta nel cercare di avere una qualità che non saprei descrivere con una parola, direi che come concetto si avvicina all’empatia; bisognerebbe cercare di mettersi al posto (?!) di quel micretto e ragionare così come ragiona lui (?!?!?).

Le ntc sono termistori e sono l’acronimo di Negative Temperature Coefficient. Questo vuol dire che la resistenza aumenta con il diminuire della temperatura. Le ntc si distinguono per il valore di resistenza a 25°, ad esempio ci sono ntc da 10K da 15 K o da 4K7 e cosi via.

Come abbiamo visto la lettura della misura analogica viene implementata leggendo i tempi di carica e scarica del condensatore. Il rapporto fra i due tempi è un valore proporzionale alla resistenza della ntc e quindi della temperatura. I condensatori ceramici hanno un grosso errore percentuale le misure devono essere per tanti motivi molto accurate. Il test del firmware sulla scheda opportunamente modificata poteva essere fatto sul banco attraverso l’emulatore della Microchip. Ma poi si doveva fare il test, vero, sulla scheda e in quel caso si doveva programmare dei micro OTP ( One Time Programmer ) che erano i microcontrollori effettivamente utilizzati per la produzione. L’emulatore aveva una porta bruciata perchè in un progetto precedente era stata utilizzata come ingresso per la lettura del sync di rete e la scheda per la prova non era stata disaccoppiata.... Il pic ha dei robusti diodi di clamp in ingresso al micro, ma non abbastanza per la 220 volt e tanto meno per un rimbambito.

Squillava il telefono con la solita chiamata interna che arrivava dalla segreteria o da qualche altro ufficio dello stabilimento perchè i fax gli scanner e in generale tutto ciò che era alimentato con la corrente doveva essere gestito dalla progettazione...

Robert alzò la cornetta. Era Arnaux il responsabile della Ariete, di evidenti origini francesi che parlava quel tipico italiano erremosciato d'oltralpe. Non posso parlare con chi ha cadenze o particolarità nel linguaggio, dopo pochi minuti li acquisisco e inizio a parlare come lui.... l’erre moscia con i francesci, la elle al posto della erre con i cinesi...( e rischiando sempre di prendere dei pattoni... ). Arnaux gli disse che ormai dubbi non ce n’erano più ( beato lui ), aveva visto con i propri occhi la partenza spontanea di un ciclo di raffredamento senza che la batteria esterna fosse minimamente ghiacciata. Robert si alzò e attraversò tutto il laboratorio come se fosse Il_miglio_verde.
C’era poco da dire, discutemmo, un poco, per riuscire a capire, pensando e ripensando a tutti i nostri test operativi in laboratorio ma non avevano mai visto una cosa di questo tipo nei due mesi precedenti. Un falso contatto ? L'ntc aprendosi avrebbe mandato in overflow la procedura di lettura, e avrebbe mandato la macchina in uno stato di errore funzionale. Un corto sulla ntc ? Dubitavo fortemente, una resistenza bassa vuol dire temperature altissime perché mai dovrebbe sghiacciare.... Un baco nella macchina stati ? Anche in questo caso era molto poco plausibile, il modulo era provato e collaudato in numerosi progetti. Nel pic lo stack è hardware così non possiamo avere degli overflow, non ci sono interrupt e nessuna interruzione del programma è implementabile. E se la macchina resettasse ?

E così via ipotizzando le varie possibilità che si potevano creare. I test che avevamo effettuato erano abbastanza consistenti gran parte li avevo fatti io ed ero convinto di aver verificato tutto il verificabile. I tre prototipi installati in Ariete impostati in modalità pompa di calore, avevano, dopo qualche decina di minuti, attivato le fasi di raffreddamento senza che la batteria esterna fosse ghiacciata. I tempi ovviamente non erano ripetibili e cambiavano di volta in volta, i nostri due prototipi in laboratorio avevano attivata la funzione in pompa di calore da una settimana e non si era mai vista la fase di sghiacciamento della batteria esterna.

Erano le 17:30, spensi il monitor Trinitron della Sony e scrissi nel foglio sotto la tastiera “Ariete problema attivazione spontanea ciclo di sghiacciamento”. Cercavo un qualche appiglio in quelle parole come se potessero essere la chiave per inferire da dove provenisse il problema. Ma basta pensare era ora di tornare a casa...

Risolvere i problemi è quella caratteristica che accomuna i professionisti in genere ed è quella tendenza che gli americani chiamano “problem solver”. Questa caratteristica attraversa le professioni ed è particolarmente ricercata negli ambienti manageriali. Con molta probabilità il mio macellaio è più “problem solver” del sottoscritto e con molta probabilità potrebbe continuare ad essere migliore di tanti general manager all’interno dei gruppi industriali nazionali ed extranazionali.
Il re Salomone è, fra i personaggi storici, colui che più si distinse nella qualità della saggezza e della perspicacia, fra i racconti biblici celebre è la risoluzione del figlio conteso dalle due mamme che indubbiamente gli ha permesso di consolidare la sua già nota fama di problem solver ... ma lui era saggio per divina provvidenza.

Lavorare in Assembly significa lavorare con un micro nudo e bisogna implementare tutto, anche cose semplici come una somma o una sottrazione. Come si può notare l'operazione di sottrazione è implementata usando sempre quella della somma ma complementando il dato da sottrarre.

;-------------------------------------------------------
; H_SUB        : DIFFERENZA in HIGH PRECISION
; INPUT     : RB3_(1,2,3,4)-RB0_(0,1,2,3)
; OUTPUT    : RB3_(1,2,3,4)in 2'S compl.
; Comment    : Accetta in input solo numeri <EFFFFFFF!!!!!!
;-------------------------------------------------------
; complemento a 2 il dato e lo passo in ingresso ad H_Add.
P_H_sub
         comf        RB0_0,Same    ;complemento il dato da sottrarre
         comf        RB0_1,Same
         comf        RB0_2,Same
         comf        RB0_3,Same
         incf        RB0_0,Same    ;aggiungo uno
         skpnz
         incf        RB0_1,Same    ; eventuale riporto
         skpnz
         incf        RB0_2,Same    ; eventuale riporto
         skpnz
         incf        RB0_3,Same    ; eventuale riporto

;-------------------------------------------------------
; H_add        : somma in HIGH PRECISION
; INPUT     : RB3_(1,2,3,4) + RB0_(0,1,2,3)
; OUTPUT    : RB3_(1,2,3,4) in 2'S compl.
;-------------------------------------------------------
P_H_add
; Low nibble di fsr utilizzato come flags che contengono i vari riporti.
       movlw        0f0h        ; maschera
       andwf        Fsr,same    ; resetto flag
       movfw        RB0_0
       addwf        RB3_1,same    ; sommo il primo byte
       clrw
       skpnc
       movlw        01h
       addwf        RB0_1,w    ; sommo il primo riporto
       skpnc
       bsf          Fsr,0        ; salvo il primo riporto
       addwf        RB3_2,same    ; sommo il secondo byte
       skpnc
       bsf          Fsr,0        ; se ho il riporto me lo salvo
       clrw
       btfsc        Fsr,0        ; test riporto precedente
       movlw        1
       addwf        RB0_2,w        ; somm+o il riporto
       skpnc
       bsf          Fsr,1        ; salvo il secondo riporto
       addwf        RB3_3,same    ; sommo terzo byte
       skpnc
       bsf          Fsr,1        ; salvo riporto
       movfw        RB0_3
       addwf        RB3_4,same    ; sommo quarto byte
       btfsc        Fsr,1        ; test sul riporto precedente
       incf         RB3_4,same
       retlw        0h

-L’autunno era inoltrato, il freddo si faceva fastidiosamente sentire in quei paesi premontani. La nebbia saliva dal fiume sottostante per cercare il maggior fresco dell’altura. Le strade curvilinee attraversavano piccoli agglomerati di case grigie, con finestre illuminate, cucine movimentate dalla colazione nei piccoli tavoli, con vicino piccole stufette elettriche accese per stemperare l’aria. Agli incroci gente assonnata che attraversava il mondo per andare a lavorare o per affari propri, che magari ti guarda, fumandosi filtri di sigarette finite 10 minuti prima, in completo stato catatonico oppure non ti guarda affatto, intenta a rispondere al cellulare a genitori figli zii o cugini. Kirkegaard passava silenzioso su una Wolkswagen Polo anni 90 con gli U2 sempre a palla... distratto e solitario come ogni buon Nerd che si rispetti-

Il giorno dopo, entrai in laboratorio e raggiunsi la scrivania. Sull’attacapanni c’era la mia “cappa”, una specie di soprabito che il grande capo, desiderava fortemente far indossare a tutti. La misi velocemente e mi sedetti accendendo il pc, messo sotto la scrivania per risparmiare spazio. A fianco avevo la scheda prototipo sopra un tappetino antistatico di protezione. La sonda di batteria e quella dell’aria ambiente interna erano messe di lato e distanziate con meticolosa cura, l’oscilloscopio carrellato era pronto all’uso ma spento.

Di lato alla mia postazione era appena arrivata una macchina per il test della crimpatura cablaggi. Era una lunga scrivania con tanto di micro fresa, bagno acido e alla fine microscopio con interfaccia digitale su pc e un software di rilevamento ottico per la misura della superficie di contatto tra il filo conduttore e l'amp... Il cablaggio era stato il core business aziendale per molto tempo ma ora i margini di guadagno si stavano sempre più assottigliando.
Osservavo quella maledetta sonda di batteria arrotolata come una serpe velenosa sulla scrivania, il corpo della NTC era affogato in una resina all’interno di un cappuccio di rame. In produzione avevano una macchina artigianale che attraverso una decina di ugelli riempivano di resina array di cappucci in rame con dentro la ntc e tutta l'operazione veniva effettuata all’interno di una camera depressurizzata.

Quel Martedì un po’ alla disperata pianificammo di effettuare una trasferta per raggiungere l’azienda cliente. E così il Giovedì stesso partimmo all’alba percorrendo velocemente i trecento chilometri che ci separavano e, attraversammo le pianure emiliane su monotone autostrade, per raggiungere le grigie zone industriali lombarde. Passammo il tempo raccontando stupidaggiani, aneddoti, vecchie storie , in quella Audi A8 diplomatica da 330 cavalli con aria condizionata, e l’avveniristico GPS integrato....

La temperatura condizionata. (III/III)

Se nella vita pensi che sbagliando si impara, ecco ….allora il paracadutista non fa per te. ( anonimo )

La premessa sulle macchine combinatorie scritta nel capitolo precedente era necessaria per cercare di spiegare il metodo generale per la risoluzione dei problemi nei sistemi embedded. In tutti questi sistemi elettronici si crea un flusso di dati che nasce dagli ingressi e finisce con le uscite. All’interno di esso la logica sviluppata dal firmwarista interviene macinando triturando, scomponendo e aggregando quelli che sono gli elementi base di questo flusso, i dati. In realtà esistono due ulteriori moduli virtuali nel nostro sistema, sono la parte condizionatore dei segnali, in ingresso e la parte degli attuatori delle uscite. Questi moduli raggruppano tutto quell’insieme di circuteria elettronica che interfaccia il microcontrollore con il mondo esterno. Gli errori si riveleranno solo nelle uscite ( ovviamente ) alcuni saranno bloccanti altri saranno tollerati molto dipenderà dal grado di aspettazione che abbiamo del sistema.

Raggiungemmo a metà mattinata l’azienda che era un anonimo capannone di generose dimensioni in una zona industriale nella periferia di Milano. Il primo piano era al 90% predisposto ad officina meccanica. Alcune sezioni erano attive, altre erano spente e coperte con cellophan. ( il segno di una crisi anticipata ). Salii una scala metallica per raggiungere il laboratorio.

Entrammo in una stanza molto ampia e altrettanto illuminata. Le scrivanie erano allineate ordinatamente in due file e sopra una di queste, due tecnici montavano l' assieme di un condizionatore. In fondo a sinistra riconobbi il nostro prototipo e la sezione dove facevano le prove. Sulla destra una vetrata e poi una porta ampia e scorrevole dove si celava un ambiente che sembrava essere una camera termica. Uno dei tecnici si avvicinò e ci presentammo con misurato garbo e nello stesso momento Arnaux usci dall’ufficio felicissimo del nostro arrivo. I soliti convenevoli preliminari e subito iniziammo con la descrizione del guasto in tutte le sue varianti, a cui facevano seguito una miriade di dettagli, elenchi di particolarità delle operazioni fatte nelle ore precedenti. Era mattino inoltrato “Un caffè ?”... “Certo ! Ma non francese..” risate un po’ idiote per una pausa che sapeva tanto di pretesto per prendere ancora un po’ di tempo.

Qualche tempo prima avevamo saputo del disastro dell’Ariane esploso in volo. L’Ariane era un missille europeo utilizzato per l’invio di stratosferici satelliti, diventi l’odierna spazzatura cosmica ,che ogni tanto ci casca addosso. I progettisti avevano mantenuto tutta l' architettura hardware e software riprendendola dal progetto precedente l’Ariane 4 ( come se fosse un gigantesco cut and paste del progetto, perché squadra che vince non si cambia... ) e ufficialmente ammisero di aver sostituito unicamente i motori con un tipo più efficente e performante ( e scommetto anche più economico ) …. Non aggiungo oltre perché il report con la descrizione del bug che ha causato l’esplosione è molto bello e lo potete trovare in questo link. . Qui invece un articolo del famoso giornalista americano Gleik sempre sull’accaduto link .

Bene dopo questi rilassanti articoli, arrivammo sul condizionatore e mentre parlavamo, osservai l’evidente guida in plastica flessibile che univa le due unità, coprendo i tubi contenenti il gas compresso da una parte all’altra della batteria. Questa guida era composta da tanti moduli di una decina di centimetri ognuno, che venivano assemblati insieme; nella parte di contatto, c’era una specie di perno che rendeva possibile la variazione dell’angolo. Seguimmo con la linea dell’occhio il percorso di quella sonda all’interno del condizionatore, ma subito lo perdemmo perché entrava in una guida di plastica rigida che non potevamo smontare. Non c’erano altre macchine perché era un prototipo e quello che avevamo davanti era aimè l’unico pezzo completo disponibile. Allora ci spostammo sull' unità esterna e li scoprimmo il disastro.

Appena smontata la grata, ci guardammo e una gocciolina di sudore calò dalla fronte. Sull’unità esterna una spiralina scendeva perpendicolarmente dal supporto laterale che portava i tubi del Freon alla batteria. La spiralina viene utilizzata per rendere ordinato un generico cablaggio, ma in questo caso accoppiava insieme i fili della sonda di temperatura con le fasi di alimentazione della ventola esterna e del compressore, infine, per non farci mancare nulla, il neutro e il cavo di terra. Molti di voi sanno cosa succede quando abbiamo due conduttori accoppiati e in uno di questi, facciamo scorrere della corrente.

Ma il problema non era la spiralina.
Nei giorni successivi ripetemmo le prove in laboratorio che confermarono quanto visto in sede dal cliente. La 220 volt indotta causava gli errori sulla misura della ntc sulla batteria esterna provocando i cicli di sghiacciamento.

Il problema era che di soluzioni non ne avevamo. Potevamo eliminare la spiralina, potevamo evitare il passacavo sull' unità esterna ed interna, ma non potevamo sostituire il supporto flessibile, utilizzato per collegare le due unità. Questa specie di anaconda in plastica ( stampata brevettata e pubblicizzata ) prevedeva una sezione per il passaggio dei cavi che inevitabilmente li avrebbe resi solidali per tutto il percorso.
Riprogettare la guida? Schermatura della 220 volt?
Niente da fare alla fine l’Ariane era esploso anche a noi....

Tornammo a casa un pochino più seri. Le battute erano meno caciarone; mentre quella mattina si rideva... adesso i sorrisi erano appena accennati.

Il giorno dopo entrai in laboratorio. Feci un po’ di ordine nel codice e misi a posto un paio di macro. Erano di confronto tra flag di due registri generici. Queste macro avevano come parametri d' ingresso delle costanti utilizzate dal preprocessore dell'assembler e come si può notare sono costanti a 16 bit. Nella dichiarazione implementeremo nel byte alto l’indirizzo del registro, nel byte basso l’indice del bit che vogliamo utilizzare. Le macro le scrivevo in maiuscolo per capire subito dove fossero all'interno del codice e poi di solito aggiungo sempre una lettera ( nel nostro caso una f ) alla definizione delle costanti e dei registri per implementare Hungarian notation anche nel nostro ambiente assembly...

#define fSYNC         (Address1 << 8) | Address1 & 0FFh
#define fREADY_NTC    (Address2 << 8) | Address2 & 0FFh

es...

      SBSAME    fSYNC, fREADY_NTC
      jmp       Cycle_Main

Le macro saranno fatte in questo modo

;--------------------------------------------
; SBSAME    : Macro Compare two bit in general register and skip
;            if equal
;
; Input       Address1 : Address first register, and bit
;            Address2 : Address second register. and bit
; Output    NONE
; Ram        1 Reg : Spare_a
; Ram        1 Reg : Spare_b
;--------------------------------------------
SBSAME        MACRO        Address1, Address2
       clrf        Spare_a
       bsf         Spare_a,LSB
       btfss       Address1 >> 8) & 0FFh,Address1 & 0FFh
       bcf         Spare_a,LSB
       clrf        Spare_b
       bsf         Spare_b,LSB
       btfss       Address2 >> 8) & 0FFh,Address2 & 0FFh
       bcf         Spare_b,LSB
       movfw       Spare_b
       xorwf       Spare_a,w
       skpz
   ENDM
;--------------------------------------------
; SBDIFF    : Macro Compare two bit in general register and skip if different
;
; Input        Address1 : Address first register
;        Address2 : Address second register
; Output    NONE
; Ram        1 Reg : Spare_a
; Ram        1 Reg : Spare_b
;--------------------------------------------
SBDIFF        MACRO        Address1, Address2
       clrf        Spare_a
       bsf         Spare_a,LSB
       btfss       Address1 >> 8) & 0FFh,Address1 & 0FFh
       bcf         Spare_a,LSB
       bsf         Spare_b,LSB
       btfss       Address2 >> 8) & 0FFh,Address2 & 0FFh
       bcf         Spare_b,LSB
       movfw       Spare_b
       xorwf       Spare_a,w
       skpnz
   ENDM

Robert mi fece sapere che arrivò la conferma della proposta Sgs. Avevano abbassato i prezzi e dovevamo prendere in considerazione l’utilizzo dei suoi controllori l’ST6 per un Cronotermostato da sviluppare a breve per la York....

Silicon Bug (I/III)

Al mondo non ci sono che due modi per fare carriera: grazie alla propria ingegnosità o grazie all'imbecillità altrui. ( Jean de La Bruyère, I caratteri, 1688 )

Si supponga che, nel futuro, si possa costruire un computer che si comporti come se capisse il cinese.

In altre parole, il computer prenderebbe dei simboli cinesi in ingresso, eseguirebbe un programma e produrrebbe altri simboli cinesi in uscita. Si supponga che il comportamento di questo computer sia così convincente da poter facilmente superare il test di Turing.

In altre parole, che il computer possa convincere un uomo che parla correttamente cinese (per esempio un cinese) di parlare con un altro uomo che parla correttamente cinese, mentre in realtà sta parlando con un calcolatore. A tutte le domande dell'umano il computer risponderebbe appropriatamente, in modo che l'umano si convinca di parlare con un altro umano che parla cinese. I sostenitori dell'intelligenza artificiale forte concludono che il computer

capisce la lingua cinese, come farebbe una persona, in quanto non c'è nessuna differenza tra il comportamento della macchina e di un uomo che conosce il cinese. Questa è la "famosa" ipotesi della stanza cinese di Searle ma veniamo alla nostra storia e al più terrificante e devastante bug che un firmwareista può incontrare, il silicon bug....

Peter Solonico era il buyer della azienda dove lavoravo e il suo ufficio aveva posto vicino l'amministrazione. Ricevette una telefonata da Simon che invece era il responsabile commerciale nella nostra zona della ditta fornitrice di componenti elettronici. La chiamata di routine era stata fatta per alcuni aggiornamenti che Simon aveva ricevuto qualche giorno prima ad un meeting aziendale. Parlarono di molte cose, come gran parte delle telefonate di quel tipo, e quindi della evidente crisi, dei mercati finanziari, di come le aziende non fanno più investimenti, un po’ di retorica dei disastri e fra le varie lamentele anche del micro usato negli ultimi progetti aziendali . Il microprocessore era un Texas Instruments TMS430F149 un micro molto interessante e particolarmente performante nelle applicazioni a basso consumo energetico.

“Ti dicevo che abbiamo un aggiornamento per quel micro. C’è infatti il modello successivo il TMS430F249 che potete tranquillamente sostituire nella vostra produzione corrente. Costa un euro di meno del precedente, consuma la metà... così è perfetto per le vostre applicazioni low power ”

“mmm … Ma sei sicuro che non ci sono problemi, e posso sostituirlo ?”

“Vai tranquillo il nostro FAE ha detto che sono equivalenti sia hardware che software”

“Va bene mi hai convinto … allora mandamene 170 pezzi così il prossimo lotto lo facciamo con questo micro”

“Perfetto. Te li mando subito...”

“Benissimo .. allora ci sentiamo a presto”

“Ciao..”

“Ciao..”

Arrivai in sede piuttosto trafelato e affaticato dalla lunga settimana di lavoro che finalmente sembrava finire. Gli uffici dove lavoravo, questa volta, erano dei luminosissimi open space con soffitti molto alti e ampie finestre addobbate da monotoniche veneziane che celavano la vista ad un angosciante parcheggio esterno. Le postazioni di lavoro erano suddivise da separatori che erano poco più alti delle scrivanie. A fianco a me c'era Sasha , l'elettronico masterista addetto alla progettazione di tutti i disegni sia meccanici che elettrici, assemblava i prototipi, eseguiva test preliminari, fumava sigari toscani, e le solite malelingue sostenevano che aveva anche una omossessualità pesantemente occultata.

Arrivai con qualche minuto di ritardo e subito accesi il pc mettendo a posto il perenne disordine della scrivania, subito, mi accorsi della presenza inquietante di Malcom, il terribile responsabile della produzione. Era tanto brutto quanto odioso ma oltremodo indispensabile per la vita aziendale; constatare che fosse odioso al sottoscritto era davvero di poco conto e anzi, per molti colleghi diventava un pregio. Con la coda dell’occhio vidi che Malcom arrivava con anomalo passo trafelato, passo che tipicamente adottava quando si creavano situazioni critiche e che noi invece figurativamente rappresentavamo con una goffa pantomima facendo l'aereoplanino come se fossimo dei cetrioli volanti... a bassa quota.

“Kirk senti … ti ricordi quando l’altra settimana abbiamo comprato il programmatore della Texas.”

“Si …” ma durante i puntini di sospensione credo di aver assunto una espressione inequivocabilmente inquietante che era una via di mezzo fra l’angoscia kierkegaardiana e la dolorosa sofferenza di un dito schiacciato da una sportellata.

“Quando hai finito con le faccette da ebete, considera che ieri sera abbiamo iniziato la programmazione delle schede ma il micro ... non si è nemmeno acceso. Non va.... ” una pausa di riflessione dove uno volentieri si sparerebbe sui maroni e poi la conclusione scontata dell’epitaffio “...potresti darci un occhiata ?”

Un occhiata ? Perchè non gliela dai te l'occhiata sacco di m...

Mi concentrai per cercare di occultare quello che pensavo poi alla fine come sempre cedetti “Si …. dammi un attimo che mi riprendo dallo shock per averti visto così presto.... arrivo subito”

Parlando di cose serie come dicevo il Texas MSP430 e' un micro particolarmente interessante. Si distingue per essere un classico Von Neumann ma a 16 bit che però essendo di nuova generazione ne hanno reso l'architettura interna sotto molti aspetti particolarmente efficiente. É un 16 bit nativo e quindi la gestione dei registri è stata tutta progettata per lavorare con questa struttura dati. Il micro è un RISC con un ciclo macchina da 125 ns che garantisce efficenza e versatilità, in particolar modo nella gestione dei registri interni e del salvataggio su ram; per i dettagli potete vedere il seguente link. Abbiamo un convertitore a 12 bit, due timer a 16 bit con una decina di configurazioni capture/compare. E’ anche un lowpower con diverse configurazioni per la gestione del basso consumo. In standby con risveglio da interrupt consuma meno di 2 uA. ( avvicinandoci molto alle correnti di scarica di una batteria... ).

Un elemento fondamentale nello sviluppo di un firmware è quello di avere a disposizione nel codice una struttura dati che ci possa indicare il trascorrere del tempo. Questa struttura dati è, in realtà, semplicemente una serie di registri che vengono aggiornati attraverso un interrupt di un timer interno del nostro uC. Per la gestione dei timer di sistema si può implementare una routine assemby tipo quella sottostante. La routine è tutto sommato molto semplice grazie anche agli opcode RISC che il micro mette a disposizione.

#include  "msp430x14x.h"

#define MAX_TIMERS    8

    rseg CODE

PUBLIC __timer_handler

EXTERN glbTimers

__timer_handler:

   ; push.w R2
   push.w R4
   push.w R5
   mov.b #MAX_TIMERS,R4
   mov.w #glbTimers,R5
Loop:
   cmp.w #0,0(R5)
   jz IsZero
   dec.w 0(R5)
IsZero:
   add #2,R5
   dec.b r4
   jnz Loop
   pop.w R5
   pop.w R4
   ; pop.w R2
   ret
   end

Se questa routine la associamo ad un interrupt di un timer interno che viene richiamato a cadenza costante, ecco pronta una struttura dati che ci permetterà di verificare il trascorrere del tempo; ma ora descriviamo velocemente il nostro progetto.

Questa volta la ditta cliente era l’Italgas e l'applicazione era per la loro rete di distibuzione nazionale. Il piccolo sistemino veniva e viene utilizzato per la lettura delle correnti catodiche dei metanodotti. Tento di descriverlo meglio. Il gas di Putin arriva in Italia attraverso condutture da 50 / 60 bar di pressione. Tipicamente nei pressi di grandi svincoli di distribuzione del gas e in mezzo a sperdute campagne, ci sono delle cabine chiamate di primo salto che diminuiscono drasticamente la pressione del gas dai 50/60 bar ad una decina di bar. Queste condutture raggiungono poi le periferie cittadine dove ci saranno altre cabine dette di secondo salto che porteranno il gas sino alla pressione di qualche bar ( 4.5 tipico ). Queste poi raggiungeranno le ultime cabine di terzo salto dove il gas viene portato alla pressione di esercizio cittadino che è di qualche millibar ( tipicamente 20). Per ulteriori dettagli potete vedere il seguente link

Dopo questa velocissima descrizione adesso addentriamoci in un dettaglio che ci interessa. Tutte queste condutture soffrono di un problema peculiare che è tipico di questi sistemi. Un tubo metallico, a contatto con il terreno si deteriora corrodendosi. Questa fenomeno fisico di corrosione non è quello che conosciamo di ossidazione del metallo chiamato ruggine; questa corrosione è causata invece, dalla meno ovvia differenza di potenziale che nasce fra la struttura metallica e il terreno circostante. Questa differenza di potenziale, crea le correnti catodiche. Il problema è globalmente riconosciuto ed è stata sviluppata tutta una tecnologia, che si chiama sistema di protezione catodica. Il continuo monitoraggio di queste correnti, consente di prendere delle contromisure che attenuano e rallentano i pericolosi effetti di corrosione che, se degenerassero incontrollabilmente, potrebbero provocare pericolosissimi fori nella tubazione. Queste contromisure “semplificando”, consistono nel rendere immune il metallo della tubazione cercando di annullare queste corrosive correnti. L’operazione di immunizzazione viene resa possibile mettendo sotto tensione la tratta con potenti alimentatori creando così delle correnti inverse che annullerebbero quelle naturali del sistema... ma ci sono altre tecniche. Questo è il corso ( a pagamento ? ) Italgas dove potrete vedere probabilmente anche i nostri apparati...

Il progetto firmware non era il mio ma lo avevo ereditato dal mio predecessore. Premesso che era ed è un amico, questo fatto dell'eredità del firmware rendeva comunque le cose più complicate, perchè progetti di questo tipo sono particolarmente sofisticati dal punto di vista ingegneristico e il mio predecessore non era niente male come firmwarista; ma lo capiremo meglio fra un po'....

Raggiunsi la produzione come un cammello che sta per entrare nel deserto. Ora pensavo che la volta precedente avevamo scoperto che il programmatore non supportava il nuovo modello di microcontrollore, ma questa volta era chiaro che c'era qualcos'altro. Verificai che effettivamente tutta la procedura di programmazione era stata effettuata correttamente. Dopo pochi minuti feci una telefontata al Chiatti che era il FAE italiano per quella famiglia di microcontrollori.

"No Kirk avevamo già parlato di questo.. ."

"Si... ma non con me..."

"Il progetto lo devi ricompilare però non basta ... ci sono delle piccole modifiche da fare... "

"Si ma perché non ne parliamo prima... e poi piccole... ho gia capito tutto...."

"Ti mando il pdf..."

"Si ... manda manda... il pdf...."

e da quel momento niente fu come prima...

Silicon Bug (II/III)

Ora, Searle chiede di supporre che lui si sieda all'interno del calcolatore. In altre parole, egli si immagina in una piccola stanza (la stanza cinese) con un libro contenente la versione in italiano del programma utilizzato dal computer e carta e penna in abbondanza. Searle potrebbe ricevere scritte in cinese attraverso una finestra di ingresso, elaborarle seguendo le istruzioni del programma, e produrre altri simboli cinesi in uscita, in modo identico a quanto faceva il calcolatore. Searle fa notare che egli non capisce i simboli cinesi. Quindi la sua mancanza di comprensione dimostra che il calcolatore non può comprendere il cinese, poiché esso è nella sua stessa situazione. Il calcolatore è un semplice manipolatore di simboli, esattamente come lo è lui nella stanza cinese - e quindi i calcolatori non capiscono quello che stanno dicendo tanto quanto lui. ( tesi della stanza cinese di Searle )

Non impiego molto a comprendere che il sistema di sviluppo che ho a disposizione non supporta il nuovo microcontrollore e quindi mi scarico dalla IAR quello completo con licenza a 30 giorni. Compilo ma il codice si blocca in due punti.

Uno è all’interno di un modulo assembly di inizalizzazione della memoria interna. L’altro è nella misura della frequenza del DCO.

Spieghiamo meglio cosa è il DCO ( Digitally Controlled Oscillator ). Dietro questa sigla si cela un vero e proprio oscillatore interno al micro estremamente veloce nella risposta che è stato progettato dalla Texas come clock di sistema. Il micro MSP430F249 ha questa configurazione del clock.

XT2 Clock esterno Alta/Bassa frequenza ( 400 kHz / 16 MHz )
LFXT1 Clock esterno Alta/Bassa frequenza ( 400 kHz / 16 MHz )
DCO Clock interno

VLOCKL Clock interno frequenza fissa con bassissimi consumi ( tipicamente 12 kHz )

I device interni del micro possono prendere questi oscillatori attraverso queste impostazioni configurabili.

ACLK clock ausiliario
MCLK master clock
SMCLK submain clock

La lettura della frequenza del DCO è stata implementata ad solo uso diagnostico, ma è piuttosto importante perché il micro nella nostra applicazione lavora per il 90% del suo tempo con questa frequenza. L’oscillazione nella release precedente era un rc effettuata con una resistenza esterna mentre in questa release abbiamo utilizzato la resistenza interna. Descrivo velocemente come viene implementata la lettura di questa frequenza.

In pratica si sfrutta una tipica funzione chiamata capture dei timer. Questa funzione consente di rilevare lo stato del timer quando accade un certo evento. Questi eventi possono essere associati a pin esterni oppure come nel nostro caso possiamo avere come evento i fronti del quarzo esterno FLXT1 che è da 32 kHz. Il nostro timer per il conteggio lo associeremo invece al DCO interno. Ad ogni fronte del clock esterno il timer si resetta e inizia a contare alla frequenza data dal DCO. Al secondo fronte il dato letto viene trasferito nel buffer e nello stesso tempo si resetta per consentire la prossima eventuale lettura. Se leggiamo 1 la nostra frequenza sarà 32 kHz, se leggiamo 2 64 kHz... e così via. ( e così abbiamo un lsb da 32 kHz... )

Ora ecco il fatidico codice che il mio predecessore aveva scritto per misurare questa frequenza.

 //-----------------------------------------------------
 // GetDCOFreq
 // Utilizza il TimerB e ACLK(32 kHz) per misurare la frequenza del DCO (torna valore in Hz)
 //-----------------------------------------------------
 LONG  MSP430_GetDCOFreq()
 {
   BYTE  SmclkFromXt2;
   WORD  n1,n2;

   // Setta un flag se SMCLK è ricavato da XT2
   if (BCSCTL2 & SELS)
		SmclkFromXt2=1;
	else
		SmclkFromXt2=0;

	// Ricava il clock per SMCLK da DCO
   BCSCTL2 &= ~SELS;
   // Accende TimerB: conteggio continuo a 16 bit, clock = SMCLK
   TBCTL = TBSSEL1 | MC1 | TBCLR;
   // Capture da CC16B=ACLK, rising edge
   TBCCTL6 = CM1 | CCIS0 | SCS | CAP;
   // Attende il primo evento di capture
   while ( (TBCCTL6 & CCIFG)==0 ) {};   <--- DEAD LOCK
   // Memorizza valore attuale
   n1 = TBCCR6;
   // Azzera flag di capture e overflow
   TBCCTL6 &= ~(COV|CCIFG);
   // Attende il prossimo evento di capture
   while ( (TBCCTL6 & CCIFG)==0 ) {};
   // Memorizza valore attuale
   n2 = TBCCR6;
   // Se si e' verificato un overflow azzera il valore, se no calcola la differenza
   if ( (TBCCTL6 & COV) != 0 ) n2=0; else n2=n2-n1;
   // Ferma il TimerB
   TBCTL = 0; TBCCTL6 = 0;
   // Ripristina il clock a SMCLK da XT2 se necessario
   if (SmclkFromXt2 != 0) BCSCTL2 |= SELS;
   // Ritorna il valore calcolato in KHertz
   return( (n2*32768L)/1000L );
 }

L'interfaccia Jtag nasce come sistema di comunicazione dati con gli integrati per implementare il Boundary Scan. Tipicamente le aziende produttrici di elettronica si adoperavano per sviluppare attrezzature di collaudo per garantire un adeguato livello di qualità del prodotto.
Il collaudo si suddivide in due parti, il primo collaudo viene effettuato sulla scheda mentre il secondo sull'assieme.
Il boundary scan è una evoluzione del collaudo in circuit e il Jtag era il sistema di comunicazione. Questo sistema si è evoluto diventando l'interfaccia principale degli emulatori moderni. Decadi or sono gli emulatori infatti erano dei sofisticati probe con sopra sostanzialmente un micro che aveva una interfaccia in grado di emulare a sua volta il micro del nostro progetto. ( come ad esempio la mitica Metalink.... )

Sviluppare firmware con questi oggetti era una pacchia. Break point condizionali, trace, call stack aggiornamenti in real time di variabili; tutte queste cose rendevano più semplice lo sviluppo di applicativi.

Ma se torniamo indietro nel tempo gli antesignani dei sitemi di sviluppo per il debug di schede embedded, erano gli emulatori; non dei micro ma bensì delle eeprom. ( ricordo bene il cassone della Deneb per emulare la eeprom dello z80....)

Adesso i costi si sono notevolemente ridimensionati con il risultato costringere il firmwarista a sviluppare software con sistemi talmente economici da essere regalati dal fornitore.

Ma veniamo alla nostra storia. Il punto dove si bloccava il codice è quello, nel codice soprastante, segnato nel commento Dead Lock.

Squilla il telefono. Un cliente ha effettuato un ordine da due mesi ma l’ordine non è stato evaso e nessuno ( cosa ben peggiore ) lo aveva chiamato.

Volevo dirgli che la cosa mi sembrava molto coerente... invece presi nota. Salutai con garbo e chiusi il telefono.
Intanto mi chiama Mangusta, l’amministratore delegato della azienda che mi stupra, e nel frattempo mi estorce una settimana per finire il porting del progetto.
Ritorno in ufficio ancora stordito dal veloce meeting.
Commento le due sezioni di codice che bloccavano il programma e passo al porting che mi impegna allo spasmo per un paio di settimane.

Poi arriva Agosto che ha due settimane di ferie e Mangusta scende e viene a salutarmi augurandomi calorosamente buone vacanza.

Quando torno la licenza era scaduta e allora cerco una release dello IAR workbench con crack ma non riesco a trovarlo.

Navigo fra warez, altavista, torrent, siti pirata&porno e finisco la giornata bello arzillo ma niente crack.

Allora scarico un’altra licenza a 30 giorni e la installo in un portatile.... ma ho bisogno di un nuovo jtag perché quello che ho è solo parallelo, e i portatili hanno solo interfacce usb.

Mi faccio mandare il jtag personale del FAE dichiarando lo stato di emergenza.

Mangusta ogni giorno mi saluta e sembra che mi dica “... io ti perdono” La situazione degenera il telefono squilla in continuazione, la produzione è bloccata e da Defcon5 arriviamo diritti a Defcon1.

Silicon Bug (II/III)

La coscienza e' il caos delle chimere, delle cupidigie e dei tentativi, la fornace dei sogni, l'antro delle idee di cui si ha vergogna; e' il pandemonio dei sofismi, e' il campo di battaglia delle passioni. Penetrate, in certe ore, attraverso la faccia livida d'un uomo che sta riflettendo, guardate in quell'anima, in quell'oscurità; sotto il silenzio esteriore, vi sono combattimenti di giganti come in Omero, mischie di dragoni ed idre e nugoli di fantasmi, come in Milton, visioni ultraterrene come in Dante. Oh, qual abisso è mai quest'infinito che ogni uomo porta in sé e col quale confronta disperatamente la volontà del cervello e gli atti della vita! (Victor Hugo)

Guardo fisso il quadrato rosso che sapevo non sarebbe mai diventato verde. Quel parallelepipedo rosso è il modo con cui il sistema di sviluppo dello IAR segnala la presenza di un breakpoint nel codice.

Quel quadratino è un po’ come una tappa parziale dove si scatta una istantanea all’atleta che la raggiunge. In questa metafora figurativa il microcontrollore, che corre sul codice, una volta raggiunto il traguardo intermedio si ferma e in quella attesa si visualizzano le proprietà dei registri interni. Alcuni registri hanno a loro volta i valori evidenziati di un colore rosso e anche questa è una buona utility che ti permette di capire quali sono stati aggiornati dall’ultimo break.

Da tre giorni armeggio dentro quella procedura. Ho cambiato lo stato di tutti i registri con il preciso intento di verificare le funzionalità alternative che il micro mi mette a disposizione ma il vero problema era che non avevo la più pallida idea di come uscire da quello stato di impasse. Anche io ero dentro un quadratino verde. Fermo, immobile, stanziale nella peggiore delle posizioni, quella condizione infame di non avere strade da percorrere.

Un vicolo cieco.

Il tempo in quei momenti si rallenta… i suoni si fanno vacui mentre entri in una palla di vetro. Tutto intorno a te si muove velocemente ed è frenetico. Tu invece rallenti i movimenti e addirittura li ripeti senza controllo... Il micro si blocca e poi dopo qualche secondo resetta e poi riincomincia..... si blocca … resetta …. e rincomincia in un ciclo infinito.

Quell’unico led sulla scheda si spegne per un attimo durante il reset per poi riaccendersi nella interminabile sequenza. Squilla il telefono, in amministrazione non si accende un monitor e la segretaria non può lavorare....

Una delle parti dove il codice nei giorni precedenti si bloccava era in un modulo assembly che viene fatto partire allo startup prima del main. Questo modulo ha al suo interno due sezioni di codice che devono inizializzare due zone di memoria che lo IAR mette a disposizione. Queste due sezioni si chiamano:

DATA16_I
DATA16_Z

Sostanzialmente lo IAR prevede due tipi di variabili, quelle che vengono inizializzate a zero e quelle con valori diversi da zero. Le variabili inizializzate a zero venivano resettate utilizzando una funzione di libreria standard del C chiamata memset. Le variabili invece inizializzate con valori diversi da zero utilizzano una altra funzione di libreria chiamata memcpy. Col la nuova releasa dello IAR, necessaria per utilizzare il nuovo microcontrollore, la funzione memcpy falliva andando in deadlock ( che noia... ).

Disassemblo il codice e vado a vedere al suo interno fin dove effettivamente si blocca. Passo, passo, opcode su opcode... sembrava che i registri fossero inizializzati a casaccio. Allora modifico il main e provo la memcpy. Disassemblo e strabuzzando gli occhi vedo che effetivamente l'inizializzazione della memcpy è diversa da quella che veniva implementata nel modulo assembly. Cosa era successo ? Niente di più banale. La versione aggiornata dello iar aveva rivisiato tutte le librerie interne e riiscritto i moduli. La riscrittura delle funzioni di libreria prevedeva un diverso passaggio dei parametri. Nel mio caso il parametro della lunghezza non veniva passato più sullo stack ma veniva passato attraverso un registro del micro.

Il mio predecessore per altri motivi che non sto a spiegare aveva fatto un merge di questi file e aveva implementato queste funzioni manualmente. Così visto che non siamo qui a lavare gli scogli della battigia ho riiscritto le due funzioni di memcpy e memset per essere sicuro che non ci fossero più problemi con le librerie al prossimo aggiornamento del compilatore.

       MOV     #SFB DATA16_Z, W0
       MOV     #sizeof DATA16_Z, W1
       mov.w   #00,R15
?memset:
       mov.w   R12,R10
?memloop1:
       mov.b   R15,0x0(R10)
       inc.w   R10
       dec.w   R14
       tst     R14
       jnz     ?memloop1

Questa è invece la memcpy

       MOV     #SFB DATA16_I,  W0
       MOV     #SFB DATA16_ID, W1
       mov.w    #sizeof DATA16_I,R15
?memcpy:
       mov.w   R12,R10
?memloop2:
       mov.b   @R14+,0x0(R10)
       inc.w   R10
       dec.b   R15
       tst     R15
       jnz     ?memloop2

Mi alzo stirandomi la schiena e vado in bagno che utilizzo come personale ufficio per i casi estremi. Il bagno in quella azienda era identico a quello delle carceri americane, chiuso, senza finestre con condutture scatolate appese sul soffitto che fungevano da aspiratori. Lampade al neon morenti lampeggiavano gli ultimi istanti di vita. Mi siedo sulla tavola abbassata considerando appunto che sono li per pensare o forse no.... forse sono li per non pensare. Le porte sono sfondate ci sono due bagni rotti, poi la luce intermittente rende l’ambiente davvero surreale.

Il codice era collaudato da migliaia di installazioni effettuate su un progetto precedente che aveva una piattaforma hardware identica e invece in questa vita nefasta su quel nuovo microcontrollore si bloccava, continuamente... Ripresi il datasheet e cercai di interpretare i flag che non venivano utilizzati dal mio codice, ma che era possibile modificare implementando nuove funzioni. All’interno di un registro di configurazione delle modalita operative del timer c’era un flag chiamato di sync utilizzato per allineare gli eventi del gate aperto dal quarzo esterno con lo stato del timer aggiornato direttamente dal DCO. Se lo resetto questo flag di SYNC l’evento scatta subito sbloccando il micro dal dead lock fatale. Osservo e allargo la sottofinestra dei registri interni. Il valore del timer alla fine della procedura è vuoto non ha contato nemmeno un fronte, non c’era niente da fare nemmeno quella era la strada da percorrere.

Un giorno.... e poi un altro … e poi un altro ancora. Ho un pesante sospetto nella testa ma non posso credere che ci sia un baco nel silicio. Somatizzo la situazione e resetto anche io in continuazione, guardo il led verde di un cellulare gsm appoggiato sul tavolo che lampeggia velocemente e capisco che si è appena registrato sulla rete, forse dovrei fidarmi più di me stesso, non c'è niente di sbagliato nel codice.....

Passa ancora un giorno e alla fine esausto chiamo il FAE della famiglia di questo microcontrollore. Loro ne sentono di tutti i colori e francamente non so come ma riesco a convincerlo che sono in una fossa delle marianne di liquami, allora in un atto di benevolenza mi mette in contatto con il tecnico tedesco. Quello che contatterò via e-mail sarà un super tecnico europeo della Texas Instrument. Gli descrivo il problema e gli spedisco la funzione maledetta, per cercare di agevolarlo. Dopo qualche ora una prima doccia fredda, il tedesco risponde in un inglese stentato che nel suo sistema la funzione non si blocca e mi rispedisce il codice purificato implementato. Apro la email e scarico l’allegato. Guardo il suo progetto ma in quel momento scopro una differenza importante.
La lettura della frequenza DCO il tedesco l’aveva implementata utilizzando come clock di sistema il principale proprio DCO stesso mentre io invece utilizzavo il clock esterno XT2. Cosa c’entrava questo con il dead lock ? Perchè il timer non segnava nulla utilizzando come sorgente il DCO ? Non c’era niente di logico in quello che vedevo e non c’era niente di associabile fra le due frequenze master e il Timer.

Metto a conoscenza il tedesco del problema che ho visto sulla mia scheda implementando il suo codice e dopo un giorno mi conferma che anche lui ( deo gratias ) aveva visto il blocco del codice utilizzando come clock di sistema l’XT2 esterno. A questo punto anche lui riconobbe l’estrema anomalia e ammise il limite delle sue competenze e così purtroppo non poteva far altro che passare il problema direttamente ai progettisti del silicio del micro.

Dopo una settimana arrivò il responso.... ero incappato nel peggiore incubo che un firmwarista può incontrare nella sua carriera il Silicon Bug.

Il problema dei silicon bug è che sono difficilissimi da diagnosticare perchè tipicamente e ( fortunatamente ) vengono fuori in condizioni di utilizzo estreme. Il problema è che quando si arriva a concludere che c’è un baco nel silicio del micro ( e non nel silicone ) sapete cosa accade ?

Nulla.

I tecnici del silicio della Texas riconobbero il problema sulla attivazione del DCO come clock del sottosistema e mi inviarono un round tips che avevo già scoperto. Le tre settimane precedenti svaniscono in un attimo, come quando ti risvegli da un incubo. Ma adesso che sei sveglio ti accorgi che hai un altro problema, spiegare a Mangusta il perchè di quel ritardo che oramai aveva superato il mese. Spiegargli il silicon Bug ? Rinunciai. Mi presi un altro po’ di pesciate d’ordinanza che invece non potevo rinunciare.

Esco dal parcheggio e imboccando la strada che poi arriva alla statale, guardo i capannoni che circondano la zona. Uno era un gigantesco deposito di giocattoli cinesi chiuso cinque anni fa e rimasto tale dopo l’ingiunzione fallimentare, a fianco un altro abnorme capannone scheletrico; ne avevano alzato le pareti prefabbricate e i pilastri portanti ma il fatale fallimento era arrivato prima di raggiungere il tetto. Mi giro di lato e vedo il furgone degli zingari che attraversa come una sentinella la zona in cerca di rame. Poco più in là un call center arnia con un continuo andirivieni di servi della globalizzazione. Ma quella sera era come dire... diverso. Ero molto più rilassato in quel posto di cemento e acciaio e con rammarico ripenso alle sere precedenti... che avevo buttato via. Metto la freccia e mi fermo in una enoteca, un collega mi ha parlato di un bolgheri blasonato che non ti depaupera le tasche e compro così un Guidoalberto del 2003. Piove ma non mi importa...

In questo link potrete vedere lo scambio di messaggi accaduto realmente fra un utente con uno strano nome Kirk&gaard ( davvero questi ragazzi hanno una gran fantasia... ;-)... ) con il FAE tedesco della Texas che poi ha dato spunto a questo raccontino

120/120