Come iniziare con gli IC Cypress EZ-USB FX2LP

Questo articolo vuole essere una collezione di risorse per iniziare lo studio dei circuiti integrati di casa Cypress, precisamente gli IC della serie FX2LP.

Qualora fosse necessario disporre di comunicazione USB 2.0 Hi-Speed (480 MBps) e di un microcontrollore ad 8 bit ad elevate prestazioni, IC come CY7C68013A (sotto è mostrato il suo diagramma a blocchi logico) che utilizzeremo nell’articolo sono sicuramente da valutare.

Notiamo come sul dispositivo in considerazione non sia presente una memoria Flash o EEPROM interna per la memorizzazione del firmware, da un punto di vista produttivo significa ridurre di molto l’area di silicio e quindi il costo del dispositivo non dovuto solo alla area della memoria ma anche alla pompa di carica (Charge Pump) interna necessaria per la generazione della elevata tensione necessaria per il suo utilizzo.

La pompa di carica introduce problemi legati alla miniaturizzazione del dispositivo ed influisce spesso sulla scelta del processo produttivo, di contro per la memorizzazione del firmware sarà necessaria una memoria esterna o il caricamento del firmware in memoria RAM al collegamento del PC tramite USB, scelta perseguita in diversi prodotti commerciali che rende allo stesso tempo molto semplice l’aggiornamento del firmware.

E’ possibile utilizzare una EEPROM esterna da 16 bytes come l’IC 24LC00 per la sola memorizzazione del VID/PID USB associato al dispositivo in modo da far associare subito il driver desiderato al dispositivo.

Il micro nell’IC è compatibile a livello di codice binario con gli 8051 classici e permette di riutilizzare toolchain e strumenti come Keil uVision C51 per lo sviluppo del codice. E’ necessario prestare attenzione ad alcuni dettagli in quanto la maggiore velocità (4 clock / istruzione) rispetto all’architettura classica (12 clock / istruzione) può introdurre differenze nelle tempistiche di funzionamento. Nel panorama Open Source è disponibile il compilatore SDCC (Small Device C Compiler).

Sulla rete sono disponibili diverse schede di sviluppo per tutte le tasche, dalle economiche schede amatoriali CY7C68013A MINI BOARD ai kit di sviluppo ufficiali come il CY3684 EZ-USB FX2LP Development Kit contenente al suo interno oltre all’IC anche SRAM, GAL, IO Expanders, diverse EEPROM, Transceiver, e molto altro ancora.

Per quanto riguarda la programmazione non è necessario comperare un programmatore esterno in quanto grazie alla interfaccia USB è possibile caricare il firmware da PC nella RAM o nella EEPROM collegata all’IC.

Per iniziare, anche nel caso di schede di sviluppo economiche, installiamo il software di sviluppo CY3684 EZ-USB FX2LP Development Kit che creerà diverse cartelle nel nostro disco.

In particolare è importante la cartella Drivers\cyusbfx1_fx2lp in quanto sarà necessario installare il driver ivi contenuto al collegamento del dispositivo al PC tramite USB. Dopo l’installazione del driver verrà identificato come Cypress EZ-USB FX2LP No EEPROM e sarà pronto per l’interfacciamento coi tools di sviluppo.

Apriamo la Cypress USB Console, installata assieme al Development Kit per verificare che il driver del dispositivo sia correttamente installato

Scegliendo Options / EZ-USB Interface è possibile accedere ad altri comandi per il caricamento di firmware (pulsante Download per il caricamento del firmware nella RAM), scrittura della EEPROM collegata al dispositivo  (pulsante S/Lg EEPROM per la scrittura di piccole o grosse memorie EEPROM, S = Small, Lg = Large) ed altro ancora.

L’interfaccia del programma non è purtroppo molto user-friendly, è consigliato consultare la guida EZ-USB Development Kit User Guide per maggiori informazioni sugli strumenti di Cypress.

Realizziamo adesso un semplice programma programmando il microcontrollore 8051.

Apriamo Keil uVision5, disponibile anche in versione di valutazione gratuita con qualche limitazione, e scegliamo Project / New uVision Project indicando il percorso del nostro progetto. Ci verrà chiesto il dispositivo da programmare, scegliamo EZ-USB FX2LP (CY7C68XXX-X) e premiamo OK.

Scegliamo adesso Projects/Options for Target e dalla scheda Target impostiamo la frequenza di clock del cristallo della nostra scheda di sviluppo

Nella scheda Output assicuriamoci che sia abilitata la creazione del file HEX

Nella scheda Utilities infine impostiamo come strumento di programmazione del dispositivo il percorso del programma CyUpload, scaricabile al termine dell’articolo, che ho sviluppato tramite le libreria Cypress CyUSB .NET DLL di cui parleremo eventualmente in un successivo articolo, per semplificare, integrare e velocizzare la programmazione ed evitare di ricorrere al programma Cypress USB Console ogni volta.

Nel campo Arguments inseriamo la stringa %H che sarà trasformata automaticamente nel percorso del file HEX durante la programmazione da parte di Keil uVision.

Adesso che il progetto è stato correttamente configurato, aggiungiamo al progetto nel Source Group 1 la libreria EZUSB.LIB dal percorso C:\Cypress\USB\CY3684_EZ-USB_FX2LP_DVK\1.0\Target\Lib\LP per poter utilizzare funzioni come EZUSB_Delay() per l’attesa di un certo numero di millisecondi.

Creiamo adesso un nuovo file Blink.c col seguente codice:

Dove OEB è il registro della porta B adibito alle direzioni dei pin (1 = Output, 0 = Input) ed IOB è il registro di I/O per la lettura e scrittura dei bytes.

Il codice mostrato alzerà il pin PB0 ad HIGH per 50ms e lo porterà a LOW per 100ms, ripetendo il codice ciclicamente.

Una volta terminata la stesura del codice è possibile compilare il programma con il comando Project / Build target e caricarlo nel dispositivo tramite il comando Flash / Download

Variando i tempi di lampeggio e collegando un led con relativa resistenza sarà possibile creare il classico Hello World del mondo della programmazione firmware.

Abbiamo visto in questo articolo alcuni strumenti e un esempio di programmazione dei dispositivi Cypress,

L’Application Note Getting Started with FX2LP può fornire un’introduzione preliminare alternativa, il punto di inizio per lo studio del microcontrollore e delle funzionalità USB dell’IC è il manuale di riferimento tecnico EZ-USB Technical Reference Manual ed il datasheet del dispositivo.

E’ possibile continuare il proprio studio esplorando funzionalità avanzate come l’USB Hi-Speed, i GPIF, e tanto altro ancora.

Importante: Il programma CyUpload è una utility pensata per l’uso personale e non ampiamente testata per funzionare in tutte le condizioni possibili. Programma la RAM del primo dispositivo utilizzante i driver Cypress trovato, è necessario collegare solamente il dispositivo Cypress da programmare o utilizzare Cypress USB Console che può essere utilizzato per controllare se sono presenti altri dispositivi Cypress collegati.

Scarica CyUpload

Buon divertimento con i circuiti Cypress

FPGA: Comunicazione ad alta velocità tramite USB 2.0 - Download

Siamo giunti al termine di questa triologia di articoli dove abbiamo realizzato una comunicazione ad alta velocità tra FPGA e PC, è sotto riportato il sommario del percorso svolto:

Prima parte:       Introduzione al progetto e UM232H

Seconda parte:  DE0-Nano

Terza parte:       Software

Nel download del progetto è presente:

- il progetto per la realizzazione del modulo USB 2.0 per la DE0-Nano tramite toner transfer (Eagle 6.4)

- il progetto console C# (Visual Studio 2010)

- il progetto FPGA (Quartus 13.0)

Per concludere volevo segnalare alternative all’IC FT232H di cui esistono versioni a più canali denominate FT2232H (2 canali) ed FT4232H (4 canali) utili quando nella scheda sono necessarie contemporaneamente più interfacce come ad esempio JTAG per la programmazione della FPGA.

Infine gli integrati di Cypress della serie EZ-USB SX2 offrono un controller USB 2.0 ad alta velocità mentre la serie FX2LP (FX2 Low Power) aggiunge nello stesso integrato un microcontrollore 8051 e tante altre funzionalità.

La scelta per questi articoli è però ricaduta sull’FT232H tramite il modulo di sviluppo UM232H per la sua semplicità e il basso costo.

Buon divertimento a tutti

FPGA: Comunicazione ad alta velocità tramite USB 2.0 (terza parte) - Software

L’IC FT232H di cui abbiamo parlato nei precedenti articoli (parte I, parte II) permette una comunicazione col pc tramite due interfacce: VCP e D2XX.

L’interfaccia VCP (Virtual COM Port) è pensata per sostituire sistemi con la vecchia porta seriale senza modifiche nei software esistenti, il dispositivo viene visto dal sistema operativo come una porta COM seriale. Gli svantaggi di questa interfaccia riguardano le prestazioni, difficilmente si riusciranno a superare i 3M Baud.

L’interfaccia D2XX è un’interfaccia proprietaria per i dispositivi FTDI che permette di raggiungere le massime prestazioni e fornisce accesso a tutte le funzionalità esposte dagli IC.

Windows CDM Driver Architecture

Nella distribuzione Windows entrambe le interfacce vengono fornite in un unico pacchetto driver denominato CDM (Combined Driver Model) mentre per gli altri sistemi operativi le interfacce corrispondono a differenti driver mutualmente esclusivi.

