La forza delle periferiche indipendenti: risparmio energetico e real time

Le Core Independent Peripherals (CIPs) sono periferiche autonome, interconnesse ed intelligenti. Grazie alle CIPs il microcontroller non necessita di interazione con la CPU (Central Processing Unit) per l’esecuzione dei task. Ciò corrisponde ad una serie di vantaggi a favore dell’applicazione.

Il primo è che non è necessaria la CPU per la comunicazione tra le periferiche. Il core può entrare in modalità Sleep ed il il flusso del software non ha bisogno di essere interrotto. Ovviamente, se il core resta in Sleep ed il software non è necessario, allora il consumo di corrente dell’applicazione sarà ridotto. Poiché la CPU è la parte del microcontroller con il più elevato consumo di corrente, l’utilizzo di CIPs riduce il consumo di energia.

Il secondo vantaggio è che le CIPs non causano interruzioni, il che consente comunicazioni complessivamente più veloci.  Se il core della CPU sta eseguendo del software e deve essere interrotto dalle periferiche per l’esecuzione di altre specifiche azioni, questo assorbirà parecchio tempo. Una interruzione richiede tre cicli di clock oltre a due cicli di clock per il relativo jump e potrebbe utilizzare diversi cicli per il context switch, al fine di salvare i dati nei registri sullo stack, a seconda dell’applicazione. Le CIPs, quindi, consentono comunicazioni molto più veloci rispetto al caso in cui il core debba subire interruzioni.

Terzo, l’utilizzo di CIPs si traduce in un più rapido time-to-market. Inoltre, è richiesta la scrittura di una minore quantità di software dato che l’hardware può eseguire compiti autonomamente. Questo riduce il rischio di errori software e richiede una minore validazione del software stesso. Di conseguenza, il tempo di sviluppo di un prodotto è inferiore rispetto al caso di non utilizzo di CIPs.

Nei microcontroller (MCU) AVR, tutte le Core Independent Peripherals sono connesse attraverso Event System. Nell’Event System, un multiplexer connette gli event generator e gli event user. Ci sono event sincroni e asincroni. Gli event sincroni richiedono meno di un ciclo di clock mentre gli event sincroni richiedono due cicli di clock.

Molte periferiche possono essere connesse ad un event system come CIPs. Ci sono timer, cioè Real Time Counter (RTC), Periodic Interrupt Timer (PIT), le Custom Configurable Logic (CCL), Analog Comparator (AC), Analog-to-Digital Converter (ADC), Universal Synchronous/Asynchronous Receiver/Transmitter (USART), e General Purpose Input/Outputs (GPIOS).

UTILIZZO DELLE CORE INDIPENDENT PERIPHERALS

Le Core Independent Peripherals richiedono una configurazione iniziale prima del loro utilizzo. La CPU esegue le istruzioni per la corretta inizializzazione dell’Event System e periferiche richieste.

Delay/Debouncing

Oggigiorno, svariate applicazioni utilizzano un pulsante quale input. Per ogni pulsante è necessaria una logica di debounce o una parte di software per ottenere un segnale non-toggling. Per gli MCU AVR il debouncing è un compito facile da eseguire come software. Può essere fatto da delay e/o logica nel programma software. Il software non è complicato ma utilizza risorse della CPU. Se il pulsante è stato premuto o meno può essere verificato sia per polling che via interrupt dal controller GPIO. Entrambi richiedono tempo ed utilizzo della CPU per eseguire l’intero compito di debouncing.

Debouncing/Delay con filtro CCL

Figura 1: Filtro del CCL

Con le Core Independent Peripherals, completare la funzione di debouncing può essere fatto senza sovraccarichi aggiuntivi sulla CPU. Tutto ciò che è necessario è una Custom Configurable Logic (CCL). La GPIO, a cui il pulsante è connesso, è configurato come un event generator asincrono. La CCL sarà l’event user. Il segnale verrà trasferito dal pin del GPIO all’input del CCL senza ritardi. La tabella logica nel CCL è configurata in modo tale che l’output sia uguale all’input. L’output della tabella logica viene instradato verso il filtro. Per il filtro del CCL, vedere Figura 1 e Figura 2. È possibile rimuovere i glitch dal segnale di ingresso e impostare il ritardo del filtro da due a cinque cicli di clock (peripheral clock o un alternative clock) per il segnale di uscita. Utilizzando un clock lento, di 32 KHz, otterremo un ritardo di 1,5ms. Ė anche possibile prolungare il ritardo con un clock differente o con un timer.

Delay con un Timer
Per esempio, il Timer/Counter B (TCB) è impostato in modalità “Single-Shot”. Se al timer arriva un event signal questo avvia il conteggio fino al valore massimo programmato, quindi si ferma. L’output del TCB è connesso al CCL. Nel CCL può essere eseguita la desiderata combinazione di segnale di ritardo. Questo consente un tempo di ritardo molto flessibile. Ognuno dei nuovi event verso il timer TCB fa ripartire il conteggio.

Dead Time Generation

Il Dead Time viene utilizzato in applicazioni nelle quali gli switch (transistor, FET o IGBT) risultano in serie tra alimentazione e terra (GND). Se entrambi vengono attivati contemporaneamente si verificherà un corto. Un esempio è costituito dalla configurazione H-bridge comunemente utilizzata per i drive di controllo motori. A seconda dell’applicazione, il dead-time sarà tra le commutazioni oppure tra gli impulsi del Pulse-Width Modulation (PWM). Il dead-time tra gli impulsi PWM è necessario, per esempio, nel drive sinusoidale e tra commutazioni nei motori Brushless DC (BLDC) singolo polo. Il dead-time tra impulsi PWM può essere generato con il timer Time Code Display (TCD).

Figura 2: CCL LUT 1 DEAD TIME GENERATION

Figura 3: CCL LUT 0 DEAD TIME GENERATION

Per generare dead-time tra commutazioni sono necessari due timer, Custom Configurable Logic (CCL) e AC. Le Figure 2 e 3 rappresentano la logica della truth table del CCL. Il timer TCA genera il segnale PWM base per il controllo motori. L’AC è collegato esternamente al sensore Hall del motore e collegato internamente tramite l’event system al timer TCB. Il timer TCB genera il segnale di dead-time nel caso riceva un segnale da AC. Il CCL combina segnale AC, TCA (PWM) e TCB (dead-time). I segnali input possono essere selezionati direttamente nella configurazione CCL e non richiedono l’uso di Event System. Questi moduli sono direttamente collegati tra loro. Il CCL genera quindi due PWM, (Figura 4) che pilota le commutazioni per il motore. Quindi il motore gira senza alcun coinvolgimento della CPU. Per maggiori informazioni tecniche è possibile fare riferimento alle AVR Application Note AVR42778.

Figura 4:  Diagramma dei tempi per DEAD TIME GENERATION

Segnale PWM di Spegnimento Automatico

Molte applicazioni richiedono il monitoraggio del consumo di corrente in modo tale che essa non superi un dato livello massimo. Ciò può essere facilmente realizzato con un AC (analog comparator). L’AC misura la tensione (corrente attraverso una resistenza) via shunt register. Se supera una soglia configurata in precedenza, il segnale PWM dovrebbe cessare immediatamente. Entrambi gli esempi seguenti utilizzano Core Independent Peripherals. Il segnale di uscita PWM può essere fermato quando viene rilevata una sovracorrente senza interazione della CPU.

Esempio di illuminazione a LED con TCA e CCL
Il Timer/Contatore A0 genera il PWM per il LED (Light Emitting Diode). L’AC viene utilizzata per rilevare la sovracorrente mentre il CCL viene utilizzato per combinare questi segnali, in tal modo se viene rilevata una sovracorrente, il PWM viene automaticamente fermato. L’AC ed il TCA0 sono connessi via Event System al CCL. Il segnale output AC ed il PWM sono configurati nel TRUTH table del CCL, (Figura 5).  

Il segnale PWM è alimentato se l’event signal si forma in modo tale che l’AC sia zero. Se viene rilevata una sovracorrente, l’event signal CA è uno e l’uscita è zero finché sussiste una sovracorrente.

