Embedded Workbench su MSP430 con IAR System

IAR Systems produce e vende tools per lo sviluppo e il debug di applicazioni embedded a microprossore/microcontrollore, offrendo supporto per un'ampia gamma di microcontrollori (MCU's) 8/16 e 32 bit. MSP430 rappresenta una famiglia di microcontrollori prodotti  dalla Texas Instruments. Questi microcontrollori lavorano a 16 bit e sono caratterizzati  da  un  consumo  estremamente  ridotto (ultra low-power).

INTRODUZIONE

IAR Embedded Workbench è un ambiente integrato  di  sviluppo  (IDE) per  Windows . Questo include tutti i tools necessari per lo sviluppo ed il testing delle applicazioni embedded: Project Manager, Editor, Compilatore ANSI C (or EC++), Assembler, Linker, Librerie, set completo di Librerie Runtime e C-SPY Debugger Simulatore. Inoltre a seconda delle CPU utilizzate il debugger C-SPY è disponibile anche come (ROM-monitor, Emulatore ICE, BDM, JTAG...). Oltre ad un'efficiente generazione del codice da parte del compilatore, l'Embedded  Workbench della IAR offre la possibilità di utilizzare lo stesso ambiente di sviluppo per più di 30 differenti microprocessori/controllori  e DSP a 8/16 e 32 bit, la figura 1 mostra i blocchi funzionali di questo prodotto.

Figura 1. I blocchi funzionali di IAR Embedded Workbench

Figura 1. I blocchi funzionali di IAR Embedded Workbench

IAR Embedded Workbench per MSP430 supporta l’architettura MSP430X: questa estende il set delle istruzioni del MSP430 e garantisce un range d’indirizzzamento fino a 1 Mbyte.

In questa versione IAR ha potenziato alcuni aspetti tra cui la possibilità di migrare dalle versioni precedenti:

  • I progetti ottenuti da EW430 nelle versioni 1.x e 2.x possono essere aperti dal gestore dei progetti (project manager) della versione corrente. L’unico aspetto negativo è la perdita delle definizioni di configurazione del debugger.
  • Se si sta migrando da una versione 2.x alla versione corrente e si sta utilizzando la libreria DLIB, allora è necessario rivedere la configurazione della libreria stessa. In ogni caso il produttore, IAR, ha predisposto un apposito documento per condurre l’utente verso la nuova versione di EW430 senza traumi. Il documento è identificato come MSP 430 IAR Embedded Workbench Migration Guide.
  • Dall’altro versante, se si  vuole  migrare  dalla versione 1.x, il produttore  ha predisposto  una guida chiamata Step by step migration disponibile in EW430.
  • Il codice sorgente, scritto originariamente per la versione 1.x di MSP430 IAR C compiler può essere, con modifiche minime, utilizzato con la versione di MSP430 IAR C/C++ compiler, incluso in questa versione del prodotto.
  • Il codice sorgente scritto per la versione 2.x di MSP430 IAR C/C++ compiler può essere utilizzato in questa nuova versione dell’ambiente di sviluppo senza nessuna modifica.

Il prodotto  EW MSP430 è costituto dai seguenti pacchetti o varianti:

Professional edition

Questo è la versione professionale, nel senso che include una serie di strumenti che sono utili per la definizione del progetto  e allo sviluppo. Questa variante, per esempio, include Statechart Design.

Standard edition

È una versione completa a meno di Statechart
Design, Test and Documentation Tools.

Limited edition