Dopo aver installato il driver CDM è possibile procedere alla programmazione tramite D2XX utilizzando le API documentate nella D2XX Programmer's Guide e visionando gli esempi nei diversi linguaggi di programmazione.

Per semplificare la comprensione del software svilupperemo in questo articolo un programma console per scrivere e leggere i dati dalla FPGA.

Come ulteriore facilitazione utilizzeremo il linguaggio C# tramite la libreria wrapper fornita da FTDI per velocizzare ulteriormente i tempi di sviluppo.

La libreria incapsula nella classe FTDI tutte le funzionalità esposte dalle API, aggiungendo una serie di controlli e diagnostica per rendere più developer-friendly l’utilizzo a programmatori C#.

Importante: Alcuni messaggi di errore vengono mostrati dalla libreria wrapper tramite MessageBox, sarà necessario includere nel progetto il riferimento all’assembly System.Windows.Forms per poter compilare correttamente l’applicazione se si include il sorgente della libreria nel proprio progetto per evitare di distribuire una DLL aggiuntiva.

Per avere accesso al dispositivo come prima cosa dobbiamo creare una nuova istanza della classe FTDI e aprire il dispositivo.

La prima funzione da chiamare sarà OpenByDescription, OpenByIndex, OpenByLocation o OpenBySerialNumber dove sarà possibile aprire il dispositivo in base alla descrizione, indice, locazione o numero di serie.

Utilizzeremo OpenByDescription specificando la descrizione “UM232H”, corrispondente alla descrizione di default del modulo. In caso di problemi sarà possibile impostare il nome della descrizione del chip tramite il programma FT Prog. La stringa della descrizione è memorizzata nella EEPROM collegata al chip FT232H sul modulo UM232H.

La libreria offre un meccanismo un po’ antico per la gestione degli errori che non è stato convertito nella libreria wrapper con l’utilizzo di eccezioni C#. Ogni chiamata in genere restituisce un valore di tipo FT_STATUS, da controllare per verificare se tutto è andato a buon fine.

Prima di poter leggere e scrivere dati dobbiamo impostare la modalità operativa di comunicazione ed alcuni parametri.

Innanzitutto resettiamo il dispositivo chiamando la funzione SetBitMode con modalità FT_BIT_MODE_RESET, ignoriamo il primo parametro che consiste in una maschera di bit per impostare quale bit sono di ingresso e quali di uscita, parametro utile per configurare i pin di I/O dell’ACBus.

Dopo il reset attendiamo 10ms per impostare il dispositivo nella modalità 245 FIFO sincrona tramite il parametro FT_BIT_MODE_SYNC_FIFO.

Impostiamo poi altri parametri come la latenza tramite SetLatency il cui valore di default è 16ms. Il timer di latenza è una caratteristica del driver, un timeout per trasmettere brevi pacchetti di dati al pc. Cambiare la latenza è un’operazione opzionale e può servire per migliorare in alcuni casi le prestazioni in base alla propria applicazione.

Tramite InTransferSize impostiamo la dimensione dei trasferimenti in ingresso ed uscita dell’USB, aumentiamo questo valore per migliorare le prestazioni nel trasferimento sequenzialmente di grosse quantità di dati.

Infine impostiamo tramite SetFlowControl il flusso di controllo a FT_FLOW_RTS_CTS per evitare rari errori di corruzione dati.

Siamo adesso pronti a trasferire ad alta velocità i nostri bit.

Senza riportare tutto il codice sorgente che potrete trovare alla fine di questo articolo, riportiamo le parti salienti descrivendo a grandi linee il resto.

Come prima operazione apriamo il file di ingresso da trasmettere alla FPGA, ne leggiamo un blocco composto da qualche migliaia di bytes e tramite la funzione Write inviamo all’IC FT232H i bytes letti che verranno quindi inviati alla FPGA.

La funzione write è molto semplice e così dichiarata:

dove il primo parametro è il buffer contenente i dati da scrivere, il secondo parametro indica il numero di bytes da scrivere ed il terzo riporta i bytes effettivamente scritti.

swWrite è un’istanza della classe C# Stopwatch per misurare la durata dell’operazione e permettere di riportare successivamente le statistiche di velocità delle operazioni.

Dopodiché leggiamo i dati dalla FPGA utilizzando la funzione Read:

Con sintassi analoga alla funzione Write, molto semplice da utilizzare. Ricevuti i dati controlliamo byte per byte se corrispondono ai dati del file inviato ed aggiorniamo ad intervalli regolari le statistiche.

Sotto è riportata una schermata del programma in esecuzione:

In questo articolo è stata sviluppata una semplice interfaccia console per evitare di aggiungere le complessità di un interfaccia grafica multithreading mostrando le operazioni basilari da compiere per gestire la comunicazione tramite USB 2.0ad alta velocità con il chip di FTDI.

