
Ecco le 3Domande per Daniele Basile, relatore al prossimo Better Embedded di Firenze. Progettista elettronico su sistemi embedded che ho avuto il piacere di incontrare di persona e quindi scambiare esperienze ed idee sulla progettazione elettronica. Attualmente ricopre la figura di Embedded Developer in Develer.
Daniele: Sono un Ingegnere Elettronico, e dal 2007 lavoro in Develer, come progettista e sviluppatore di sistemi Embedded. Nell'ambiente dove lavoro ho potuto approfondire molto la mia conoscenza del mondo open source, e anche di tutte quelle tecnologie che ruotano al mondo embedded. La mia principale attività è quella di progettare, e a volte anche produrre, schede elettroniche per i nostri clienti, per svariati ambiti, che vanno dal medicale al ferroviario.
Oltre a progettare le schede, mi dilettato anche nella programmazione e allo sviluppo di applicativi per embedded, dove ho anche collaborato allo sviluppo di BeRTOS, un sistema operativo real-time, proprio per sistemi con poche risorse hardware.
Puoi anche dare un tuo parere sullo sbroglio automatico, è utile realmente o è solo una trovata commerciale?
Daniele: Certamente al giorno d'oggi esisto molte soluzioni commerciali e non, per sbrogliare circuiti elettronici. Secondo la mia modesta esperienza, chi inizia a fare questa attività si trova a doversi districare tra diverse "filosofie di interfaccia" che ogni cad ha. In sostanza, come avete bene recensito voi, ci sono molti cad validi e completi, ma con una usabilità completamente diversa tra loro e quindi portano l'utente a dovere spendere del tempo per imparare uno o l'altro, e spesso questo lo legano ad usare sempre lo stesso cad. Personalmente, ho trovato valido Eagle di CadSoft, che per circuiti più o meno complicati, offre una interfaccia abbastanza intuitiva, e ti consente di imparare un po' la tecnica per cercare il cad che più è tagliato per le propria esigenza. Molto peso nella scelta è dovuta al sistema operativo su cui gira, dove purtroppo Windows la fa da padrone, e obbliga molte persone che hanno Linux o Mac a usare un po' di soluzioni scomode, come macchine virtuali, dual boot o altro.
Per quanto riguarda lo sbroglio automatico, io la reputo più una trovata commerciale che un vera alternativa allo sbroglio manuale.
Questo perchè, almeno per me, il grosso del tempo va nel piazzamento dei componenti e nella rifinitura dello sbroglio (piani di massa, serigrafia, ecc.), che va fatto comunque a mano, invece il tempo che ci vuole per disegnare le varie piste, per uno con un po' di esperienza, è quasi pari al tempo che uno impiega a configurare correttamente la funzione di sbroglio automatico. Oltre a questo c'è anche un po' di sana vanità e di filosofia, perchè c'è chi nello sbroglio ci vede un po' un "arte", e anche perchè un occhio, anche con poca esperienza, evita di fare cose sciocche e potenzialmente pericolose.
Lo trovo molto interessante e, avendo progettato e sbrogliato circuiti per 20 anni, mi piacerebbe confrontarmi su aspetti pratici e problemi reali riscontrati. Puoi anticiparci almeno una delle problematiche che affronterai, così poi ne discutiamo insieme alla community nei commenti?
Daniele: Grazie alle nuove tecnologie i sistemi embedded stanno diventando sempre più complessi, e necessitano di hardware sempre più performanti. Per questo motivo nasce l'esigenza di progettare schede dove possono girare sistemi operativi completi come Linux.
Progettare una scheda Linux di certo ha un complessità maggiore, dovuta al fatto che le frequenze in gioco sono alte, e si devono utilizzare memorie RAM esterne, che porta a dovere considerare anche i problemi di integrità del segnale.
Ovviamente il quadro si complica quando la scheda deve essere ingegnerizzata, e se deve funzionare in un ambiente particolare, tipo quello industriale. Altre considerazioni vanno fatte: sulla alimentazione, su che tipo di memoria non volatile utilizzare, se bisogna avere un memoria dove scrivere dati, se c'è bisogno di avere una data sempre valida, in che modo va prodotta collaudata e programmata per la prima volta, che problemi di compatibilità elettromagnetica ci possono essere, sulla reperibilità dei componenti, sui costi, ecc.
Insomma, ci sono molti aspetti da tenere di conto, ne cito forse il più critico, ovvero i segnali dalla/alla RAM, che dovendo funzionare con frequenze alte, è importante che tutti i segnali abbiano tempi di propagazioni simili e comunque sempre all'interno delle tolleranze raccomandate dal costruttore, oltre a questo ci possono essere problemi di crosstalk, dove segnali vicini si possono influenzare alterando il vero livello del segnale. Tutti questi problemi sono strettamente legati al tipo di RAM, dal numero dei banchi, alla topologia che si utilizza per collegarle, dal tipo di package, dalla disposizione sullo stampato, piani di massa e alimentazione e layout dello stampato.
In generale per una corretta progettazione di una scheda Linux esistono molte linee guida e best practices, ma come sempre un po' di esperienza e qualche dritta, a volte possono fare la differenza.

Sulla seconda domanda, ha perfettamente ragione!
Sono d’accordo!
Non l’ho mai definita una trovata commerciale ma più una traccia per novellini però effettivamente è un po’ come sentire di una macchina che si guida da sola oppure di un jet che non ha bisogno del brevetto…
Progettare non è per tutti e soprattutto progettare non è facile.
Ci vuole tempo, pazienza, costanza… Non si impara da un giorno all’altro e non è cosa semplice.
Non si “schiaccia autoroute” e poi si dorme 😀
Sulla terza domanda avrei un dubbio: quando si parla di ” tempi di propagazioni ” stai parlando anche dei tempi di latenza?
No, i problemi a cui mi riferiscono dipendono dal tempo in cui i segnali si propagano sulle piste, ed è direttamente connesso con la geometria dello stampato e dai tipi di dielettrici che vengono utilizzati.