Difference between revisions of "SSV DNP5370 (Blackfin)"

From Electrolab
Jump to: navigation, search
(Architecture du logiciel embarqué)
(Blackfin DNP5370)
Line 1: Line 1:
 
== Blackfin DNP5370 ==
 
== Blackfin DNP5370 ==
 +
Retour à [[Projets:Perso:2013:Module de localisation]]<br />
 
=== µCLinux et cross compilation ===
 
=== µCLinux et cross compilation ===
 
Le code du Blackfin est développé en C sous linux. La portabilité entre Linux et µCLinux permet de développer et tester son code sur hôte dans un premier temps (PC) puis ensuite sur cible une fois que les principales fonctions sont opérationnelles. Il n’y a pas de modification majeurs entre un code hôte et un code cible, tout se joue essentiellement au niveau des interfaces et du Makefile. Il est nécessaire de « bouchonner » les interfaces et d’utiliser un Makefile spécifique à la machine exécutant le code.<br />
 
Le code du Blackfin est développé en C sous linux. La portabilité entre Linux et µCLinux permet de développer et tester son code sur hôte dans un premier temps (PC) puis ensuite sur cible une fois que les principales fonctions sont opérationnelles. Il n’y a pas de modification majeurs entre un code hôte et un code cible, tout se joue essentiellement au niveau des interfaces et du Makefile. Il est nécessaire de « bouchonner » les interfaces et d’utiliser un Makefile spécifique à la machine exécutant le code.<br />

Revision as of 23:41, 11 March 2014

Blackfin DNP5370

Retour à Projets:Perso:2013:Module de localisation

µCLinux et cross compilation

Le code du Blackfin est développé en C sous linux. La portabilité entre Linux et µCLinux permet de développer et tester son code sur hôte dans un premier temps (PC) puis ensuite sur cible une fois que les principales fonctions sont opérationnelles. Il n’y a pas de modification majeurs entre un code hôte et un code cible, tout se joue essentiellement au niveau des interfaces et du Makefile. Il est nécessaire de « bouchonner » les interfaces et d’utiliser un Makefile spécifique à la machine exécutant le code.
La fonction d’un Makefile est de compiler le(s) fichier(s) source au format machine afin de pouvoir les exécuter. Un Makefile est associé à un exécutable, ainsi qu’à un type de machine.
Un fichier Makefile en C sous Linux se nomme Makefile.nom, nom étant l’identifiant du Makefile.
Les fichiers Makefile peuvent être édités sous Kate aisément, leur typologie étant cependant différentes d’un fichier C standard (Un Makefile n’est pas dédié à un code C). Aujourd’hui, ce type de compilation est en règle générale intégrée à l’environnement de développement.
Un fichier Makefile définit les variables suivantes :

  • CROSS : Chemin du compilateur ainsi que des dépendances associées, par exemple les fichiers headers utilisés à la compilation,
  • CC : nom de l’exécutable du compilateur,
  • EXEC : Nom de l’exécutable produit à l’issue de la compilation,
  • OBJS : définit les fichiers objets à créer pour pouvoir générer l’exécutable. Les fichiers objets sont définis par le nom du fichier source avec le suffixe « *.o »,
  • CFLAGS : paramètre du compilateur, utilisé pour définir certaines caractéristiques à appliquer au code lors de la compilation (par exemple pour assurer la reproductibilité de la compilation, qui peut varier en fonction des machines ou des recompilations, etc.).
  • LFLAGS : Idem.

Les fichiers sont ensuite compilés un par un, en utilisant la structure :

$(CC) $(CFLAGS) -c nom_de_la_source.c

Puis une compilation globale est lancée pour créer les exécutables :

$(CC) $(LFLAGS) -o $(EXEC) $(OBJS) -lm

Un Makefile s’exécute par la commande make –f Makefile.nom. Il est possible de lancer plusieurs Makefile à la suite en utilisant un script shell.
Un exemple de Makefile est présenté ci-dessous :

/***********************************************************************************/

CROSS	  = /opt/opt/uClinux/bfin-uclinux/bin/bfin-uclinux-
CC	  = $(CROSS)gcc
EXEC	  = SCH_PROC
OBJS      = SCH_main.o SCH_calcul.o SCH_process.o SCH_time.o GEN_IPC.o SCH_RS232.o ITF_calcul.o COM_calcul.o
CFLAGS	  = -O2
LFLAGS    = -Wl,-elf2flt

all: 
	$(CC) $(CFLAGS) -c SCH_main.c
	$(CC) $(CFLAGS) -c SCH_calcul.c
	$(CC) $(CFLAGS) -c GEN_IPC.c
	$(CC) $(CFLAGS) -c SCH_process.c
	$(CC) $(CFLAGS) -c SCH_time.c
	$(CC) $(CFLAGS) -c SCH_RS232.c
	$(CC) $(CFLAGS) -c ITF_calcul.c
	$(CC) $(CFLAGS) -c COM_calcul.c
	$(CC) $(LFLAGS) -o $(EXEC) $(OBJS) -lm