Importante: Prima di lanciare l’applicazione è necessario inserire nella cartella contenente l’eseguibile (cartella Debug o Release) un file nominato dataIn.bin che sarà inviato alla FPGA ed il cui contenuto sarà ricevuto indietro

FPGA: Comunicazione ad alta velocità tramite USB 2.0 (seconda parte) - DE0-Nano

In questo articolo (vedi precedente) illustriamo il funzionamento dell’IC FT232H per poterlo così interfacciare alla nostra scheda FPGA DE0-Nano

L’FT232H permette di eseguire due tipi di operazione nella modalità FT245 sincrona: operazione di lettura ed operazione di scrittura.

Operazione di lettura

Un’operazione di lettura può iniziare quando il chip porta il pin RXF#, che quindi andrà monitorato, a LOW. L’FPGA può portare il pin OE# a LOW per far presentare il primo byte sul bus (i pin ADBUS) dopodiché può portare il pin RD# a LOW per informare il chip dell’avvenuta lettura. Tenendo il pin RD# a LOW si possono leggere sequenzialmente più dati, o si può interrompere la lettura portando ad HIGH il segnale RD#.

Sul fronte di salita del clock (pin ACBUS5) saranno presentati i sequenzialmente gli ulteriori dati. Una volta letti tutti i dati disponibili il segnale RXF# verrà portato ad HIGH dal chip.

NB: E’ importante monitorare sia sul fronte di salita sia di discesa il segnale RXF# per poter portare ad HIGH i pin OE# ed RD# al primo fronte di salita del clock nel caso il segnale RXF# venga portato ad HIGH nel fronte di discesa precedente, come illustrato nel diagramma.

Operazione di scrittura

Un’operazione di scrittura può essere iniziata quando il pin TXE# è LOW. WR# deve essere portato a LOW quando i dati presentati sul bus sono validi. Una scrittura sequenziale può essere fatta ad ogni fronte di salita del clock mentre TXE# è ancora LOW. La FPGA deve monitorare TXE# per assicurarsi che i dati possano essere accettati. Sia TXE# che WR# devono essere LOW per far si che i dati vengano accettati.

NB: Così come nell’operazione di lettura è importante monitorare sia sul fronte di salita sia di discesa il segnale TXE# per poter portare ad HIGH il pin WR# al primo fronte di salita del clock.

Tempistiche

E’ estremamente importante rispettare le seguenti tempistiche

Per assicurarsi che la FPGA rispetti i vincoli temporali sarà necessario impostare i vincoli tramite un file SDC (Synopsys Design Constraints) ed impostare ragionevolmente il carico capacitivo dei pin tramite Quartus.

Sotto è riportato un esempio di file SDC con in particolare i vincoli di Setup ed Hold Time

Diagramma a blocchi del sistema di LoopBack

Per illustrare meglio sia la lettura che la scrittura realizzeremo un semplice loopback, ovvero la ricezione e la ri-trasmissione di dati tramite USB 2.0.

Il clock fornito dal chip FT232H viene utilizzato anche per la logica interna, per migliorare l’aderenza alle tempistiche è introdotto preliminarmente in un PLL dove è possibile tramite sfasamento migliorare i tempi di Setup o di Hold.

Il sistema è composto da due blocchi principali: ft232h_loopback che contiene la vera logica del sistema, implementata tramite macchina a stati finiti, ed il blocco single_port_ram, una semplice memoria SRAM implementata direttamente su FPGA il cui scopo è memorizzare i dati letti durante la fase di scrittura. La memoria funge da buffer per migliorare le prestazioni del sistema ed evitare di scrivere il dato subito dopo ogni byte letto.

La dimensione del buffer è personalizzabile senza modificare il codice dei blocchi ma semplicemente cambiando il valore dei parametri associati, nell’immagine è presente un buffer di 2KB (2048 bytes) pari a 16384 bit, il 3% della memoria integrata nella FPGA della DE0-Nano.

Macchina a stati finiti

La macchina a stati finiti implementata nel blocco ft232h_loopback è molto semplice e sotto illustrata graficamente

Il processo che determina lo stato successivo, basato sullo stato corrente e sugli ingressi è il seguente:

Dove writeIndex rappresenta l’indirizzo della SRAM dove avverrà la lettura o la scrittura

Il processo che determina le uscite in base allo stato corrente e agli ingressi è il seguente

Da notare l’utilizzo dell’alta impedenza sul bus durante la lettura. Essendo il processo non dipendente dal clock il monitoraggio dei segnali nRXF ed nTXE avviene correttamente, congruamente a quanto detto precedentemente.

Memoria RAM

