ALLER PLUS LOIN :
Premières expériences ColdFire (µC 32 bits)

Quelles différences par rapport à nos µC 8 bits HC(S)08 ?
Les Coldfire, processeurs 32 bits sont répartis en deux types, les microcontrôleurs (MCU) et microprocesseurs (MPU). La différence fondamentale est que les MPU n'embarquent pas de flash, la sram sur la puce sert essentiellement de cache au CPU. Les MCU ne disposent donc pas de module de gestion de mémoire externe.
Certains de ces MPU sont très puissants (jusque 300Mhz), et embarquent des coprocesseurs mathématiques. Cependant, ils ont tous un « grand parent » commun : le MC68000.
Cette « ancienneté » fait qu'il existe de très nombreux outils libres sur le net pour ces MCU, y compris un compilateur C/C++ de la collection GCC (GNU Compileur Collection) des logiciels libres GNU (acronyme récursif GNU is Not Unix).
CPU :
Sans rentrer dans la description de la structure du modèle de programmation, il faut cependant mentionner que là où le CPU HC08 a un accumulateur (A) (le S12 a également B) et un registre d'index (X) avec un pointeur de pile (SP), le ColdFire a 8 registres généraux de données 32 bits (D0 à D7) et 8 registres d'adresse 32 bits (A0 à A7). Le registre A7 sert de pointeur de pile. Douze modes d'adressage, assez similaires à ce que l'on trouve sur les HC sont disponnibles. Pour une description détaillée, on se réfèrera au liens donnés dans la partie « assembleur »
Pour les instructions, quelqu'un connaissant les HC ne tombera pas en terrain inconnu; les mnémoniques étant fort similaires (pas de movlwf et autres btfsc...-beurk)
A noter une instruction MAC (Multiply-ACcumulate, qui permet des opérations a=a+b*c) qui optimise les calculs DSP (et autres)
Les performances :
Les MCF sont des processeurs « RISC », bien que cette notion soit relative.
Ils sont répartis en familles sous les dénominations suivantes : MCF5XYY où X est la version du « coeur » : il y a actuellement V2,V3,V4. Une extension vers le haut (V5) est prévue . YY définit le modèle dans la famille. MCF signifie Motorola ColdFire.
Le gros problème, pour l'amateur en tous cas : le boîtier. Le plus « facile » est le QFP, qui existe en QFP 64 au pas de 0,5. Il y a aussi des QFP80 au pas de 0,65.. ouf.
Parmi cette famille nombreuse, j'ai donc choisi de porter mon attention sur la série MCF5213 (comprenant aussi MCF5211 et 5212). Le 5212 est identique au 5213 à l'exception du fait qu'il n'a pas de module CAN (réseau, pas ADC). Le 5211 est un 5212 avec mémoire moitié. Ce sont les « bas de gamme » -Low cost Coldfire.
http://www.freescale.com/webapp/sps/s ... ?code=MCF5213&fsrch=1
Le 5213/5212 possède 32ko de ram et 256ko de flash. Des MCU avec 1Mo de Flash sont prévus dans 2-3 ans (voirs les roadmaps)
Leur horloge va jusque 80 Mhz bus (76 MIPS), et le prix (farnell) se situe à une douzaine d'euros hors taxe, soit un peu comme les « anciens » HC11.
Il faut noter que des nouveaux MCU continuent d'apparaître, avec notamment des interfaces PHY (ethernet) et/ou USB OTG (On -The-Go). 22 nouveaux MCU sont sortis fin 2007. Une version V1 (MCF51Q128) est sortie mi-2007. Ces MCF V1 sont parfaitement compatibles du point de vue périphériques avec les 9S08. Cependant le CPU est un vrai ColdFire 32 bits. D'après mes premiers essais, il y a un facteur 10 (comme annoncé par Freescale) en vitesse de traitement.
Le mapping mémoire.
C'est ce qui m'a le plus dérouté. Sur les HC08, les adresses des regsitres des périphériques, de la ram et de la Flash sont biens définis, de même que les vecteurs d'interruption qui commencent à FFFF.
Sur les MCF, il faut définir les adresses de base, via les regsitres :
RAMBAR (Ram Base Adresse Register), mise à 0x20000000 le plus souvent sur les MCF5213.
FLASHBAR, normalement 0x00000000
IPSBAR (Registres des périphériques), normalement 0x40000000
VBR : Vector Base Register, qui donne l'adresse des vecteurs d'exceptions (ou interruptions). A noter que les deux premier « vecteurs » sont : La valeur initiale de PC (program Counter) et du SP (pointeur de pile). En général, les vecteurs sont placés en début de flash (donc à l'adresse 0x00000000)
Toutes les adresses seront donc définies par rapport à ces registres.
Tout autre valeur nécessite de très bonnes connaissances en programmation (ce qui n'est pas mon cas; j'utiliserai donc ces valeurs qui me conviennent d'ailleurs parfaitement)
Ces valeurs sont chargées au reset, c'est la première action qui est effectuée.
Bref, pour revenir au 5213, voici sa structure interne (tirée de la datasheet) :Je ne détaillerai pas les modules, suffisamment décrits dans la datsheet, mais pour fixer les idées sur l'aspect « professionnel « de ces µC, on peut par exemple signaler que le convertisseur A/D est sur 12 bits.
Le matériel que je me suis procuré consiste en :
- Une carte M5211DEMO, en vente à 86 euros sur le site de Farnell. L'avantage de cette carte est qu'elle inclut un BDM P&E.
Une (enfin 2-3) carte M5213BADGE. Elles ne sont plus en vente chez freescale, ce sont des cartes très similaires aux M5213EVB, sans le transceiver Zigbee. En vente chez Future Electronics, mais je m'en suis procuré à très bas coût (25 euro pièce + port) sur Ebay

Elles n'ont pas de BDM, mais un debugger série incorporé dBUG (voir programmation assembleur ci après). C'est un excellent débugger, qui réalise tout ce que peut faire un IDE moderne, sauf que c'est sous forme « ligne de commande » via un terminal série. J'ai utilisé un adaptateur USB-série et une carte PCMCIA RS232 sur mon PC portable, tous les deux vont très bien.
Le bus CAN est disponnible sur un connecteur DB9.
Le connecteur BDM est sur l'image ci-dessus sur le côté gauche: 26 (13x2) pins, mais pas de panique, seulement 10 sont utilisées.
LA PROGRAMMATION ASSEMBLEUR
Voici les documents de référence en français, que je recommande de télécharger et de bien lire (ils ne sont pas très volumineux :
Une excellente description du ColdFire et de l'assembleur :
http://extraerg.enserg.fr/fr/form/m8/ ... nformatique2A_2006-07.pdf
Le cours de joris Dedieu, un cours ASM détaillé :
http://joris-dedieu.developpez.com/
Un assembleur (bien que ne respectant pas strictement les conventions GNU peut être trouvé) :
http://www.austexsoftware.com/softwaretools.html
1. Voici le programme de calcul fact.s , du site de l'enserg, de la factorielle d'un nombre (ici, 6), adapté à l'assembleur utilisé: directives, commentaires avec « ; » au lieu de « | » Le programme et la variable res sont localisé en RAM, après les 8k occupés par le debugger.
On voit des mnénoniques fort semblables à ce qui est connu : MOVE, JSR, BEQ, MULS, ADD, NOP, RTS,..

2.L'assemblage se fait sur le PC par une ligne de commande dans une fenêtre DOS : cfasm -l fact.s , avec l'option -l pour avoir un listing
L'assembleur produit un fichier « fact.o » qui est en fait un S19 (l'ouvrir pour s'en persuader)

3. L'étape suivante consiste maintenant à se connecter à la carte d'essai MCF5213 via la connection série, avec un terminal, qui sera paramétré comme ci-après.
J'utilise pour ma part « tera term », plus facile à paramétrer que le terminal win.

Le contrôle du flux doit être mis sur XON/XOFF
La carte d'éval MCF5213 contient un débugger en flash. C'est le debugger dBug. Il est en téléchargement libre sur le site de freescale. C'est le fichier « M5213EVB_DBUG_BIN.zip ». La source est également fournie. Les commandes sont bien détaillées dans le mode d'emploi de la carte.
Il faut préciser les choses suivantes :
- dBug occupe 80Ko de Flash et 8Ko de ram. Son utilisation sur M5211DEMO est donc un peu « juste »: Sur le MCF5213, il reste donc 24Ko de ram et 176Ko de Flash.
- Par défaut, le téléchargement des programmes dans le ColdFire se fait en ram. La partie utilisateur de la ram commence à l'adresse 0x20002000. C'est la raison du « org 0x20002000 du programme ci-dessus. Il y aurait eu moyen de le mapper en Flash, mais il aurait fallu le télécharger puis en ram puis le copier en flash avec la commande « fl »
Si il est effacé par mégarde, la seule façon de le recharger est via BDM. CFflasher ne fonctionnant pas avec le TBLCF, cela ne peut donc se faire qu'avec CodeWarrior.
La séquence des opérations à effectuer est la suivante :
A la mise sous tension, la carte effectue un reset. Il y a également un bouton qui permet de resetter la carte.
a) downloader le programme (fact.o) avec la commande « dl » puis aller dans le menu « file » de tera term » et sélectionner « send file.. » puis fact.o.
b) mettre un point d'arrêt à une des dernières instructions NOP. Comment trouver l'adresse de celle-ci : faire « dis 0x20002000 » deux fois, on repèrera les instructions NOP aux adresses 0x20002036 et 0x20002038.

On place donc un point d'arrêt : br 20002036
On lance le programme à l'adresse go 20002004 , pas 20002000 car à cette adresse, j'ai réservé une variable de 32 bits « RES » : voir l'asm.

Le programme s'arrête bien à 20002036, qui est une instruction « NOP » opcode 4E71.
Le résultat du calcul est dans D3 et vaut 2D0 (720= 6!)
Le PC est bien arrêté à 20002036
Voilà, une très brève introduction au debugger dBUG. Très convivial, très simple d'emploi, il y a moyen de bien s'amuser.
Tous les registres des périphériques sont accessibles/modifiables via la commande irmd. La table des vecteurs se trouve en début de ram (si j'ai bien compris). Si l'on veut modifier ou voir les registres de l'UART0, la commande ser irm uart0
A noter que dBud est une cible native de GDB. Bien que ne l'ayant pas encore essayé, il doit être possible de debugger un ColdFire avec GDB par la liaison série.
Pas encore de carte ColdFire ? Pas grave- Il existe un émulateur « tournant » sur PC (remarquer la similarité des commandes).
Cet excellent émulateur est telechargeable à l'adresse (prendre la dernière version « Cygwin »):
http://www.slicer.ca/coldfire/download.php

Cet émulateur émule un MCF5206, ce qui est ennuyant et à la fois pas trop, s'agissant d'un coeur V2.
PROGRAMMATION CODEWARRIOR ET BDM.
Le problème du BDM
Si le BDM P&E pour HCS08-HCS12 était encore abordable pour l'amateur (99USD) , celui pour le ColdFire ne l'est plus du tout (enfin, pour moi : 250 USD). Donc 2 solutions :
- « Extraire » un BDM d'une carte M5211DEMO
- Construire un Open Source BDM :
Daniel Malik a heureusement réalisé un BDM style TBDML, c'est le TBLCF:
http://forums.freescale.com/freescale ... CFCOMM&message.id=624
Voici ma réalisation, exactement suivant le PCB de D. Malik :
Cout: environ 10 euros, à partir de JB16 (SOIC 20). Programmation par bootloader USB.
Je ne détaillerai pas la construction, programmation du JB16 et le paramétrage de CodeWarrior, mais le fonctionnement est sans souci et immédiat tel que décrit dans le manuel. Une liaison 10 (j'ai utilisé un cable souple) pins est suffisante.
Attention, il faut au minimum la version CodeWarrior 6.3 (qui est la version actuelle 04/2007)
Justement, en ce qui concerne Code Warrior, la version « Special Edition » est limitée à 128K, ce qui devrait couvrir la (grande) majorité des réalisations amateur.
Attention, l'utilisation de CW pour ColdFire est assez bien différente de celle des HCS08 et HCS12 (il faut par exemple programmer le Coldfire manuellement).
Une bonne description de la « prise en main » est décrite dans le document :
http://www.freescale.com/files/graphi ... _SEMINAR_PRESENTATION.pdf
à partir de la page 87 : « Getting started with CodeWarrior ». La lecture de ce paragraphe et du mode d'emploi du tbdlCF de D. Malik permettra de rendre celui-ci opértaionnel en une heure.
Pour la carte M5213EVB, ouvrir le projet qui se trouve dans le folder :
C:\Program Files\Freescale\CodeWarrior for Coldfire V6.3\(CodeWarrior_Exemples)\M5213EVB
Il s'agit d'un simple programme qui fait un « chenillard » avec les 4 leds de la carte et qui envoie sur le port série UART0 « Hello World ».
Pour la carte M5211DEMO, il y a un « projet similaire » livré sur le CD de celle-ci.
Il est bon de s'entraîner à :
- Compiler le projet M5213EVB
- Effacer la Flash du M5213EVB
- Programmer le projet sur M5213EVB
Ne pas oublier le cavalier « BDM Enable » de la carte de démo. Pour ma part, n'y ayant plus pensé, j'y ai perdu 3 heures à me demander ce qui ne fonctionnait pas.
Et quand tout refonctionne correctement, avec le tool « flash programmer de CW », on pourra reprogrammer le debugger dBUG série de MCF5213EVB qui se trouve là :
http://www.freescale.com/webapp/sps/s ... summary.jsp?code=M5213EVB
En cette fin 2007, une nouvelle version de CodeWarrior pour MCF est en développement chez Freescale (V 7.0), elle similaire d'emploi à le version 6 for microcontrolleurs pour les MC9S08 et MCF V1 actuele... En attendant la version unifié de CW (9S08, 9S12, MCF V1,V2,V3,V4), annoncée pour 2008.
Les outils indispensables (en téléchargement libre sur le site FSL):
CFflasher :
Petit utilitaire qui programme et/ou efface , examine la flash du µC (malheureusement, ne semble pas fonctionner avec le TBLCF). Simple et efficace.

Installé en 5 minutes, fonctionnement dans le même délai.
COLDFIRE_INIT (Cfinit) de micro-APL (2006).
Fantastique !!! L'équivalent du « processor expert ». Génère les « projets » au format CodeWarrior ou GNU, en assembleur ou C.
Attention, pour des raisons que je ne connais pas, la programmation des registres périphériques se fait via des « masques » et/ou. Bien que cela soit un peu déroutant, c'est au final beaucoup plus lisible.

Programmation/Debug GCC
Les outils de développement ColdFire ont la particularité d'être extrèmement couteux, et je ne suis pas prêt à mettre l'équivalent d'une petite voiture pour posséder une chaine de développement de luxe.
Cependand, comme expliqué plus haut, il existe une chaine gcc, qui comprend un compilateur et un débugger (gdb) : m68k-elf-gcc
Cependant, ce compilateur fonctionne :
- en ligne de commande
- sous LINUX
- Le problème linux peut être résolu par CigWIn, qui permet l'émulation d'une machine virtuelle linux sous win32
L'environnement Eclipse (www.eclipse.org) permet de construire un environnement de développement graphique professionnel. Les difficultés principales de la mise au point d'une telle chaine sont :
- le makefile
- le script de linker.
- Les routines de bas niveau, en asm (chargement des RAMBAR, FLASHBAR,...)
- Les définitions (en asm) des vecteurs d'exception (interruptions)
Ce dernier point constitue le difficulté principale : rappel, les paramètres xxxBAR, sui sont et peuvent définis de plusieurs manières différentes (dans le script du linker pour CW); les fichiers exécutables au format « elf » (Executable and Linkable File) et j'en passe des meilleures.
La mise au point d'une telle chaine sont décrits ici :
et ici :
http://www.cambridgeimaging.co.uk/Coldfire%20IDE.pdf
Suivre pas par pas et méticuleusement toutes les étapes, vous aurez à la fin un IDE d'une qualité professionnelle comprenant debugger et compilateur d'une qualité professionnelle, sans limitation de taille de code.
Malheureusement, l'exemple fourni est simpliste (même simplissime) et ne permet pas de mettre en oeuvre facilement au moins un « template minimal » pour le développement de projets 5211/5213. De plus, si le BDM P&E est supporté, le tblcf de D. Malik ne l'est actuellement pas.
Je travaille actuellement sur ce sujet. Je serai obligé, pour la mise au point de cette chaine d'utilser la carte M5211DEMO, pour le BDM P&E.
Ceci fera l'objet d'un second article, celui-ci étant déjà assez long. (et pas trop indigeste, j'espère).
A cette occasion, je réaliserai également une carte d'essai perso MCF5212; cette carte d'essai étant dans l'état actuel des choses, une M5211DEMO dont j'ai désoudé le MCF5211 et mis un MCF5212 à la place (ainsi qu'un quartz) . Y ayant chargé dBUG de la carte M5213EVB, celui-ci fonctionne parfaitement.

thierry