#-----------------------------------------------
clean: 
	rm -f *.o *.gdb *.elf $(EXEC)

/***********************************************************************************/
Ce Makefile permet la compilation d’un code C pour une exécution directement sur une cible de type Blackfin en µClinux. L’exemple ci-dessous est utilisable pour une exécution sur PC x86 :
/***********************************************************************************/

PATH	  := $(PATH):/usr/bin:/usr/local/bin
CC	  = gcc
EXEC	  = SCH_PROC
OBJS      = SCH_main.o SCH_calcul.o SCH_process.o SCH_time.o GEN_IPC.o SCH_RS232.o
CFLAGS 	  =  -Wall 

all: $(EXEC)

$(EXEC): $(OBJS)
	$(CC) $(CFLAGS) -O3 -o $@ $(OBJS) -lc -lm
	chmod 777 $@
	
#-----------------------------------------------

clean: 
	rm -f $(EXEC) *.elf *.gdb *.o

/***********************************************************************************/
A noter, il n’est pas nécessaire de compiler les fichiers source pour en faire des fichiers objets dans ce cas, la compilation est automatique.
Ce type de compilation sera utilisé par exemple pour le débogage de l’application et des fonctionnements internes du système avant son déploiement sur cible.

Script Shell

Les batch shells sous linux sont des exécutables en lignes de commande, très pratique pour automatiser des opérations de type copie de fichier, insertion de noyau ou ouverture de droits.
Un batch doit toujours être nommé : nom.sh. Il s’exécute par la commande : sh nom.sh
Il doit toujours commencer par la commande #!/bin/sh en tête du fichier de script. Ci-dessous des exemples de commande standard utilisables en shell, même si en principe toutes les commandes batch sont utilisables en shell (en principe, cf remarques ci-après) :
Insertion de modules dans le noyau :

  • insmod i2c-dev.ko
  • insmod i2c-bfin-twi.ko
  • insmod can.ko

Compiler plusieurs exécutables :

make clean
#nettoyage des fichiers existants, plus propre
make -f Makefile.INIT_target
make -f Makefile.CAN_target
make -f Makefile.SCH_target

Le script ci-dessous permet d’envoyer les fichiers exécutables ainsi que les fichiers nécessaires à l’exécution, comme les scripts par exemple, sur la cible via un lien ftp (ultra secure certes mais bon…)

ftp -i -n -g <<END_SCRIPT
open 192.168.0.126
#adresse de l’équipements cible
user nom_user mot_de_passe
#user suivit du nom utilisateur et mot de passe pour se connecter à la cible. 
type binary
lcd /home/mael/Travail/drone/drone_labo #dossier origine
cd /media/mmc #dossier cible
system
send CAN_PROC
chmod 777 CAN_PROC
send INIT_PROC
chmod 777 INIT_PROC
send SCH_PROC
chmod 777 SCH_PROC
send i2c-bfin-twi.ko
chmod 777 i2c-bfin-twi.ko
send i2c-dev.ko
chmod 777 i2c-dev.ko
send can.ko
chmod 777 can.ko
send autostart_target.sh
chmod 777 autostart_target.sh
END_SCRIPT

On ouvre une communication ftp, on se logue, puis on indique source ert origine des fichiers.
La procédure est d’envoyer le fichier avec la commande « send » puis de le rendre exécutable avec « chmod 777 ».
  Remarque :

  • La commande stty –icanon, permettant de passer des commandes à un terminal sans utiliser [Entrée] pour valider, ne peut pas être utilisée dans un batch car elle doit être entrée dans le terminal lui-même,
  • La commande sudo chmod 0777 /dev/ttyUSB0 par exemple visant à donner un accès en lecture/écriture à un port, nécessite les droits admin (d’où le sudo). Dans le cas où une commande de ce type est passée dans un shell, le mot de passe sera demandé en plus dans tous les cas dans le terminal.

Architecture du logiciel embarqué

Le logiciel embarqué sur le blackfin est conçu sur la base de processus fonctionnant en parallèle, disposant chacun de fonctions particulières. Les fonctions sont activées séquentiellement par le scheduler sur la base de registres d’activation partagés, et associés chacun à un processus.
Les données sont créées sur la base d’un même fichier de définition, et l’échange de données entres fonctions et processus se fait exclusivement par IPC, des zones de mémoire allouées et partagées entre toutes les fonctions.

Présentation de l'architecture Blackfin

L’architecture du logiciel embarqué sur le Blackfin est présentée dans le schéma ci-dessous :