Il multicontrollore Propeller è un dispositivo della Parallax inc. contenente otto processori RISC a 32 bit e può gestire direttamente un’uscita video VGA, videocomposito, una tastiera, un mouse. Ben otto processori RISC a 32 bit indipendenti, tutti uguali, sincronizzati dallo stesso clock che può arrivare alla frequenza massima di 80MHz. Gli otto processori, chiamati COG, condividono le risorse comuni del Propeller quali registri di I/O e timer, mentre l’accesso alla memoria RAM/ROM avviene tramite un HUB che sincronizza le richieste dei singoli COG. Per questo motivo, per definire il Propeller, è più appropriato il termine multicontrollore.
Introduzione
I vantaggi di questa architettura sono molteplici. L’assenza di vincoli o di strutture predefinite lascia ampio spazio al progettista che può costruire l’applicazione con la massima libertà. Al vostro nuovo progetto serve una porta di comunicazione seriale? Si può dedicare un COG alla gestione della comunicazione ed utilizzare due pin di I/O qualsiasi per le linee seriali. Dovete aggiungere una seconda seriale? Un secondo COG può eseguire lo stesso codice (non una copia!), utilizzando altri pin di I/O. Questi esempi, se pur banali, rendono perfettamente l’idea di come in un sistema che prevede l’utilizzo di diversi microcontrollori, ognuno dedicato ad una particolare funzione, si possa ridurre drasticamente la complessità utilizzando un solo Propeller suddividendo la funzioni tra gli otto COG, utilizzando la RAM dell’HUB per la condivisione dei dati.
L’ARCHITETTURA DEL PROPELLER
L’architettura del Propeller è riportata in figura 1. Gli otto COG condividono i registri di I/O digitale e il system counter. Ricevono lo stesso clock di sistema e accedono alle risorse condivise RAM/ROM e configurazione tramite l’HUB.
Figura 1. L’architettura del Propeller con gli otto microcontrollori a 32 bit (COG) nello stesso package. I pin di I/O e il system counter sono periferiche condivise da tutti i COG. L’Hub contiene i registri di configurazione, la memoria condivisa RAM/ROM del Propeller e sincronizza l’accesso alle risorse da parte dei singoli COG
IL COG
Il COG è un processore RISC a 32bit con 2KB di RAM organizzata in 512 registri da 32 byte. La memoria RAM del COG può essere utilizzata indifferentemente sia per memorizzare codice che per memorizzare dati. Gli ultimi 16 registri della memoria sono riservati per i registri di configurazione delle periferiche del COG: due contatori, due PLL, una periferica video e i registri per il controllo degli I/O delle porte digitali. Ogni COG può eseguire codice memorizzato nella RAM interna senza interagire con altri COG oppure accedere al codice condiviso memorizzato nella RAM dell’HUB. Il clock di ogni COG può raggiungere gli 80MHz. Considerando che per eseguire ogni istruzione sono necessari quattro cicli di clock, ogni COG del Propeller può lavorare a 20Mips massimi. Utilizzando tutti gli otto COG alla massima frequenza il Propeller può raggiungere complessivamente 160Mips.
L’HUB
L’HUB coordina l’accesso alle risorse mutuamente esclusive del Propeller da parte dei singoli COG. Il meccanismo di accesso si basa sulla tecnica del round robin: ogni processore periodicamente (ogni due cicli di clock di sistema) può eseguire un accesso esclusivo alle risorse. La tecnica non è ottimizzata perchè i COG ricevono l’abilitazione ad accedere alla memoria esterna anche quando non ne hanno bisogno ritardando invece l’accesso agli altri COG. Questa scelta però semplifica moltissimo la sincronizzazione tra i vari COG e rende il funzionamento deterministico poiché si può calcolare esattamente la latenza minima e massima per l’accesso da parte di un COG alle risorse comuni.
LE RISORSE COMUNI
I pin di input/output
Tutti i pin di I/O sono condivisi tra gli otto COG che possono accedere in ogni istante alle porte del multicontrollore. Ogni COG ha al suo interno i propri registri di configurazione per definire la direzione, input o output, e lo stato, alto o basso, dei singoli pin. La gestione degli ingressi non costituisce un problema poiché tutti i COG accedono solo in lettura ai registri di I/O. Per evitare conflitti nella configurazione e nelle scritture dei registri di uscita si applicano delle regole di composizione per definire lo stato dell’uscita in funzione del valore assegnato da ogni COG. Quando almeno un COG configura un pin di I/O come output il pin diventa un output senza considerare la configurazione degli altri COG. Lo stato di un pin di output si ottiene combinando in OR le definizioni dei singoli COG. Perciò lo stato di un pin di output condiviso sarà alto quando almeno un COG lo configura alto.
Il system clock
Il clock di sistema del Propeller può essere generato in tre modi diversi: tramite un oscillatore RC interno, oppure tramite un oscillatore con quarzo esterno che può essere seguito da un PLL in grado di incrementare la frequenza fino a 16 volte. Il clock di sistema viene fornito direttamente agli otto COG pertanto per raggiungere 80MHz con il PLL abilitato si deve utilizzare un quarzo di 5MHz. L’HUB invece riceve il clock diviso per due e a questa frequenza esegue la scansione degli accesi dei COG alla memoria.
Il system counter
Tra le risorse comuni accessibili da tutti i COG in ogni istante c’è anche il system counter. Si tratta di un contatore a 32 bit incrementato alla frequenza di clock del sistema accessibile solo in lettura. Il system counter non viene mai azzerato e può essere utilizzato per inserire ritardi o temporizzazioni nei processi in esecuzione nei COG.
LE RISORSE CONDIVISE
La memoria RAM/ROM
La memoria inclusa nel Propeller comune a tutti i COG è di 64Kbyte. I primi 32KByte sono occupati da una memoria RAM che può essere utilizzata come memoria condivisa per il codice applicativo, come memoria dati per l’applicazione o come memoria di scambio dati tra gli otto COG. A questo proposito i COG possono utilizzare il registro di lock dell’HUB. Tramite i lock bit si possono creare dei semafori per coordinare l’accesso alle aree comuni e garantire l’integrità dei dati condivisi. I 32KByte superiori dello spazio d’indirizzamento sono occupati da una memoria ROM che contiene il codice di startup, tabelle di funzioni matematiche (Seno, logaritmo anti-logaritmo) e la descrizione di un set di caratteri utilizzabili per la visualizzazione su display grafico. Questa memoria contiene anche l’interprete dello Spin il linguaggio di programmazione del Propeller.
LA PROGRAMMAZIONE DEL PROPELLER
Per programmare un multicontrollore con un’architettura così particolare si deve necessariamente utilizzare l’assembler (o assembly). Solo così si riescono ad ottenere le prestazioni indicate in termini di Mips. In realtà la Parallax ha realizzato lo Spin un ambiente di sviluppo con un linguaggio ad hoc ad alto livello.
Lo Spin
Lo Spin è un linguaggio interpretato (nella ROM del Propeller c’è una copia dell’interprete) simile al basic che però presenta alcune caratteristiche di linguaggi più evoluti come la definizione di oggetti. Non si tratta di un linguaggio ad oggetti vero e proprio ma si possono realizzare dei moduli in cui sono definite le strutture dati, le funzioni pubbliche e l’insieme delle funzioni private scritte sia in linguaggio SPIN che in assembler. Ogni oggetto avrà la sua interfaccia pubblica e può a sua volta includere altri oggetti. La definizione degli oggetti è uno dei punti di forza dello Spin poiché è possibile creare dei moduli per le funzioni base riutilizzabili facilmente in nuovi progetti. La stessa Parallax per incoraggiare la condivisione dei vari moduli ha creato un’area apposita nel proprio sito: il Propeller Object Exchange. Nell’IDE di sviluppo ci sono delle funzioni particolari per facilitare lo scambio e la condivisione dei moduli. Ad esempio, grazie ad un font true type, appositamente sviluppato dalla Parallax, è possibile aggiungere al listato del codice dei commenti con disegni e piccoli schemi hardware. In questo modo si può integrare la documentazione completa nel listato del codice. Tramite un’opzione dell’IDE è possibile generare un file zip che include tutto il progetto attuale e una copia dell’IDE stesso evitando così eventuali problemi di compatibilità tra versioni differenti del sistema di sviluppo.
LA PROCEDURA DI STARTUP
Per utilizzare il multicontroller Propeller sono necessari pochi componenti esterni: un quarzo, solo se non si vuole utilizzare l’oscillatore RC interno, e una memoria eeprom da 32Kbyte con porta IIC per memorizzare il codice applicativo (figura 2).
Figura 2. Lo schema minimo necessario per utilizzare il Propeller. Il quarzo è opzionale poiché il Propeller ha anche un oscillatore interno. La memoria eeprom non è necessaria quando si avvia il Propeller con la connessione remota attiva. La Propeller Clip converte l’interfaccia serial in USB
Il boot code del Propeller che si trova nella ROM dell’HUB carica il contenuto della eeprom nella RAM dell’HUB, successivamente cede il controllo al COG0 che esegue una copia dell’interprete Spin e inizia a leggere e ad eseguire il codice applicativo. Durante la fase di sviluppo del codice è possibile sfruttare un’altra funzione del boot loader. All’avvio infatti il loader cerca di stabilire una connessione seriale con un dispositivo remoto (Ad es. un PC). Se viene stabilita la connessione il Propeller carica il codice applicativo nella RAM direttamente dal dispositivo remoto anziché dalla eeprom. Questa funzione permette di aggiornare rapidamente il codice durante la fase di sviluppo.
I TOOLS DI SVILUPPO
Dalla descrizione della procedura di startup si può già intuire che per utilizzare un Propeller si deve semplicemente collegare due porte del micro ad una porta seriale e utilizzare l’IDE di sviluppo per la programmazione. In figura 3 un esempio di una completa demo board con connessione USB per la programmazione, predisposta per la connessione audio, video VGA e con una protoboard per la realizzazione dell’hardware.
Figura 3. La demo board del propeller. Include connettori audio/video VGA, un connettore PS2 e il connettore per l’interfaccia USB per la programmazione. Con la protoboard è possibile aggiungere e provare velocemente il proprio hardware
CONCLUSIONI
Utilizzare il Propeller, pensare ad un‘applicazione in termini di otto processi concorrenti non è semplice e può creare inizialmente delle difficoltà. I vantaggi di questa architettura sono molteplici come enunciato nell'introduzione. L’assenza di vincoli permette al progettista di spaziare con una certa libertà in termini hardware e software, sfruttando la potenza del linguaggio assembly (o assembler).
In questi casi utilizzare il linguaggio assembler/assembly e’ molto importante per gestite molto da vicino le operazioni del propeller. Oggi le nuove piattaforme di sviluppo permettono di usare un linguaggio ad alto livello invece dell’assembly, a vantaggio entro certi limiti del programmatore.