Core Arm, identici ma non troppo

Sono molti i fattori alla base del continuo aumento della domanda di core della serie Cortex-M di Arm che si apprestano a divenire i protagonisti indiscussi nel mercato dei microcontrollori a 32 bit. Tra le molte versioni di core Arm Cortex-M disponibili, i progettisti possono scegliere tra una gamma estremamente ampia di caratteristiche, livelli di prestazioni, consumi e funzioni di comunicazione che permette loro di reperire una Mcu con core Arm in grado virtualmente di soddisfare qualsiasi esigenza applicativa. Grazie alla standardizzazione sulla famiglia di core Cortex-M, gli Oem possono sfruttare i vantaggi derivati da un set di istruzioni comune e dalla disponibilità di un ecosistema completo di librerie, tool e firmware con il quale migliaia di progettisti di sistemi embedded hanno acquisito una grande familiarità. Un’altra ragione che viene solitamente riportata per promuovere l’utilizzo di Mcu basate su un core Arm Cortex-M è la portabilità del codice: il set di istruzioni comune per i core Cortex-M e lo standard di interfaccia Cmsis (Cortex microcontroller software interface standard) sono due importanti elementi della strategia messa a punto da Arm finalizzata ad assicurare i progettisti operanti nel mondo embedded circa la possibilità di eseguire il porting del codice sviluppato per una Mcu basata su Arm su un’altra Mcu senza richiedere modifiche sostanziali. In una situazione tipica, un Oem potrebbe avere la necessità di aggiornare un prodotto esistente mediante l’aggiunta di ulteriori funzionalità che richiedono nuove periferiche, per esempio un controllore per il rilevamento tattile o un controllore per Lcd, che non sono supportate dalla Mcu del prodotto attuale. Ciò potrebbe richiedere il passaggio da un controllore basato su Cortex-M3 a una Mcu differente, anch’essa basata su un core Cortex-M3. I progettisti potrebbero quindi ipotizzare che il firmware e il codice applicativo che gira sul primo dispositivo girerà senza problemi anche sul secondo. Dopotutto entrambi i core sono chiamati Arm Cortex-M3, ragion per cui dovrebbe trattarsi di due dispositivi identici. Allo stesso modo, un progettista che ha sviluppato un sistema utilizzando un core Arm Cortex-M0+ è perfettamente consapevole delle potenzialità, delle prestazioni e delle caratteristiche di questo core. Il progettista è quindi portato a ipotizzare di poter utilizzare una Mcu di qualsiasi fornitore dotata di un core Arm Cortex-M0+ per un nuovo progetto, confidando nel fatto che la Cpu garantisca le medesime potenzialità, prestazioni e caratteristiche. Queste ipotesi, sfortunatamente, non sono sempre completamente valide.

Non un singolo core ma una piattaforma

L’etichetta Arm Cortex-M3 non si riferisce a un componente hardware unico e riproducibile, ma è una convenzione di denominazione. Arm attribuisce l’etichetta Cortex-M3 a un gruppo di elementi di proprietà intellettuale che ciascun licenziatario può configurare individualmente per l’utilizzo nelle varie versioni di ogni Mcu che produce. Ovviamente sussistono vincoli severi relativamente al numero e all’entità delle modifiche che un licenziatario può apportare: la struttura del core è per la maggior parte stabilita da Arm. Tuttavia, è meglio non pensare a un Cortex-M3 come a un singolo core, ma come a una piattaforma IP sulla quale ciascun produttore di Mcu realizza il proprio hardware che quindi è unico. In base a queste considerazioni, appare importante comprendere fin dalle fasi iniziali della progettazione l’influenza che le differenze nella configurazione del core avranno sulle prestazioni dell’applicazione. La scelta del progettista non è limitata a un numero ristretto di core Arm Cortex-M, ma coinvolge centinaia di permutazioni delle configurazioni del core. Quando si effettua una scelta di questi tipo, una consulenza da parte di uno specialista che ha seguito i corsi organizzati da Arm, che opera presso un distributore o un fornitore di servizi può rappresentare un valido aiuto.