È una versione senza debugger e include le
seguenti limitazioni:

  • Il debugger/simulatore IAR C-SPY non è disponibile;
  • Il supporto MISRA C non è disponibile.
    BaseLine edition information
    Questa versione è una variante a basso prezzo. Chiaramente dispone di diverse limitazioni:
  • Esiste un limite di 12 Kbyte per un programma C/C++;
  • L’assemblatore IAR Assembler è uguale a quello fornito con la versione completa e senza restrizioni;
  • Il linker IAR XLINK Linker può linkare fino ad un massimo di 12 Kbyte di codice sorgente C. Non esistono questi limiti se il progetto è scritto interamente in assembler;
  • Il simulatore IAR C-SPY può leggere fino 12Kbytes di codice scritto in C, anche in questo caso non ci sono limiti  se il progetto è scritto interamente in assembler;
  • Il supporto a MISRA C non è disponibile.
    KickStart edition
    Con il pacchetto KickStart si vuole identificare uno speciale starter-kit/evaluation IAR Embedded Workbench con le seguenti limitazioni e caratteristiche:
  • I limiti del codice di MSP430 IAR KickStart C/C++ Compiler è di 4 Kbytes;
  • L’assemblatore IAR Assembler è fornito ed è completo senza restrizioni;
  • Il linker IAR XLINK Linker può linkare fino a 4Kbytes di codice scritto in C. Non ci sono limiti se il progetto è stato scritto interamante in assembler;
  • Il simulatore IAR KickStart C-SPY può trattare fino a 4Kbytes di codice scritto in C, ma non si hanno restrizioni se il codice risulta scritto in assembler;
  • Il supporto MISRA C non è disponibile;
  • Il codice sorgente della libreria runtime non è inclusa.
    Evaluation edition
    Questo pacchetto è fornito per un periodo limitato, di solito per non più di 30 giorni. Le limitazioni previste sono:
  • Dopo il periodo d’uso l’EW MSP430 non è più disponibile;
  • Il supporto MISRA C non è incluso;
  • Il codice sorgente della libreria di runtime non è fornita.

OPZIONI DI CONFIGURAZIONE DI EW MSP430

Una volta installato il prodotto da STARTx PROGRAMSx IAR SYSTEMSx IAR EMBEDDED WORKBENCH KICKSTART FOR MSP430 V3, possiamo lanciare il tool. Il debug a corredo del tool è C-SPY: questo può essere configurato per essere utilizzato con il target (MSP430) o come simulatore software in mancanza del target stesso.

Utilizzare Kickstart

L’ambiente di sviluppo Kickstart dispone di funzionalità limitate ma nel contempo è perfettamente utilizzabile. Le limitazioni dell’ambiente possono essere così riassunte:

  • Il compilatore C non genera un file di listing in codice assembler;
  • Il linker è perfettamente funzionante per codice fino a 4K bytes di codice sorgente in C;
  • Nel contempo non esiste, per il linker, un limite per il codice assembler;
  • Il simulatore accetta in ingresso fino a 4K bytes di codice.

Per configurare l’uso di Workbench e C-SPY è necessario predisporre  in maniera corretta  l’ambiente di sviluppo. In questo caso è utile leggere la documentazione a corredo fornita dal produttore.

Definizione del progetto

Per utilizzare l’ambiente è necessario creare un progetto (project), la definizione del progetto è fatta attraverso l’uso del menu PROJECT x OPTIONS. Vediamo cosa dobbiamo fare per configurare un progetto:

  • Occorre specificare il target device (GENERAL OPTIONSx TARGETx DEVICE);
  • Abilitare l’uso di un progetto basato su assembler o  misto (assembler/C)   (GENERAL OPTIONSx TARGETx ASSEMBLER ONLY PROJECT);
  • Abilitare la possibilità della generazione, al termine del processo di linking, di un file eseguibile:
    FILEx EXECUTABLE);
  • È consigliabile, in fase di debug, disabilitare le ottimizzazioni dei programmi scritti in C: (C/C++ COMPILERx  CODEx OPTIMIZATIONSx SIZEx NONE (BEST DEBUG SUPPORT));
  • In fase di debug è opportuno avere, con l’eseguibile prodotto, anche tutte le informazioni di debug quali i riferimenti al codice sorgente, i simboli, ecc.: (C/C++ COMPILERx OUTPUTx GENERATE DEBUG INFO);
  • Quando utilizziamo il preprocessore C è necessario definire il percorso (path) dei file di include: (C/C++ COMPILERx PREPROCESSORx INCLUDE PATHS);
  • Se, abbiamo file scritti in assembler, occorre generare anche le informazioni di debug: (ASSEMBLERx OUTPUTx GENERATE DEBUG-INFO);
  • Occorre specificare, se  applicabile,  anche  il path  per  il preprocessore  assembler: (ASSEMBLERx PREPROCESSORx INCLUDE PATHS);
  • Se volessimo utilizzare  C-SPY  è  opportuno specificare un formato compatibile dell’eseguibile: (LINKERx OUTPUTx FORMATx DEBUG INFO [WITH TERMINAL IO]);
  • Occorre a questo punto predisporre i riferimenti precisi per le librerie: (LINKERx CONFIGx SEARCH PATHS);
  • Se usiamo C-SPY è necessario specificare il driver: Selezionare PROJECTx OPTIONSx Debuggerx Setupx  Driverx  FET se è valido questa opzione   (per esempio, MSP430). Selezionare SIMULATOR per iniziare la fase di debug con il simulatore. Se FET Debugger è selezionato, occorre usare PROJECTx OPTIONSx FET Debuggerx Setupx Connessione alla porta appropriata: LPTx per la porta parallela TI USB FET per la porta USB;
  • Abilitare il Device Description file. Questo file rende C-SPY  “aware”:  (DEBUGGERx SETUPx  DEVICE DESCRIPTIONx  OVERRIDE DEFAULT);
  • È possibile azzerare  la  memoria  del  target prima di caricare il programma: (FET DEBUGGERx SETUPx DOWNLOAD CONTROLx ERASE MAIN AND INFORMATION MEMORY);
  • Per  non avere impatti  sulla  prestazione  del sistema durante l’attività di debug, può risultare utile    disabilitare i  cosiddetti Virtual VIRTUAL BREAKPOINTS), e  per  disabilitare tutti i System Breakpoints (FET DEBUGGERx SETUPx SYSTEM BREAKPOINTS ON).

Creazione di un progetto da scratch

Vediamo ora cosa dobbiamo fare se vogliamo creare un progetto da scratch, in assembler o in C, e la procedura di caricamento su MSP430. I passi necessari sono così riassunti:

  1. da Windows occorre lanciare EW, da (STARTx PROGRAMSx  IAR SYSTEMSx  IAR EMBEDDED WORKBENCH KICKSTART FOR MSP430 V3x   KICKSTART  IAR  EMBEDDED  WORKBENCH);
  2. Creiamo un nuovo file di testo: (FILEx NEWx SOURCE/TEXT);
  3. A questo punto scriviamo il nostro programma, (vedi listato 1);
  4. Con l’opzione (FILEx SAVE) procediamo  con l’operazione di store del programma. Si ricorda che un file assembler deve avere estensione “.s43” e un programma C il suffisso “.c”;
  5. Ora creiamo un nuovo workspace (FILEx NEWx WORKSPACE). Dalla finestra di dialogo specifichiamo un nuovo workspace e selezioniamo l’opzione SAVE;
  6. Con (PROJECTx CREATE NEW PROJECT) creiamo un nuovo  progetto  specificando  il nome del progetto stesso e selezioniamo l’opzione CREATE;
  7. Occorre ora aggiungere il file che abbiamo appena creato al progetto (PROJECTx ADD FILE). Seleziona il file di testo e scegli l’opzione OPEN;
  8. A questo punto è necessario configurare le opzioni  del  progetto  (PROJECTx OPTIONS).  Per ogni categoria (GENERAL OPTIONS, C/C++ COMPILER, ASSEMBLER, LINKER, DEBUGGER) accettiamo la configurazione fornita da IAR e scegliamo di modificare le seguenti eccezioni:a. Specifichiamo il target device (GENERAL OPTIONSx TARGET x DEVICE);b. Abilita un progetto assembler o C/Assembler (GENERAL OPTIONSx TARGETx ASSEMBLER ONLY PROJECT);c. Selezioniamo la generazione dell’eseguibile in output (GENERAL OPTIONSx OUTPUTx OUTPUT FILEx EXECUTABLE);d. Per fare il debugging su FET (MSP430) occorre fare la seguente scelta (DEBUGGERx SETUPx DRIVERx FET DEBUGGER);e. Questa scelta comporta la definizione di una porta di connessione (FET DEBUGGERx SETUPx CONNECTION);
  9. A questo punto non ci rimane altro che fare il building del progetto, infatti con (PROJECTx REBUILD ALL).
  10. Il debug del nostro esempio è fatto utilizzando C-SPY (PROJECTx DEBUG). Con questa scelta si lancia C-SPY, non appena C-SPY prende il controllo  di EW MSP430 ottiene il controllo del target, pulisce la memoria del target stesso, programma la memoria con la nostra applicazione e resetta il target;
  11. Per lanciare l’applicazione occorre fare (DEBUGx  GO), se invece volessimo fermarla occorre fare (DEBUGx STOP DEBUGGING): in questo modo, oltre a stoppare il nostra applicativo, usciamo da C-SPY e ritorniamo al Workbench.   Con (FILEx  EXIT) usciamo  dal tool.
;******************************************************************************
; MSP-FET430x110 Demo - Software Toggle P1.0
;
; Description; Toggle P1.0 by xor'ing P0.1 inside of a software loop.
; ACLK = n/a, MCLK = SMCLK = default DCO ~ 800k
; Texas Instruments, Inc
;******************************************************************************
#include "msp430x11x1.h"
;------------------------------------------------------------------------------
ORG 0F000h ;
;------------------------------------------------------------------------------
RESET mov.w #300h,SP ; Initialize 'x1121 stackpointer
StopWDT mov.w #WDTPW+WDTHOLD,&WDTCTL ; Stop WDT
SetupP1 bis.b #001h,&P1DIR ; P1.0 output
;
Mainloop xor.b #001h,&P1OUT ; Toggle P1.0
Wait mov.w #050000,R15 ; Delay to R15
L1 dec.w R15 ; Decrement R15
jnz L1 ; Delay over?
jmp Mainloop ; Again
;
;-----------------------------------------------------------------------------
; Interrupt Vectors Used MSP430x11x1
;-----------------------------------------------------------------------------
ORG 0FFFEh ; MSP430 RESET Vector
DW RESET ;
END
Listato 1

Stack Management

La gestione dello stack è sempre un’operazione abbastanza delicata per i sistemi embedded. La quantità di spazio allocato per lo stack può essere definito o agendo direttamente attraverso EW MSP430 (GENERAL OPTIONSx STACK/HEAP) o modificando direttamente il file .xcl, il linker control file. Questo file è utilizzato dal linker per definire gli indirizzi di memoria e lo spazio allocato di Ram e Flash.

Single Step

La modalità di funzionamento sinle step è fondamentale  per  il  controllo  dell’applicazione  sotto test. Infatti, con un programma assembler questa modalità consente l’esecuzione di ogni singola istruzione; mentre, con un programma C, l’operazione consente l’esecuzione di ogni singola istruzione C. Esistono diversi varianti per il Single Step: STEP OVER, STEP OUT, NEXT STATEMENT.

Breakpoint

I breakpoint utilizzati sotto C-SPY, e quindi non in simulazione, utilizzano un numero limitato di risorse on-chip. Quando è impostato un breakpoint, l’applicazione è comunque eseguita senza restrizioni particolari, in realtime. Se, invece, non si utilizzano i breakpoints hardware, o se utilizziamo il simulatore, i breakpoints non sono più hardware, ma vengono definiti Virtual Breakpoints. Questi sono abilitati  (FET DEBUGGERx  SETUPx  USE VIRTUAL BREAKPOINTS). In questo modo l’applicazione non è più in realtime, ma offre, nel contempo,  la possibilità  di utilizzare un numero di breakpoints illimitati. La figura 2 mostra una schermata di lavoro relativo all’esempio in listato 1. È possibile notare le seguenti finestre aperte:

  • Watch, utilizzata per monitorare variabili e zone di memoria;
  • Register, per leggere/modificare  i  registri  del componente;
  • Disassembly, mostra il listing in memoria
  • Il codice sorgente;
  • La finestra di log dell’attività della sessione di lavoro.
Figura 2. IAR Embedded Workbench al lavoro con il file del listato 1

Figura 2. IAR Embedded Workbench al lavoro con il file del listato 1

CONCLUSIONE

L’ambiente di sviluppo IAR Systems è certamente un prodotto flessibile e ricco di strumenti per aiutare il programmatore nel suo lavoro di codifica/test del proprio lavoro. L’uso di MISRA C consente all’utente la verifica, in tempo reale, dell’aderenza ai criteri di certificazione adottati.

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend