FreeRTOS con trace in tempo reale su un microcontrollore AVR

FreeRTOS con trace in tempo reale su un microcontrollore AVR

Il trace in tempo reale di un’applicazione in esecuzione su un microcontrollore rappresenta un valore aggiunto significativo, utile non solo per eseguire un debugging accurato, ma anche per verificare il normale funzionamento del sistema. Nell’articolo vedremo come realizzare un’applicazione dimostrativa in grado di tracciare le operazioni svolte dal kernel FreeRTOS su una MCU ATmega4809.

Introduzione

Scopo dell’articolo è la realizzazione di un’applicazione dimostrativa basata sul porting del kernel real time FreeRTOS su un microcontrollore ATmega4809 appartenente alla famiglia AVR. L’obiettivo è quello di tracciare l’esecuzione del codice, in particolare i cambi di contesto (context switch) operati dallo scheduler sui task configurati nel sistema, utilizzando opportuni strumenti software. Sarà inoltre possibile verificare il tempo di risposta della CPU anche in condizioni di carico pari al 100%. Come vedremo in dettaglio più avanti, il trace eseguito su linea seriale ha comunque un impatto non trascurabile sul processing della CPU, anche se questo aspetto è il più delle volte ritenuto trascurabile rispetto ai significativi vantaggi che la funzionalità di trace è in grado di offrire.

FreeRTOS

FreeRTOS non ha certo bisogno di presentazioni. Si tratta, infatti, di un kernel real time tra i più diffusi a livello mondiale, con milioni di installazioni in tutti i principali settori di mercato. Attualmente FreeRTOS può contare su oltre venticinque porting per diverse architetture hardware, a cui devono aggiungersi le versioni non ufficiali sviluppate da gruppi di utenti. Le principali caratteristiche di FreeRTOS possono essere così sintetizzate:

  • progetto open source sviluppato in collaborazione con i principali produttori di microcontrollori e microprocessori;
  • portabilità: ad eccezione di alcune piccole parti di codice dipendenti dalla specifica architettura, il software è comune alle diverse piattaforme hardware;
  • non richiede alcuna licenza di utilizzo. In particolare, FreeRTOS è distribuito in accordo a una licenza GNU GPL modificata che non prevede il rilascio del codice sorgente delle applicazioni basate su di esso;
  • il footprint è particolarmente ridotto, consentendo l’installazione sui sistemi embedded, notoriamente caratterizzati da risorse di memoria limitate.

È importante sottolineare come FreeRTOS (di cui in Figura 1 possiamo osservare il logo) sia esclusivamente un kernel, non un sistema operativo real time completo. Il kernel include tutti i meccanismi che governano la creazione, distruzione e attivazione dei task, la sincronizzazione e la comunicazione tra i processi (nota anche con il termine IPC, acronimo di Inter Process Communication), la gestione degli eventi e degli interrupt. Tutto ciò che sta al di fuori del kernel (driver di periferica, file system e programmi di utilità) dovranno essere forniti da terze parti o sviluppati in proprio (magari partendo da progetti open source già disponibili in rete).

Figura 1: Il classico logo del progetto FreeRTOS

Un’altra caratteristica peculiare di FreeRTOS è quella di essere espressamente nato come kernel mono core: un solo task può essere, di volta in volta, messo in esecuzione dallo scheduler. Altri meccanismi implementati in FreeRTOS sono la preemption, direttamente legata al concetto di priorità dei task e i livelli di priorità associati agli interrupt. Dal punto di vista software, FreeRTOS nasce come un sistema completamente configurabile. Le impostazioni sono infatti tutte contenute all’interno di un unico file header (FreeRTOSConfig.h) e ogni modifica apportata allo stesso consente di personalizzare alcuni parametri (come ad esempio il tick di sistema, i livelli di priorità, la dimensione delle code di messaggi) oppure abilitare o disabilitare determinate funzionalità. A seguito della compilazione dei file sorgenti e del file di configurazione, viene prodotto l’output a livello software, generalmente sotto forma di libreria statica. In Figura 2 possiamo osservare l’estratto di un tipico file di configurazione di FreeRTOS.

Figura 2: Tipico aspetto del file di configurazione di FreeRTOS