L’implementazione della memoria RAM è quella classica, realizzata a partire dai template predefiniti di Quartus

Presenta parole di lunghezza 1 byte mentre la dimensione della memoria è impostata tramite il parametro generico ADDR_WIDTH.

L’utilizzo di risorse finale del sistema così implementato è molto ridotto e lascia spazio all’implementazione di altre funzionalità sulla scheda

Per quanto riguarda la parte FPGA è tutto, vedremo nel prossimo articolo come realizzare il software per scrivere e leggere dati tramite USB 2.0 ed interfacciarci quindi alla scheda DE0-Nano ad altissima velocità.

FPGA: Comunicazione ad alta velocità tramite USB 2.0 (prima parte)

Uno dei principali problemi in sistemi composti da FPGA e PC è stabilire una comunicazione semplice, veloce ed affidabile. Vediamo in questo articolo come aggiungere alla scheda di sviluppo DE0-Nano il supporto USB Hi-Speed (fino a 480 MBit/s teorici) per aprire nuovi scenari di sviluppo come l’acquisizione ed elaborazione di dati ad alta velocità.

La scheda di sviluppo DE0-Nano dispone di due pin header superiori da 40 pin (2x20) che permettono l’espansione della scheda.

Utilizzeremo l’header GPIO-1 per collegare la scheda di sviluppo UM232H basata sull’IC FT232H di FTDI che offre una comunicazione USB 2.0 tramite un’interfaccia FIFO sincrona ad 8 bit di semplice utilizzo che offre trasferimenti fino a 40 MBytes/s. Da prove pratiche in alcuni casi, sfruttando vari buffer, si sono misurate velocità di trasferimento addirittura superiori.

Sopra il diagramma a blocchi del chip FT232H, tra le altre funzionalità è possibile notare un buffer di 1K Bytes in ricezione e trasmissione

Lo schema del modulo di espansione è abbastanza semplice, non contiene elementi aggiuntivi e collega la scheda FPGA a quella USB 2.0 impostando tramite i collegamenti l’alimentazione del modulo UM232H in modalità self-powered, ovvero alimentata tramite la scheda DE0-Nano e non dalla porta USB.

Il consumo del modulo UM232H è molto contenuto, circa 60mA ma solamente quando collegato tramite USB al PC, rendendolo appetibile anche in applicazioni alimentate a batteria. A PC scollegato il consumo del modulo è non rilevante in quanto in stand-by grazie al pin PWRSAV#.

Sotto un’immagine del prototipo del modulo USB 2.0, realizzato tramite Toner Transfer, collegato alla scheda di sviluppo.

Configuriamo il modulo UM232H

Una volta realizzato il modulo di espansione e collegato al PC tramite il programma FT Prog è possibile configurare la EEPROM a bordo dell’UM232H contenente le configurazioni del modulo.

In particolar modo impostiamo nella pagina USB Config Desciptor il dispositivo come Self Powered, selezioniamo inoltre il canale come 245 FIFO ed il Driver come D2XX Direct come mostrato nelle seguenti immagini:

Il driver Virtual COM Port seppur permetta di sostituire senza sforzo vecchie porte seriali nei software dove previste non permette di raggiungere velocità elevate. D2XX offre un’API semplice ed efficiente, disponibile sia in C/C++ sia in linguaggi come C#.

Prossimamente vedremo come realizzare il software lato PC e come programmare la FPGA per realizzare una semplice applicazione di LoopBack (es. un file inviato alla FPGA e ritrasmesso al PC) al fine di verificare il funzionamento del tutto.

Vi lascio per il momento solamente un’altra immagine..

A presto

Introduzione ad ASF (ottava parte) – SPI

Al livello più basso nei microcontrollori XMega per utilizzare il supporto hardware ad SPI abbiamo a disposizione per ogni porta SPI i seguenti registri: Control (CTRL), Interrupt Control (INTCTRL), STATUS e DATA, tutti adeguatamente documentati nel datasheet del microcontrollore.

Possiamo accedere ad esempio ai registri della porta SPI C tramite SPIC_CTRL, SPIC_INTCTRL, SPIC_STATUS ed SPIC_DATA o tramite la comoda struttura SPIC (il suffisso C indica la porta SPI) che espone i registri come membri della struttura (es. SPIC.CTRL). Mantenendo un puntatore alla struttura la sintassi diventa (&SPIC)->CTRL.

Come operazione preliminare configuriamo i pin che utilizzeremo tramite SPI (dove nel codice i vari *_PIN sono pin creati ad esempio con l’istruzione IOPORT_CREATE_PIN come visto negli articoli precedenti).

Nella modalità Master è necessario mantenere il pin SS ad un livello logico alto per evitare che il modulo pensi che un altro master voglia prendere il controllo del bus (bus contention).