Le differenze tra i core Cortex-M

Di seguito vengono analizzate alcune delle differenze a livello di implementazione dei vari core relative alle attuali Mcu basate su Cortex-M.

• Bus Axi - Il core Arm Cortex M7 prevede il bus Axi per le comunicazioni punto-punto a 64 bit tra i blocchi di memoria e il processore. Alcune istanze del core Arm Cortex-M7, invece, connettono risorse di memoria con il processore attraverso un bus esterno e non mediante il bus Axi.
• Floating Point Unit- I core Arm Cortex-M4 e Arm Cortex-M7 possono o meno includere una Floating Point Unit: si tratta di una decisione presa dal licenziatario dell Mcu. Nel core Arm Cortex-M7 la Fpu potrebbe essere del tipo a precisione singola o doppia: anche in questo caso la scelta è fatta dal produttore della Mcu.
• Wake-up Interrupt Controller - Si tratta di una funzionalità interessante per la riduzione dei consumi resa disponibile da Arm su tutti i core della serie Cortex-M. Essa permette a un core di essere “svegliato” dallo stato di “deep sleep” quando un segnale su un pin esterno dedicato lo fa passare dallo stato logico basso (Low) allo stato logico alto (High). Il controllore Wic non necessita di clock e permette di risparmiare il 99% della potenza consumata dal core durante il funzionamento normale. Anche se si tratta di una caratteristica di assoluto rilievo, non è prevista su alcune Mcu basate sul core Arm Cortex-M. Il produttore dell’Mcu può decidere di non implementare il controllore Wic, ottenendo una modesta riduzione in termini di costi e dimensioni del chip, oltre che di consumi nel funzionamento in modalità normale. Benché si tratta di una caratteristica standard dei core Arm Cortex-M, gli utenti devono perdere tempo a leggere attentamente il datasheet del dispositivo scelto per accertarsi che quest’ultimo integri tale funzionalità.
• Memory Protection Unit - Il suo compito è proteggere le aree di memoria da sovrascritture da parte di task che non dispongono di privilegi. Un’unità di questo tipo può essere implementata in qualsiasi core delle serie Cortex-M ad eccezione dei core Cortex-M0. A discrezione del produttore della Mcu, comunque, può essere eliminata per far posto ad altre funzionalità.
• Micro Trace Buffer - Questa caratteristica del core Cortex-M0 aiuta gli sviluppatori a effettuare il debug dell’applicazione nel caso si verifichi un “hard fault”, ovvero un guasto stabile e continuo nel tempo, durante l’esecuzione. Un produttore di Mcu può comunque decidere di ometterla. Allo stesso modo Etm (Embedded trace macrocell) fornisce una visualizzazione completa dei dati e degli indirizzi durante l’esecuzione e mette a disposizione un’interfaccia ad alta velocità per un debugger esterno. Al suo posto può invece essere implementata un’interfaccia per debug standard come Swd o Jtag.
• Priorità degli interrupt - Nei core Cortex-M3, M4 ed M7 è previsto un numero di interrupt compreso tra 8 e 256 e il numero di priorità degli interrupt supportato è scelto ogni volta che un produttore di Mcu sviluppa un nuovo prodotto o una nuova versione di un prodotto esistente. Un’applicazione particolarmente complessa che gira su un core Cortex-M7 con 256 livelli di priorità degli interrupt potrebbe incontrare dei problemi nel momento in cui si effettua il porting su una Mcu differente sempre basata sul core Cortex-M7 che supporta solamente 16 livelli.

Una scelta accurata del core

Quelli riportati sono alcuni esempi delle principali opzioni di configurazione tra le quali un produttore può scegliere per ciascuna Mcu che intende implementare. Da quanto esposto si evince l’importanza di effettuare una selezione oculata del core della serie Cortex-M, indipendentemente dalla famiglia di Mcu di un particolare produttore sulla quale è caduta la scelta del progettista.