In FreeRTOS esiste sempre un task, il task Idle, caratterizzato dal livello di priorità più basso. Tale task viene schedulato quando nessun altro task è pronto per essere messo in esecuzione. L’attivazione e disattivazione dei task, con conseguente cambio di contesto operativo (context switch), viene decisa dallo scheduler. Lo scheduler non è un task, ma bensì un interrupt handler attivato in corrispondenza di ogni tick del clock hardware (ad esempio, ogni 10 ms, a seconda di come è configurato il sistema). La lista dei task viene aggiornata in base alla priorità (i task con priorità più alta hanno la precedenza) oppure, per i task a pari priorità, seguendo una politica di round robin. A titolo di cronaca ricordiamo che da qualche tempo il progetto FreeRTOS è entrato a far parte del progetto open source AWS (Amazon Web Services) ed è quindi disponibile, sotto licenza MIT, la versione Amazon FreeRTOS basata sul kernel FreeRTOS Ver. 10.

ATmega4809

I microcontrollori della serie megaAVR di Microchip si dimostrano particolarmente adatti alle applicazioni di controllo in tempo reale, in virtù di un sapiente mix tra periferiche hardware intelligenti e bassi assorbimenti di potenza. L’ATmega4809 dispone di un convertitore analogico digitale (ADC) ad elevata velocità e di un insieme di periferiche in grado di operare autonomamente rispetto alla CPU (CPI). Tutte queste caratteristiche fanno del microcontrollore la soluzione ideale per le applicazioni in cui comportamento deterministico, bassa latenza e capacità di elaborare velocemente segnali analogici sono requisiti imprescindibili. La serie di microcontrollori megaAVR (di cui in Figura 3 possiamo osservare alcune tipiche applicazioni) può essere utilizzata sia combinata con processori di fascia alta nelle applicazioni di controllo più complesse, sia in modalità stand alone nei classici sistemi di controllo. L’architettura delle MCU megaAVR è la stessa impiegata nei dispositivi appartenenti alle serie tinyAVR, con l’aggiunta di una maggior quantità di memoria. Con fino a 48 kB di memoria flash, in contenitore a 28, 32 o 48 pin, i dispositivi megaAVR sono in grado di soddisfare i requisiti di un’ampia gamma di applicazioni.

Figura 3: Il microcontrollore ATmega4809

Le principali caratteristiche tecniche dell’ATmega4809 sono le seguenti:

  • core CPU AVR a 8 bit con moltiplicatore hardware integrato
  • oscillatore interno a 20 MHz
  • fino a 48 kB di memoria flash
  • ADC veloce a 16 canali con risoluzione di 10 bit
  • circuito comparatore analogico con ingresso di riferimento scalabile
  • tensione di riferimento configurabile, generata internamente
  • scansione automatica della memoria con controllo del CRC
  • Real Time Clock (RTC) a 16 bit
  • interfacce di comunicazione I2C, SPI e UART
  • periferiche CCL (Configurable Custom Logic) mediante le quali realizzare reti di controllo combinatorie o sequenziali
  • sistema di gestione degli eventi a 6 canali
  • fino a 41 GPIO
  • tensione di alimentazione compresa tra 1,8V e 5,5V
  • range di temperatura da -40°C a +125°C

Le più moderne applicazioni di controllo richiedono dei microcontrollori efficienti, affidabili e in grado di erogare delle elevate prestazioni. La serie di microcontrollori megaAVR, non solo presenta queste caratteristiche, ma dispone di una CPU e di un insieme di periferiche in grado di ridurre drasticamente i tempi di risposta, il footprint sul PCB, oltre ai tempi richiesti dallo sviluppo e dalla validazione dell’applicazione. Come visibile nello schema a blocchi di Figura 4, un primo modulo significativo è rappresentato dal convertitore analogico digitale ad elevata velocità (fino a 150000 campioni al secondo) e risoluzione su 10 bit. Questo componente garantisce un’acquisizione accurata e regolare del segnale analogico, interfacciandosi direttamente con altre periferiche senza richiedere l’intervento da parte della CPU. Un altro modulo importante per conseguire dei tempi di risposta molto bassi è rappresentato dal gestore degli eventi.

Una matrice di collegamenti realizzata a livello hardware permette alle periferiche della serie di microcontrollori megaAVR di comunicare tra loro senza coinvolgere la CPU. Questa funzionalità permette di ridurre gli assorbimenti di potenza e aumenta il determinismo nei loop di controllo. Inoltre, il sistema di gestione degli eventi può essere facilmente configurato tramite degli opportuni strumenti software forniti da Microchip, aiutando a ridurre i tempi di validazione del sistema. Il set di periferiche “intelligenti” è completato dall’unità CCL (Configurable Control Logic), un modulo integrato ad elevata configurabilità utilizzabile per svolgere svariate funzioni (dalla semplice inversione di polarità di un segnale digitale fino all’implementazione di complesse sequenze di eventi).

Figura 4: Schema a blocchi della MCU ATmega 4809

L’hardware

A livello hardware il setup dell’applicazione richiede le seguenti due componenti:

  • la scheda di sviluppo ATmega 4809 Xplained Pro, visibile in Figura 5
  • la scheda di espansione display OLED1 Xplained Pro, visibile in Figura 6

Figura 5: L’evaluation board ATmega Xplained Pro

Figura 6: La scheda di espansione con display OLED

L’ATmega Explained Pro è una piattaforma hardware nata per supportare e agevolare lo sviluppo sul microcontrollore ATmega4809. La scheda consente un facile accesso a tutte le funzionalità del microcontrollore, semplificando la fase di integrazione del dispositivo in un progetto custom. Grazie alla presenza di un circuito per la programmazione e il debug integrato (EDBG), la board non necessita di alcun componente esterno ed è supportata dall’ambiente di sviluppo Atmel Studio. Per applicazioni particolari sono inoltre disponibili dei kit di espansione (come il display oled qui utilizzato) che ampliano la piattaforma aggiungendo nuove funzionalità hardware. Come visibile in Figura 7, la scheda è dotata di:

  • 3 connettori di espansione
  • alimentazione selezionabile tra 3,3V e 5V (quest’ultima tramite USB o alimentatore esterno)
  • connettore UDPI (Unified Program and Debug Interface) a 10 pin
  • connettore mikroBUS (utilizzabile con i moduli di MikroElektronika)
  • predisposizione per il montaggio di un dispositivo CryptoAuthentication con package UDFN8

Figura 7: Dettaglio della scheda ATmega4809 Explained Pro

Il Debugger Embedded Integrato (EDBG) dispone di tre interfacce: USB, porta virtuale COM e interfaccia DGI (Digital Gateway Interface). La porta virtuale COM è collegata a un’interfaccia UART dell’ATmega4809 e consente di interagire con l’applicazione target tramite un comune emulatore di terminale. DGI comprende invece diverse interfacce fisiche per la comunicazione bidirezionale con il computer host. Come vedremo meglio più avanti, per inviare e ricevere dati sul canale DGI verrà utilizzato lo strumento software Data Visualizer. La funzionalità CryptoAuthentication serve a verificare ed a riconoscere tramite un identificativo univoco tutte le schede collegate, in modo da evitare possibili contraffazioni, clonazioni o manomissioni delle parti hardware. OLED1 Xplained Pro è invece una scheda di espansione dotata di un display oled con interfaccia SPI e risoluzione di 128x32 pixel, tre led e tre pulsanti.

Gli strumenti software

La componente software del progetto si avvale dei seguenti due pacchetti:

  • l’utilità Data Visualizer, utilizzabile sia come parte integrante dello strumento di sviluppo Atmel Studio, sia nella modalità stand alone;
  • lo strumento Percepio Tracealyser configurato per FreeRTOS.

Atmel Studio è una piattaforma integrata per lo sviluppo e il debug di applicazioni basate sui microcontrollori della serie AVR e SAM. Data Visualizer, di cui in Figura 8 possiamo osservare uno screenshot rappresentativo, è un programma per processare e visualizzare dati acquisiti da un'interfaccia. I dati possono essere ricevuti tramite diversi tipi di interfacce, come il DGI (Data Gateway Interface, disponibile su interfacce fisiche SPI, I2C e UART) e la classica porta COM seriale. L’interfaccia DGI consente inoltre di effettuare il monitoraggio dei GPIO, la misura degli assorbimenti e la profilatura del codice.

[...]

ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2820 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend