InTiLinuX » Embedded

Using Open Source Tools for STR7xx Cross Development

IntiLinux — Mon, 17 Dec 2007 09:04:16 +0000

This is a work done by Giacomo Fazio (aka l3golas) and Antonio Nasca, with the purpose to explain how to develop, run and debug embedded software on a class of ST microcontrollers (STR71x, STR73x, STR75x, based on the core ARM7TDMI), using only open-source solutions. In fact nowadays there are many proprietary IDEs (IAR, RealView, etc.) which allow building and debugging of produced code on microcontrollers easily and quickly, but the licences for those IDEs are very expensive. So using free solutions (GNUARM, OpenOCD, Eclipse, etc.) that allow to compile and download code on many microcontrollers using cheap interfaces can be the best solution for that problem. Moreover, if we consider that all those solutions are open-source, you can understand how these programs are improving more and more and could have tomorrow features that today aren’t present or aren’t working properly.

This work is divided in two parts:

Relation on the work done and step-by-step tutorial about how to install and use all these open-source solutions, both in Windows and in Linux, similar to the tutorial written by James P. Lynch for the serie Atmel AT91SAM7S.
Used software (programs, scripts, etc.)

You can download here the zip file that includes everything.

Fabula, il robot umanoide

IntiLinux — Mon, 03 Dec 2007 10:20:20 +0000

Interessante simulatore di linguaggio naturale, con sintesi vocale incorporata.

Il video è stato scovato su youtube e non ho trovato nessuna notizia su questo simulatore di linguaggio naturale su internet.

Usare le board Xilinx (FPGA) su Linux

IntiLinux — Thu, 15 Nov 2007 12:11:32 +0000

La tecnologia FPGA (Field programmable gate array) è senza dubbio molto interessante, in quanto si propone come un’alternativa (in certi casi) ai circuiti ASIC (Application Specific Integrated Circuit), cioè a quei circuiti integrati che normalmente siamo abituati a vedere e che sono stati prima progettati e poi realizzati in fabbrica. Questi ultimi hanno un costo per chip bassissimo (ordine di grandezza del dollaro), parametri ottimizzati (es. bassa potenza dissipata), ma presentano molti svantaggi, tra cui cicli di progettazione e di produzione lunghissimi, costi iniziali molto elevati e impossibilità di correggere eventuali bug dopo aver prodotto il chip.
Un dispositivo FPGA, invece, è un chip che contiene una matrice più o meno grande di blocchi logici (LUT) configurabili e di canali di routing e tutto questo è programmabile sul campo. Ciò significa che potremo decidere noi quali blocchi logici utilizzare e come collegarli tra loro, in modo da scegliere noi cosa vogliamo che il nostro circuito faccia: i blocchi sono lì a disposizione, sta a noi decidere quali e come impiegarli. Le caratteristiche di questa soluzione sono: cicli di produzione molto veloci, semplice correzione di eventuali bug (grazie alla possibilità di riprogrammare il tutto), costi iniziali quasi nulli, a fronte di caratteristiche meno ottimizzate rispetto alle soluzioni ASIC (ad esempio maggiore potenza dissipata, maggiore area occupata, ecc.).
Ecco perché l’FPGA si pone come alternativa ai circuiti ASIC in determinati casi e permette tra l’altro di sperimentare divertendosi e imparando, dato che i modelli più a basso costo sono destinati soprattutto al mercato amatoriale.
Diverse aziende, principalmente Xilinx e Altera, hanno cominciato (e continuano tuttora a pieno regime) a vendere board FPGA per lo sviluppo, con caratteristiche e prezzi diversi. Si va dai modelli a più basso costo (con un numero di LUT limitato e con prezzi anche inferiori ai 100 dollari) a quelli più costosi (con un numero elevato di LUT e con prezzi che di conseguenza salgono anche parecchio). Per l’uso amatoriale vanno benissimo anche i modelli più economici, in quanto il numero di LUT è più che sufficiente.
La board che al momento sto utilizzando per un progetto universitario fa parte di quelle più a basso costo ed è il modello Spartan 3E-500 Starter Kit di Xilinx, che si presta bene a lavorare anche su Linux, in quanto il loro software ISE è sviluppato anche per il sistema operativo del pinguino, oltre che per Windows. Mi sembra quindi che si tratti di un’ottima scelta per cominciare, vediamo come far funzionare tutto.

Installazione di ISE e del driver

Scaricare il software dal sito di Xilinx (la versione ISE Webpack 9.2i è gratuita, basta registrarsi). Il pacchetto è unico perché comprende i file da installare per entrambi i sistemi operativi e si installa facilmente: basta lanciare l’eseguibile di installazione.
Qualche accorgimento: se il computer è usato da una sola persona conviene lanciare l’installer da utente normale e non da root e installare il software nella propria home; se invece il computer è usato da più persone, conviene lanciare l’installer da root e magari installare il software nella directory /opt, creare un gruppo contenente le persone che dovranno usare il software e dare a tutto il gruppo i diritti sulla directory e le sue sottodirectory.
Scegliamo i componenti da installare (ci sono dei componenti per il supporto alle varie tipologie di board, selezioniamo solo quello che ci interessa), togliamo il segno di spunta alla richiesta di installare i driver del cavo di collegamento della board al computer (in quanto lo faremo poi a parte), invece selezioniamo la ricerca di eventuali update (che ci sono quasi sempre, nel mio caso c’era addirittura un Service Pack), ricordando che per installare questi ultimi bisogna rilanciare l’installer.
Dopo aver terminato l’installazione bisogna installare i driver del cavo, e qui arrivano le dolenti note. Xilinx dichiara che i driver del cavo su Linux funzionano su distribuzioni Red-Hat like, ma con kernel superiori a 2.6.16 ci sono problemi, inoltre che fare se uno ha una Debian o una Ubuntu? Su Internet ci sono dei siti con delle guide su come riuscire a far andare i driver di Xilinx su una Debian con un kernel tra quelli più recenti, ma sono spesso ingarbugliate e bisogna usare il modulo del kernel proprietario windrvr; inoltre non è assolutamente detto che funzionino e il rischio di combinare un disastro sulla propria distribuzione è decisamente alto, soprattutto per un utente alle prime armi. Mentre stavo per convincermi a provare queste procedure, ho trovato su un sito la descrizione di un driver sviluppato da terze parti che utilizza tecnologie più recenti, funziona bene sulle distribuzioni anche con gli ultimi kernel e richiede solo qualche semplice passaggio per l’installazione. Inoltre il sito in questione dichiara che il driver funziona bene con le seguenti accoppiate:

XILINX Platform Cable USB DLC9, DLC9LP and DLC9G
Integrated Platform Cable USB on Spartan 3E starter kit
Integrated Platform Cable USB on Spartan 3A starter kit
Integrated Platform Cable USB on XUP-V2Pro
XILINX Parallel Cable IV (in Parallel Cable III compatibility mode)
Enterpoint Prog2 Parallel Cable III clone
Trenz TE0149-01 Parallel Cable III clone
Digilent JTAG3 Parallel Cable III clone
Amontec JTAGkey-Tiny (experimental)

mentre dovrebbe funzionare (anche se non è stato testato) con le seguenti accoppiate:
Integrated Platform Cable USB on other development boards

other Parallel Cable III clones
other FTDI2232 based devices which use the chips standard JTAG pinout (experimental)

Le versioni del software supportate sono le seguenti:

ISE Webpack 9.2 SP1, SP2 and SP3
ISE Webpack 9.1 SP1, SP2 and SP3
ISE Webpack 8.2 SP3
ISE Webpack 8.1 SP3
ChipScope Pro 9.2.01i
ChipScope Pro 9.1.02i and 9.1.03i
ChipScope Pro 8.2.04i
EDK 9.2.01i
EDK 9.1.01i and 9.1.02i
EDK 8.2.02i
EDK 8.1.02i
Synplicity Identify Debugger

Il mio caso è quello del collegamento tramite cavo USB ed è quello che spiegherò adesso.
Tanto per cominciare bisogna avere installato sulla propria distribuzione il pacchetto “libusb development”, su una Debian o Ubuntu o simili basta farlo mediante il comando

apt-get install libusb-dev

A questo punto bisogna scaricare e compilare il driver, alternativamente è possibile scaricare qui il driver già compilato ma è meglio se lo compilate da voi. Vediamo come:

1) scaricate il driver del cavo all’indirizzo http://git.zerfleddert.de/cgi-bin/gitweb.cgi/usb-driver?a=snapshot;h=HEAD;sf=tgz o alternativamente potete scaricarlo mediante il comando

git clone git://git.zerfleddert.de/usb-driver

dopo ovviamente avere installato git.

2) Estraete il driver mediante
tar xzf usb-driver-HEAD.tar.gz

3) Entrate nella cartella del driver
cd usb-driver
3) Lanciate:
make (se avete un sistema a 32 bit) make lib32 (se invece avete un sistema a 64 bit)

da cui otterrete il file libusb-driver.so

4) Copiate tale file in una cartella di sistema con il seguente comando
cp libusb-driver.so /usr/local/lib/ [da root]
5) A questo punto, dobbiamo creare la seguente variabile di ambiente mediante il comando
export LD_PRELOAD=/usr/local/lib/libusb-driver.so

Adesso il driver dovrebbe essere installato correttamente. Per verificare, collegare la board al pc mediante il cavo e accenderla. Subito dopo, digitare [da root]

lsusb

Tra i vari dispositivi, dovrebbe comparire anche il nostro cavo con a fianco un ID, che dovrebbe essere il seguente:

03fd:0008

A me ha funzionato subito, se è così si può passare alla sezione successiva, altrimenti vuol dire che il firmware non è installato correttamente, quindi il README del driver propone di seguire i seguenti passi (sostituisci a ISE_DIR la directory in cui hai installato ISE):

1)Se non hai il file /etc/udev/rules.d/xusbdfwu.rules, copialo dalla sottodirectory ISE_DIR/bin/lin/xusbdfwu.rules alla directory /etc/udev/rules.d/

2)installa il pacchetto “fxload” nella tua distrubuzione se non è già presente

3)copia i file ISE_DIR/bin/lin/xusb*.hex nella directory /usr/share/

4)riavvia udev mediante /etc/init.d/udev restart e ricollega la board al pc mediante il cavo; riprovando a lanciare lsusb dovresti ottenere per il cavo l’id corretto

Avvio di ISE

Una cosa da fare prima di avviare ISE è creare (da root) il file /etc/udev/rules.d/libusb-driver.rules e inserire dentro il seguente codice, in modo che anche l’utente normale possa usare IMPACT (il “programmatore” di ISE):

ACTION=="add", BUS=="usb", SYSFS{idVendor}=="03fd", MODE="666"

Lanciate il comando /etc/init.d/udev restart
Prima di usare ISE, bisogna impostare delle variabili d’ambiente. Quindi andate nella cartella dove avete installato ISE e digitate

source settings.sh (per una shell bash)

A questo punto possiamo avviare ISE mediante il comando

ise

Tuttavia, quando chiudiamo la sessione le variabili d’ambiente spariscono, quindi bisogna settarle di volta in volta. Bisogna anche settare di volta in volta anche la variabile LD_PRELOAD che avevamo settato precedentemente per il cavo. Inoltre, siccome ISE ha l’abitudine di salvare le variabili d’ambiente nella directory corrente da cui viene lanciato, sarebbe meglio fare in modo che questa directory sia proprio quella di ISE. Pertanto ho creato il seguente script, che si occupa di fare tutto ciò:

#!/bin/sh #set ISE directory, put here yours XILINX_DIR=/home/l3golas/Xilinx92i #switch to XILINX directory cd ${XILINX_DIR} #load environment variables and cable driver source settings.sh export LD_PRELOAD=/usr/local/lib/libusb-driver.so #launch ISE!!! ise

Inseriamo il suddetto codice in un file ise_launcher.sh, modifichiamo ovviamente la directory XILINX_DIR sostituendola con la propria e rendiamo il file eseguibile mediante il comando

chmod +x ise_launcher.sh

Creiamo un collegamento sul desktop a questo file in modo che, da questo momento in poi, potremo avviare ISE semplicemente da esso. E’ tutto.

Altri link da cui mi sono ispirato e su cui cercare ulteriori informazioni, ad esempio su altri tipi di cavo, sono i seguenti:

http://www.rmdir.de/~michael/xilinx/

https://wiki.kip.uni-heidelberg.de/KIPwiki/index.php/EDV:Xilinx-USB-Treiber

http://stefan.endrullis.de/en/xilinx_ise_8.2_ubuntu.html

Articolo scritto da L3golas.

FOX Board, un sistema Linux completo in soli 66 x 72 mm

IntiLinux — Wed, 26 Sep 2007 10:26:38 +0000

La FOX Board è una Board Linux Embedded a basso costo di ridotte dimensioni e bassi consumi realizzata per facilitare la progettazione ed il time-to-market di dispositivi in grado di interagire con protocolli ed applicazioni di rete ed Internet .
La FOX Board è ideale per la progettazione di dispositivi dotati di interfaccia WEB, capacità di esecuzione in multitasking, gestione di apparati USB, memorizzazione di dati e tutte le caratteristiche evolute derivanti dall’uso di un vero sistema operativo.

Caratteristiche:

Microprocessore Axis ETRAX 100 LX con architettura RISC a 32 bit 100MIPS
Fino a 32MB di RAM e 16MB di FLASH (*)
Interfacce: Una porta Ethernet 10/100Mb, due porte USB host 1.1, piazzamenti per due connettori di espansione da 20×2 pin passo 2.54 mm su cui sono disponibili fino a 48 linee
di I/O, I2C bus, SPI, porte seriali e parallele (**)

Esempio di montaggio del FoxCase, un case in plastica per Fox board:

Documentazione in formato pdf in lingua italiana disponibile a questo indirizzo.

La board è realizzata da un’azienda Italiana: Acme Systems srl – Roma
.

Using Open Source Tools for STR7xx Cross Development

IntiLinux — Fri, 10 Aug 2007 13:32:05 +0000

La Guida è stata rimossa perchè absoleta. Si prega di andare a vedere la versione aggiornata in lingua inglese.

Proviamo Sato sulla nostra Ubuntu Box

IntiLinux — Fri, 10 Aug 2007 09:54:56 +0000

Sato è un nuovo visual style per Poky Linux, la distribuzione Linux per dispositivi embendeed.
È stato sviluppato per funzionare a DPI molto alti e dimensioni limitate, adatto quindi a dispositivi come smartphones e PDAs.

Attualmente Poky Linux è installabile su Nokia N800 come dimostra questo video:

Caratteristiche di Poky Linux :

* Linux 2.6.x kernel support.
* x86 and ARM (both OABI and EABI) architecture support out the box with provision for others too .
* Complete cross-compiling toolchain generation (gcc 3.4 and gcc 4.1 supported).
* System layer with tuned Busybox, tslib, glibc2.x, Kdrive 7.1 XServer (aka TinyX) and more.
* Complete customisable and optimised GNOME Embedded platform support for DBus / Gstreamer EDS Embedded / X11/ Matchbox / GTK+ / Cairo etc.
* Optional dpkg (Debian) or Ipkg software packaging support.
* QEmu (x86 and ARM) integration.
* Release, debug, profiling and SDK filesystem image builds supported.
* Easily ported to new boards/platforms to provide an incredably well featured BSP.
* Support for OProfile performance measurements with remote graphical UI.
* Support for Linux Trace Toolkit (LTTng) for further performance debugging.
* Fast multithreaded builds (two hours for full filesystem on commodity dual core hardware)
* 100% Open Source

E’ comunque possibile provare Poky Linux e quindi Sato sulla nostra Ubuntu Box seguendo pochi semplici passi:

Aggiungiamo al nostro sources.list deb http://debian.o-hand.com feisty/ (vedi quì per repo Debian) e successivamente:

sudo apt-get update sudo apt-get install apt-get install qemu poky-scripts

Scarichiamo Poky QEMU kernel e l’immagine compressa del filesystem (deve essere decompressa successivamente).

Fatto questo ci posizioniamo nella cartella dove abbiamo scaricato i due file e eseguiamo:

poky-qemu zImage-2.6.21-blinky-3.0-qemuarm.bin poky-image-sdk-qemuarm-blinky-3.0.rootfs.ext2

Dopo il caricamento apparirà la seguente schermata:

OpenOCD : Open On Chip Debugger per soluzioni ARM

IntiLinux — Thu, 19 Jul 2007 10:39:41 +0000

OpenOCD è un programma open-source creato da Dominic Rath in occasione della propria tesi di laurea. Funziona sia da interfaccia TTY (via Telnet) per la connessione di un pc ad un dispositivo embedded, che da GDB server. Vediamo di chiarire entrambe le funzioni.
Per quanto riguarda la connessione ad un target ARM, si utilizza il protocollo JTAG. Tocca ad OpenOCD interfacciarsi con il target, ma c’è un problema: il PC non possiede una porta JTAG, al contrario sono presenti le normali porte parallele, seriali e USB, dunque è necessario un ulteriore componente che converta i segnali inviati da OpenOCD attraverso queste porte in segnali JTAG da inviare alla porta JTAG presente sul target. Questo componente è la JTAG hardware interface e ne esistono diversi tipi forniti da svariati produttori (Wiggler, JTAGkey, Signalyzer, ecc.).
Per quanto riguarda la funzione di GDB Server, è necessario dapprima dire qualcosa sul funzionamento di GDB. GDB (GNU Debugger) è il debugger standard del software system GNU e consente di tracciare l’esecuzione di un programma permettendo all’utente di settare dei breakpoints per bloccare l’esecuzione in qualsiasi momento; inoltre GDB consente il controllo dei valori assunti da ciascuna variabile e registro, che è possibile sia visionare che modificare. Una funzionalità presente in GDB è il “remote debugging”, che consente di controllare da una macchina (GDB client) l’esecuzione di un programma che avviene su un’altra macchina (GDB server); la comunicazione tra client e server avviene mediante un protocollo message-based chiamato RSP (Remote Serial Protocol) che sfrutta una connessione, ad esempio TCP: in pratica il GDB server deve rimanere in ascolto su una porta TCP, in attesa dei comandi che arrivano dal GDB client. E’ proprio questa la funzionalità utilizzata per effettuare il debugging su dispositivi embedded: l’applicazione viene eseguita sul dispositivo embedded e controllata dal computer, che in questo caso funge da GDB client. Ma per fare ciò è necessario un GDB server a livello del dispositivo embedded, ed è qui che il cerchio si chiude: OpenOCD svolge anche il ruolo di GDB server.
Le due funzionalità sono ovviamente collegate, dato che quando OpenOCD si comporta da GDB server ricevendo comandi di debugging da un GDB client, deve poi mandare questi comandi al processore ARM mediante la porta JTAG, ed ecco che entra in scena la sua funzione di interfaccia con il target.
Mostriamo un’applicazione pratica per chiarificare e sintetizzare quanto detto, supponendo di effettuare il debugging sul nostro dispositivo embedded e di voler vedere il valore di una certa variabile: il debugger (GDB client) invia la richiesta mediante RSP ad OpenOCD (GDB server), che come abbiamo detto funge anche da interfaccia verso il dispositivo, quindi converte l’istruzione in comandi del protocollo JTAG, che spedisce mediante le normali porte USB/parallela del PC alla JTAG hardware interface; questa a sua volta converte i segnali ricevuti in segnali JTAG a 3.3 V da inviare all’apposita porta sulla board; Il valore richiesto viene letto e viene rimandato indietro mediante il percorso opposto. Lo schema seguente mostra quanto detto:

Per quanto riguarda il processore ARM, le versioni ARM7 e ARM9 di cui ci occupiamo sono provviste di una speciale unità Embedded-ICE, ossia un circuito hardware che implementa sul chip le principali operazioni di debug mediante l’uso di due circuiti di breakpoint/watchpoint interni : ecco perchè se la nostra applicazione gira sulla FLASH possiamo effettuare il debug di essa, leggere la memoria e utilizzare due (e non più) breakpoints, il tutto senza ricorrere a soluzioni costose e limitanti dal punto di vista delle performance.

Questo articolo è il primo di una serie di articoli che interesserà il mondo dei processori embedded e in particolare quelli basati su architettura ARM.

L’articolo è stato scritto da L3golas (giacomofazio@tiscali.it)