PARALLAX PROPELLER: 8 microcontrollori a 32 bit in un unico package

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

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

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

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).

 

Approfittane ora!

Una risposta

  1. Maurizio Di Paolo Emilio Maurizio 14 Agosto 2016

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend