I microcontroller PSoCx della Cypress e il loro ambiente di sviluppo uniscono la facilità d'uso apprezzata dagli Arduinisti ad un front-end analogico interessante senza essere dei giocattoli.

Disclaimer: non lavoro per Cypress, questa non vuole essere un inserto pubblicitario. Ho usato questi prodotti e mi sono piaciuti molto. Penso di fare cosa gradita presentandoli a chi magari ancora non li conosce.

I microcontrollori e i loro dolori

Avendo a che fare professionalmente con i microcontroller e i loro ambienti di sviluppo, qual è la cosa che più mi scoraggia quando devo cominciare un nuovo progetto? È la configurazione dell'ambiente di sviluppo per lavorare con il microcontroller che ho scelto. È lo studio di quale registro fa cosa o di come è strutturata l'API. È il capire come funziona il bootloader. È l'inizializzazione del micro.

In sostanza, non è la scrittura del codice. Una volta che tutto è impostato, dirgli di fare quello che deve fare è facile.

Qui entra in scena il grande successo di Arduino. Tutto questo lavoro non c'è. Il problema è che non ci sono anche molte altre cose... non scriverò un articolo su cosa Arduino non fa, ne abbiamo già parlato a sufficienza. Sia semplicemente detto che Arduino per chi lavora nell'industria non è un'opzione. E per chi vuole imparare è una via pericolosa.

Il PSoC4

PSoC4

Parliamo di questa piccola famiglia di microcontroller. PSoC sta per Programmable System on Chip. Quindi un sistema in un chip. Sistema nel senso che non ho solo un microcontroller, ma anche un paio di ADC, DAC, OpAmps, eccetera... Insomma quella che noi digitali chiamiamo paccottiglia analogica per irritare IsidoroKZ. Direte voi "Bella forza... quale micro non ce li ha al giorno d'oggi?". Avete ragione, ma non ce li ha così: oltre ai componenti c'è un sistema di routing simile a quello di una FPGA, così che posso configurare (senza dover collegare pin esterni) uno degli opamp in modo che faccia da inseguitore di tensione collegato all'uscita del DAC e (per qualche motivo mio strano) riportarne l'uscita ad un ingresso dell'ADC. Decisamente interessante!

Il tutto ruota attorno ad un Cortex-M0, quindi un ottimo core, non roba del basso mesozoico.

Ma la vera forza è forse l'ambiente di sviluppo, che rende il tutto molto piacevole da usare.

Per inciso, non è una novità dell'ultima ora, TardoFreak già li aveva citati qui http://www.electroyou.it/forum/viewtopic.php?f=15&t=25653 una mezza eternità fa, ma forse l'argomento è passato un po' in sordina.

PSoC Creator

In questo capitolo voglio mostrarvi perché ritengo che l'ambiente di sviluppo sia una piccola perla.

Pins

Il primo tipo di PITA (Pain In The A... Armpit) con un sistema normale è assegnare i pins. Spesso le funzioni sono fisse, quindi l'interfaccia SPI è lì dov'è e non si sposta. Quando c'è la possibilità di scegliere, le scelte sono limitate e vanno fatte cercando prima nel datasheet dove posso mettere quale funzione e poi scavando nelle 500 pagine dell'Hardware Reference Manual per scoprire quale multiplexer va impostato usando quale registro e con che valore. Ovviamente non avendo letto tutte le 500 pagine butteremo via mezza giornata facendo debugging, fino ad accorgerci che dobbiamo prima attivare il clock per quel domain e poi settare il mux.

Con il PSoC Creator il tutto prende questo aspetto (l'immagine è un po' piccola per non appestare l'articolo, spero si capisca):

Gestione pins

Qui vedo l'outline del chip e i relativi pins. A sinistra c'è una lista con tutti i pin che uso (come li genero lo vediamo piú avanti). Con il drop-down menu decido dove metterli. Easy as that! La seconda buona notizia è che c'è un multiplexer colossale: posso mettere tutto dappertutto (con poche eccezioni, come i pins per il bootloader e, evidentemente, l'alimentazione).

Volete un pin come driver CMOS, un altro come open-drain, il terzo come open-drain invertito e il quarto come pull-up? Buona ricerca nelle 500 pagine. Oppure, qui, doppio click e posso scegliere queste impostazioni, assieme allo stato che dovrà avere il pin dopo il power-on reset e tutte le altre amenità del caso.

Blocchi (ana)logici

Su un'altra schermata posso decidere quali periferie mi servono:

Blocchi instanziati nel PSoC

Qui ho un'UART, il bootloader per poter caricare la firmware via UART, un IDAC che va con l'uscita su un pin e un GPIO. Se serve un altro blocco basta sceglierlo dall'elenco e depositarlo sulla superficie di lavoro. Facendo doppio-click si apre la configurazione dell'elemento. Diamo un'occhiata all'UART:

Configurazione dell'UART

Nella cartella Basic ci solo le solite banalità: baudrate, parità & co. Qui, in Advanced ci sono le cose piú interessanti. Come vedete si possono per esempio selezionare quali interrupt sono da attivare (ovviamente si può poi modificare al runtime) o assegnare un canale DMA (dov'è nelle 500 pagine?). La cosa che veramente vale oro è quel tasto in basso a sinistra: se lo si clicca si apre il datasheet per questa entità (una decina di pagine, non 500), dove sono spiegate nei dettagli tutte le possibili impostazioni.

API automatica

Non abbiamo ancora scritto una linea di codice. È ora di cominciare a pensarci. Normalmente avremmo adesso un altro tipo di PITA: cercare di capire quale fosse la lingua madre del programmatore in base agli errori di inglese che ci sono nella documentazione Doxygen dell'API. Qui la documentazione per l'API si trova nel datasheet del relativo componente di cui sopra.

Ah, non bisogna linkarla al progetto, avviene automaticamente.

Un'altra cosa interessante: quando instanzio un'UART posso chiamarla come mi pare. Per esempio "USB_to_UART_bridge" o "Pippo". Quando clicco su Build, PSoC Creator crea al volo una nuova API in cui le funzioni per l'UART portano come prefisso il nome che ho scelto (cosa molto comoda quando parliamo di pins GPIO). Nel nostro caso concreto avremmo la funzione Pippo_UartGetByte().

Un progetto concreto

Abbiamo impostato l'hardware, adesso scriviamo un po' di codice. Voglio poter impostare la corrente che scorre attraverso un LED tramite un comando ricevuto via UART. L'UART l'abbiamo istanziata. L'IDAC genererà il segnale in uscita, che con un po' di paccottiglia analogica esterna amplificherò adeguatamente. Il GPIO serve a spegnere completamente il LED quando non serve (l'OpAmp esterno che uso ha ovviamente un po' di offset e non mi spegne completamente il mosfet). Qui uno schema semplificato di quello che succede esternamente al PSoC:

Sorgente FidoCadJ | Ingrandisci | Cos'è Fidocad

L'amplificazione in corrente è data tra il rapporto della resistenza di carico dell'IDAC e di quella di shunt sotto al LED. Quando attivo il pin shutdown, l'uscita dell'opamp diventa ad alta impedenza e il pull-up porta il gate del PMOS a 9V portando la corrente attraverso il LED a (quasi) zero.

Il codice

Questo è il codice che ho scritto:

void main(){
    IDAC8_Start();

    UART_1_Start();
    UART_1_Init();
    UART_1_Enable();

    IDAC8_SetValue(0x00);

    for(;;)
    {
        uint32 newByte = UART_1_UartGetByte();

        if (((newByte & 0xFFFFFFF0)) != UART_1_UART_RX_UNDERFLOW)
        {
            if (newByte & 0x80)
            {
                SHDN_Write(0x00);
                UART_1_UartPutChar(0x31);
            }
            else
            {
                SHDN_Write(0x01);
                UART_1_UartPutChar(0x30);
            }

            IDAC8_SetValue(newByte & 0x7F);
        }
    }
}

Nulla di meno, ma soprattutto nulla di piú! Tutto il resto è generato, incluso e linkato in automatico.

Credo sia abbastanza chiaro: nelle prime righe inizializzo le componenti. Come vedete non devo passare argomenti perché ho fatto tutto prima, con il tool grafico. Poi passo il valore 0 all'IDAC per essere sicuro di non aver nulla in uscita (e comunque... lo shutdown è attivo perché ho configurato il pin di conseguenza). Quello che segue è un loop infinito nel quale cerco di leggere un carattere dalla UART. Se non ottengo un errore di buffer underrun, vuol dire che c'era effettivamente qualcosa da leggere. Ne prendo il MSB e lo uso per pilotare lo shutdown. I restanti 7 bit sono quelli che vanno diritti diritti nell'IDAC. Fine della storia.

Qualcuno potrebbe obbiettare che è poco efficiente. Che dovrei mettere il core in sleep e aspettare che un interrupt sull'UART lo svegli. E avrebbe ragione. Ma visto che qui stiamo pompando fino a 1.5 A attraverso un LED di potenza, mi arrogo il diritto di fregarmene di quel paio di uA che risparmierei...

Ed ecco qui che tutto funziona.

Driver di potenza lineare per LED

In questa foto (di qualità discutibile) si vede il tutto assemblato alla buona. Sopra la scheda di sviluppo del PSoC4, sotto la parte analogica e di potenza, a sinistra l'alimentazione. Sullo sfondo il terminale con il quale mando i comandi via porta seriale. E attaccato alla morsa con un po' di nastro adesivo un LED, nel quale al momento scorrono 1.2 mA.

Sento un'altra obbiezione: che spreco... un'intera development board per un'applicazione così banale! Signore e signori... la development board costa l'incredibile somma di tre-dollari-e-novantanove... ripeto, tre-dollari-e-novantanove.

Conclusione

Questi PSoC (che ci sono anche in altre versioni, per esempio il PSoC5, con un Cortex-M3 e un'enormità di blocchi analogici) mi sembrano una cosa molto comoda. Questo driver per LED che ho montato non è un gioco. Mi serve per lavoro. Ci ho messo in tutto un paio d'ore (compresa l'installazione dell'ambiente di sviluppo e capire come si usa). È un notevole risparmio di tempo e il prezzo è ridicolo.

Capisco benissimo il fatto che un hobbysta o qualcuno che programma per la prima volta un micro si senta scoraggiato davanti all'ambiente di sviluppo e davanti ad una mole di documentazione impressionante. Questo sistema risolve il problema, rendendo il primo passo accessibile a tutti. E ciononostante è un prodotto vero, programmabile in C con un HAL, dove si possono pilotare i GPIO usando delle maschere e non solo chiamando la funzione ACCENDI_LED.

Insomma una bella cosa per professionista e principiante, ma purtroppo sembrerebbe mancare una campagna di marketing in questo senso.