Aller au contenu

Bico64/Comprendre le cycle de développement

Leçons de niveau 15
Une page de Wikiversité, la communauté pédagogique libre.
Début de la boite de navigation du chapitre
Comprendre le cycle de développement
Icône de la faculté
Chapitre no 2
Leçon : Bico64
Chap. préc. :Hardware
Chap. suiv. :Installer l'environnement de développement
fin de la boite de navigation du chapitre
En raison de limitations techniques, la typographie souhaitable du titre, « Bico64 : Comprendre le cycle de développement
Bico64/Comprendre le cycle de développement
 », n'a pu être restituée correctement ci-dessus.

Pour programmer un petit processeur il faut plusieurs étapes que l’on va devoir répéter à chaque modification.

Tout d’abord, nous allons écrire un programme dans un langage informatique relativement indépendant du processeur utilisé. Dans notre cas, nous allons utiliser le C qui est un langage assez vieux, pas forcément génial, mais très utilisé. Le processus de compilation est le suivant:

éditer le source

[modifier | modifier le wikicode]

Il faut si possible un éditeur qui soit bien fait pour le source, avec coloration syntaxique. J'utilise Context qui est gratuit et qui a tout ce qu’il faut, y compris de quoi lancer la compilation et montrer où se trouvent les erreurs. Cette étape est évidemment celle qui prend le plus de temps au programmeur et là où il va aussi passer le plus de temps à ce dire "mais pourquoi ça ne marche pas?". On verra plus loin des Bico64#Exemples de programmes.

En C on peut écrire dans un fichier .c

 Position = Position + Vitesse;;

compiler le source

[modifier | modifier le wikicode]

Comme le langage C est indépendant d'un processeur, la première chose à faire est de traduire tout cela dans un autre langage qui est lui dépendant du processeur: l'assembleur. L'assembleur est un langage où chaque ligne est une instruction du processeur. Toutefois, c’est encore un langage lisible par un humain (entrainé) où on peut encore nommer les routines et les variables, ce qui fait que l’on n'a pas besoin de mémoriser les codes des instruction ou de faire de savant calcul pour savoir à quel endroit se trouve quelle routine. Techniquement parlant, le compilateur pourrait passer directement à la génération de code, mais c’est plus facile pour ceux qui écrivent le compilateur de traduire en assembleur puis de laisser l'assembleur traduire en code machine.

Le compilateur utilisé est SDCC qui est un compilateur Open Source supportant les PIC

À la sortie du compilateur on aura un fichier .asm qui peut ressembler à cela

;      .line 87; "test02.c" Position = Position + Vitesse;
       BANKSEL r0x101B
       MOVF    r0x101B,W
       ADDWF   r0x101A,F

À ce stade, il est inutile de comprendre ce que chaque ligne veut dire, mais on remarque qu’il met une ligne de commentaire (commence par un ;) en montrant ce qu’il veut traduire puis il met les instructions processeurs nécessaires à faire cela.

Ce programme prend le fichier assembleur et le traduit directement en code machine, ce qui est facile puisque le langage assembleur est directement le reflet des codes qui peuvent être compris par le processeur. En même temps, l'assembleur traduit des "labels" (= des noms donnés par le programmeur) en adresses dans le but d’éviter des calculs fastidieux pour le programmeur. Bien que l’on utilise souvent un langage comme le C, on peut tout à fait aussi programmer en assembleur.

À la sortie de l'assembleur, on aura un fichier .o ce fichier n’est pas fait pour être lu par un humain.

Il y a aussi un fichier .lst: il n'est fait que pour un humain pour bien comprendre comment l'assembleur a fait la traduction en code machine

                                ;.line	87; "test02.c"	Position = Position + Vitesse;
000012 1283     bcf   0x3, 0x5  BANKSEL r0x101B
000013 1303     bcf   0x3, 0x6            
000014 083b     movf  0x3b, w   MOVF    r0x101B,W
000015 07ba     addwf 0x3a, f   ADDWF   r0x101A,F

(édition de liens en français): si on a plusieurs morceaux d'assembleurs qui ont été traduits en code machine (des .o), il faut encore les mettre ensemble et les reconnecter si nécessaire. De plus, il faut regarder où mettre ces différents morceaux en mémoire, ce qui peut changer suivant le schéma électronique réalisé et l’utilisation qui est faite du processeur.

À ce stade, on obtient un gros tas de bytes qui n'ont plus qu’à être chargé en mémoire. Ce gros tas de bytes se trouve dans un fichier "hexa" avec l'extension .hex

:020000040000FA
:1000000000008A110A12AD28053083120313BA00CA
:100010001D2083120313BB012030FE000030FF00BF
:1000200000302520831203133B08BA07BB0A3A08A5
:100030008312031387000C2808008316031386011C
:1000400087018801FF308500080083120313B20086
:100050007F08B1007E08B000FE30B300B40110305C

Charger le code

[modifier | modifier le wikicode]

On va charger le code dans le processeur à l'aide d'un programmateur: cet outil est complètement différent d'un fabricant de processeur à l'autre et permet de mettre en mémoire le programme. Dans notre cas, il s'agit du PICkit 2 qui permet de programmer la majorité des processeurs PIC.


Toutes ces étapes doivent être refaites à chaque fois que l’on modifie le programme (donc souvent, car cela ne marche pas souvent du premier coup!). Il est donc important de bien automatiser toutes ces étapes pour qu'on ait le minimum de manipulation à chaque cycle.

  • Dans le cas de SDCC, il a déjà prévu de compiler, assembler, linker de manière automatique
  • Le PICkit2 a un programme qui permet de lui dire de regarder lorsque le fichier