Se lavorassimo a basso livello come prima cosa dovremmo configurare il registro CTRL del modulo SPI.

ASF per la sua configurazione ci mette a disposizione diverse funzioni: spi_master_init, spi_master_setup_device ed spi_enable.

spi_master_init abilita il clock al modulo SPI e imposta la modalità SPI a Master Mode

spi_master_setup_device imposta la modalità SPI scelta (convenzioni di comunicazione come ad esempio MODE_0 elencate nel datasheet) e la velocità di clock della comunicazione (nell’esempio 1 MHz).

Nota Bene: Da notare che nell’XMega utilizzato la struttura spi_device_conf passata per riferimento non viene di fatto utilizzata, così come l’ultimo parametro select_id che viene semplicemente impostato a zero, probabilmente per compatibilità con versioni precedenti della libreria la funzione ha mantenuto questi parametri.

spi_enable abilita il modulo SPI, è il passaggio finale della configurazione.

Attenzione: Inizialmente avere tre metodi diversi per configurare un solo registro (CTRL), con tanto di parametri inutilizzati, può rendere difficile comprendere l’utilizzo del modulo SPI di ASF.

Una volta configurato il modulo è possibile inviare dei dati al dispositivo slave con le funzioni: spi_select_device, spi_write_packet e spi_deselect_device

Dove spi_device_conf è la struttura creata in precedenza, che ha come unico scopo il mantenimento del pin di abilitazione del dispositivo slave.

spi_select_device porta a low tale pin per abilitare l’effettiva ricezione da parte del dispositivo slave

spi_write_packet invia una sequenza di bytes (nell’esempio 3 bytes: 1, 2 e 3) occupandosi di attendere il completamento della trasmissione di ogni byte prima di procedere all’invio del successivo (a differenza di spi_write_single che invia un singolo byte ma non attende il completamento dell’invio). Sostanzialmente l’invio di un byte corrisponde alla scrittura del registro DATA del modulo SPI e l’attesa nel controllo del registro STATUS.

spi_deselect_device porta ad high il pin di abilitazione del dispositivo slave per la sua disabilitazione.

Oltre alla sola istruzione spi_write_packet possono essere inserite anche ulteriori letture o scritture prima di deselezionare il dispositivo. Nel datasheet del dispositivo slave è in genere possibile trovare i dettagli richiesti per l’utilizzo delle sue funzionalità.

Analogamente la lettura di dati dal dispositivo slave avviene tramite la funzione spi_read_packet

Dove nell’esempio vengono letti 3 byte dal dispositivo slave, come abbiamo visto scrivendo in effetti dei dati fittizi sul dispositivo slave e attendendo la completa scrittura del byte prima della presentazione del byte successivo. La lettura di un byte comporta la lettura del registro DATA del modulo SPI.

Oltre alla documentazione anche per questo articolo è stato analizzato il codice sorgente del modulo ASF per trarre maggiori informazioni sul funzionamento del modulo di cui sono state riportate le più rilevanti per sopperire alle mancanze della documentazione.

Spero che in questi due articoli si siano chiariti alcuni dubbi, senza la pretesa però di spiegare tutto nei minimi dettagli.

Logiche Programmabili: Un possibile percorso per semplici appassionati

Per gli appassionati di elettronica iniziare ad utilizzare le logiche programmabili può essere un passo impegnativo.

Le schede di sviluppo FPGA più recenti offrono molte funzionalità ma necessitano la lettura di centinaia di pagine di documentazione tecnica, la conoscenza di un linguaggio di descrizione dell’hardware come VHDL o Verilog e sono in genere molto delicate. Sono spesso pensate per i professionisti del settore.

Chi non è deciso o non ha molto tempo a disposizione difficilmente farà il passo.

Con questo articolo voglio proporre un possibile percorso per gli appassionati non professionisti dell’elettronica, particolarmente amanti del DIY (Do It Yourself), per scoprire gradualmente le logiche programmabili.

Da dove partire

Prima di iniziare da un potente e costoso FPGA il consiglio è quello di può iniziare da un più semplice CPLD come l’EPM3064 della serie MAX 3000A di Altera. Sebbene un po’ datato e non permetta di realizzare veri e propri sistemi completi può aiutare all’apprendimento del workflow base di sviluppo con lo logiche programmabili.

Ecco gli svantaggi / vantaggi principali in una possibile ottica per non professionisti:

Svantaggi:

- Non compatibile con l’ultimissima versione del programma di sviluppo per logiche programmabili Quartus (gratuito nella web-edition), è possibile però utilizzare fino alla versione 13.0 SP1 installabile anche side-by-side con l’ultima versione

- Funzionalità limitate, si realizza in genere solamente semplice logica di contorno

- Programmabilità della memoria interna della CPLD limitata, garantite 100 scritture

Vantaggi:

- Datasheet di meno di 50 pagine: http://www.altera.com/literature/ds/m3000a.pdf

- Tensione di sistema compatibile coi 3.3V ed I/O compatibile coi 5V, tensioni ancora molto diffuse tra gli hobbisty

- Package disponibile in formato PLCC-44, abbinato ad un socket permette la sostituzione immediata del chip in caso di rottura, aspetto importante per chi non è professionista del settore e non vuole comprare una nuova scheda in casi mal fortuiti o di negligenza.

- Non necessita di memoria esterna

- Costo contenuto, all’incirca come un microcontrollore ad 8 bit.

Applicazioni

Alcuni possibili utilizzi della CPLD sono: sostituzione di più IC discreti di logica come ad esempio la serie 7400 con un singolo IC, microcontroller I/O expander, led driver, crosspoint switch matrices, level translator e tanti altri ancora.

Per utilizzare la CPLD non è obbligatoriamente necessario imparare un linguaggio di descrizione dell’hardware, Quartus offre un editor visuale in cui è possibile inserire e collegare virtualmente dei componenti per sostituire velocemente ad esempio porte logiche discrete o IC della serie 7400 di cui si trova già inclusa nel programma una vasta libreria.

Per iniziare a prendere confidenza col programma partire dall’editor visuale può essere una buona idea.

E’ inoltre possibile scegliere arbitrariamente i pin di I/O del proprio design tramite il Pin Planner di Quartus, un enorme vantaggio rispetto agli IC logici discreti tradizionali che può semplificare la realizzazione del PCB nel caso di schede specifiche per la propria applicazione

La scheda di sviluppo

Il mercato purtroppo non offre molte schede di sviluppo a basso costo e semplici per questa CPLD in involucro PLCC ed un ostacolo iniziale per gli amanti del DIY può essere progettare una scheda di sviluppo funzionante su cui imparare e poter basare successivamente i propri progetti.

Voglio proporre in questo articolo una scheda realizzabile da appassionati con la tecnica del Toner Transfer, un reference design che permette, assieme ad un programmatore JTAG compatibile con logiche programmabili Altera reperibile su internet per pochi euro, di iniziare a sperimentare.

Lo schematico assieme al PCB, scaricabile alla fine dell’articolo, è disponibile nel formato Eagle, particolarmente amico degli hobbisty e gratuito in versione Light.

Lo schema è molto semplice, di facile comprensione a chi ha progettato anche semplici schede con microcontrollori:

- Tutti i pin della CPLD vengono esposti tramite pin header per la prototipazione rapida

- E’ presente un connettore IDC-10 per la programmazione del dispositivo tramite JTAG (come detto precedentemente è necessario il programmatore)

- Il regolatore di tensione (es. un semplice NCP1117LPST33T3G o similare in base alle necessità) fornisce una tensione stabilizzata di 3.3V, il diodo D2 è opzionale e necessario solamente se il carico capacitivo totale alimentato (CPLD + eventuali circuiti collegati alimentati) è superiore ai 50uF, nell’incertezza e visto il costo esiguo del componente è possibile aggiungerlo in ogni caso senza grossi problemi.

- Il cristallo oscillatore, montabile su socket per la sostituzione veloce, permette di realizzare successivamente design sincroni tramite la programmazione del CPLD. E’ importante che il modello scelto sia compatibile coi 3.3V, un cristallo da 50 MHz è in genere adatto per la maggior parte delle applicazioni.

- Il pulsante di Reset (opzionale) fornisce il segnale Global Clear per azzerare i flip-flop all’interno dei propri design

- E’ possibile montare sul socket indistintamente la versione PLCC dell’EPM3064A o della EPM3032A che si distingue solamente per la presenza di minori risorse logiche.

La scheda, non professionale, è pensata dando priorità alla semplicità e al basso costo.

Ecco il rendering 3D della scheda, realizzato col gratuito Eagle3D

Per semplificare l’autocostruzione la scheda è stata progettata con saldature e connessioni su singola faccia, è necessario solamente realizzare tre ponticelli (collegamenti in rosso nella prima immagine) ed il collegamento sotto il socket tassativamente prima di saldare il socket stesso, altrimenti diventerà poi difficile procedere alla saldatura del ponticello.

A sinistra del pulsante di reset è presente un’aria non densamente occupata, dove in origine era presente un circuito di Pierce per permettere l’utilizzo della scheda con un più economico e facilmente disponibile quarzo. Nel rilasciare la scheda sul blog ho deciso di eliminare questa opzione in quanto non adeguatamente testata e per semplificare il tutto. E’ possibile spostare il connettore JTAG accanto al pulsante e rendere la scheda più compatta o inserire qualche componente utile in tale posizione in base alle esigenze.