Figura 5:  CCL TRUTH-TABLE FOR FAULT HANDLING

Esempio di Controllo Motori con TCD
Un motore BLDC è controllato dal timer TCD che genera i due canali più due canali supplementari dei segnali PWM per pilotare i quattro MOSFET in un H-bridge. L’AC è utilizzato per rilevare la sovracorrente nel motore con uno shunt tra motore e GND. L’AC è collegato tramite Event System al Timer/Counter D0 (TCD). Le funzionalità del TCD comprendono la gestione degli errori. Se viene superata la soglia della corrente alternata (sovracorrente rilevata), viene segnalato un evento al TCD e i PWM vengono arrestati automaticamente.

Misurazione del Time-Of-Flight

La misurazione del Time-Of-Flight viene utilizzata per misurare la distanza percorsa da un segnale.                 La misurazione inizia quando il segnale lascia il ricetrasmettitore e si arresta quando viene rilevato dal ricevitore.  La distanza può essere calcolata rilevandola dal tempo e dal valore noto in m/s del segnale. Nell’esempio seguente stiamo misurando la distanza con il segnale ultrasonico.  Per questo abbiamo bisogno delle Core Independent Peripherals TCA0, TCB0, TCS0, AC e 2x CCL e possiamo calcolare il Time-Of-Flight senza l’utilizzo della CPU.

Figura 6: Misurazione ultrasonica del TIME OF FLIGHT

La Figura 6 mostra la look up Table 1 (LUT1) generata dal Segnale Trasmesso. TCA Out genera il segnale PWM e TCD Out B è la maschera di trasmissione. La maschera di trasmissione invertita e il PWM sono logiche AND combinate e quindi generano il segnale di trasmissione, che è mostrato dalla truth table di LUT1.

LUT0 genera il segnale invertito. AC Out fornisce l’attività sulla linea di ricezione e TCD Out A è la maschera di ricezione. La maschera di ricezione invertita e la “linea di ricezione” sono logiche AND combinate che generano il segnale invertito, che è mostrato dalla truth table di LUT0.

Il latch SR viene ripristinato con il primo segnale trasmesso e avvia il contatore in TCD. Con il segnale derivante dal segnale riflesso e quando il latch SR è impostato, il contatore TCD viene arrestato.                            Il Time-Of-Flight è ora memorizzato nel valore del contatore del TCD senza alcun utilizzo della CPU.

La CPU è necessaria solo per il calcolo della distanza in cui il Time-Of-Flight viene moltiplicato con la velocità del segnale. Per ulteriori informazioni tecniche sulla misurazione della distanza ultrasonica, consultare la nota applicativa AVR Application Note AVR42779.

Conclusioni

La nuova serie di microcontroller ATtiny1617 / 1616 / 1614 /817 /   816 / 814 / 417 di Microchip aggiunge innovative Core Independent Peripherals (CIPs) alla famiglia di microcontroller tinyAVR.                             Con le CIP, un’applicazione può reagire in tempo reale, e con un sovraccarico software inferiore e un consumo di corrente anch’esso inferiore rispetto al non utilizzo delle CIPs. Questi esempi mostrano che le CIPs sono facili da configurare e che le prestazioni in tempo reale sono superiori e richiedono meno consumo di energia rispetto alle soluzioni basate su software. Anche col microcontroller dalle prestazioni molto più elevate, non è sempre possibile raggiungere questo livello di performance in tempo reale e, anche dove fosse possibile, il consumo di energia sarebbe di molto superiore.

A cura di Gregor Sunderdiek, Business Development Manager MCU8 EMEA, Microchip Technology Inc.

Bibliografia
Ulteriori informazioni sulla nuova famiglia tinyAVR:   
–     AVR ATtiny817 webpage
–     AVR42778 Application Note: Core Independent Brushless DC Fan Control Using Configurable Custom Logic on ATtiny817
–     AVR42779 Application Note: Core Independent Ultrasonic Distance Measurement with ATtiny817