Le piste sono larghe anche 10 mils, è quindi necessario utilizzare correttamente la tecnica del toner transfer per creare la scheda senza errori e frustrazioni, stampare tramite laser ad una risoluzione di almeno 1200 DPI su un supporto adeguato ed utilizzare un laminatore (o plastificatore) se non si ottengono buoni risultati con altri metodi.

E’ stato fatto uso di diversi componenti SMD (resistenze e condensatori 1206 e 0805) di semplice saldatura anche con attrezzature non professionali, c’è da porre solamente un pochino di attenzione laddove le piste passino sotto tali componenti per evitare corti circuiti.

Nota: Il PCB necessita di parecchi fori (131), è possibile però modificare senza grandissimi sforzi la scheda sostituendo tutti i componenti foro passante con equivalenti SMD, il socket PLCC smd necessita però di attrezzature in genere non alla portata dell’hobbista.

Il regolatore di tensione può necessitare di un dissipatore o di una maggiore area di dissipazione su PCB, in base alla tensione di ingresso e al consumo totale del circuito. Una stima del consumo precisa può essere fatta tramite lo strumento PowerPlay di Quartus in base al proprio design, dal datasheet il grafico del consumo tipico della CPLD è il seguente:

Dove è possibile notare come a frequenze maggiori corrispondano consumi maggiori.

Alternative

Oltre ad Altera esistono anche altri produttori di CPLD tra cui i principali Xilinx e Lattice Semiconductor.

 

Un ringraziamento infine all’amico Pelletta per aver collaborato allo sbroglio del PCB, realizzato e testato la scheda.

Scarica lo schema e la board

Buon divertimento con le logiche programmabili

Introduzione ad ASF (settima parte) – Introduzione ad SPI

Analizziamo in questo articolo l’utilizzo dell’interfaccia Serial Peripheral Interface (SPI)

SPI permette una comunicazione sincrona ad alta velocità tra un dispositivo Master ed uno o più dispositivi Slave.
Ogni dispositivo contiene un registro a scorrimento tipicamente ad 8 bit (1 byte) il cui scorrimento è basato sul segnale di clock fornito dal Master.

Prendiamo in considerazione una comunicazione tra un dispositivo Master ed un solo dispositivo Slave

I registri a scorrimento sono collegati tra loro tramite i segnali MISO (Master Input - Slave Output) e MOSI (Master Output – Salve Input), lo scorrimento dei bit tra i due registri permette quindi uno scambio di dati tra i due dispositivi.

Questa architettura porta ad alcune importanti conseguenze da tenere sempre presenti:

- Il Master deve inviare dei dati per leggere i dati dello Slave, i bit del registro a scorrimento dello Slave verranno copiati in quello del Master ma al tempo stesso i bit del Master saranno copiati nel registro dello Slave.

- Nuovi byte non possono essere scritti nel registro prima che i vecchi siano stati trasferiti tramite lo scorrimento

- I dati devono essere letti prima dell’arrivo dei successivi che faranno scorrere il buffer e sovrascriveranno quindi i vecchi dati che saranno così persi.

Iniziamo a vedere adesso dopo questa breve panoramica su SPI come interfacciarci tramite XMega (Master) ad un dispositivo esterno (Slave)

Creiamo un nuovo progetto tramite il template EWS ATXmega32A4U come visto negli articoli precedenti

UPDATE: Template aggiornato per Microchip Studio ed ASF 3.52 disponibile qui

Aggiungiamo tramite ASF Wizard il modulo SPI – Serial Peripheral Interface Master (Common API) scegliendo standard_spi, utilizzeremo il modulo hardware SPI del micro. Un’altra opzione che non vedremo in questo articolo è utilizzare il flessibile modulo hardware USART del micro o addirittura entrambi.

Dopo aver aggiunto il modulo notiamo come nel progetto siano stati inseriti i file spi.c ed spi.h, i driver di basso livello di SPI ed i file spi_master.c ed spi_master.h, servizi a livello più elevato

Il Driver SPI è semplicemente un file C contenente le funzioni sotto elencate che permettono una gestione a basso livello del modulo hardware di cui il micro è dotato, queste funzioni non contengono molta logica e sostanzialmente espongono sotto nomi più amichevoli i registri interni del micro. L’unica funzione contenente un poco di logica è la funzione spi_xmega_set_baud_div che effettua una serie di controlli sui dati in ingresso prima di impostare il clock in modo da avvicinarsi al baudrate desiderato.

Non chiameremo direttamente nessuna funzione del Driver SPI ma utilizzeremo invece il servizio SPI Master che oltre ad alcune definizioni e strutture dati offre le seguenti funzioni che ci permettono di strutturare in termini di pacchetti di byte il nostro Firmware

Nella prossima puntata vedremo come funzionano nella pratica le funzioni che ASF ci offre, alla prossima.