Ou comment faire de la même façon que ce que l'on fait depuis des années, mais avec du matériel récent. Je possède une carte HiFive1 depuis quelques mois sans pour l'instant avoir pris la peine d'essayer de la programmer.
https://www.sifive.com/boards
L'intérêt de cette carte de développement est qu'elle est basée sur un processeur Freedom E310. Bon, me direz-vous. Cela n'est pas faux. En fait c'est du RISC-V, un jeu d'instruction libre, c'est à dire qu'il peut être copié et implémenté à peu près ou l'on souhaite, donc dans du FPGA. Sur la carte HiFive, c'est une version 32 bits qui tourne à plus de 300MHz. Le tout dans un boitier dont la surface occupée correspond à peu près à celle d'un ATmega328p qui équipe les cartes Arduino, du 8 bits à 16MHz donc. Pour fonctionner ce petit processeur E310 à besoin d'une mémoire externe de programme. Sur la carte, c'est à une EEPROM qu'est dévolu ce rôle.
Le programme chargé dans la carte se contente de faire varier la couleur d'une LED RGB. C'est joli, ça prouve que ça fonctionne et... rien de plus. Il était donc temps d'au moins tester une suite de développement dédiée à ce type de processeur. Ça tombe bien, SiFive propose directement la suite Eclipse avec compilateur adapté. A remarquer que pour une fois, cette suite est fournie sans installation. On télécharge l'application, on 'click' sur l'exécutable et c'est prêt! Rien à voir avec d'autres fournisseurs dont la mise en place de la solution de développement requiert à elle seule une équipe de plusieurs personnes pendant un certain nombre d'heure...
Le test qui 'tue' : charger l'application en mode Debug, et effectuer une séance de débogage. Et bien, mis à part une ou deux étranges subtilités de la suite Eclipse fournie par SiFive, le test est rapide à mener et s'avère de suite concluant :
Alors non seulement ça fonctionne, mais en plus c'est rapide. Pour mes tests, j'ai utilisé un PC équipé d'un ancien processeur Core 2 Duo à 3GHz (un E7500) et de 4Go de mémoire sous Windows 7/64. Muni d'un SSD, la machine est suffisamment véloce pour une utilisation confortable de la suite logicielle. Point besoin donc d'un octo-core à 4 GHz, de 128Go de ram, et de l'infâme Windows 10!
Comme le système fonctionne, je suis allé au bout du concept et ai répondu favorablement à la question posée par les développeurs de chez SiFive :
D'autres exemples sont fournis par SiFive. Cette solution matérielle et logicielle semble donc facile à utiliser, tout du moins aussi facile qu'une carte Arduino. Je vais d'ailleurs effectuer des tests personnels avec les périphériques embarqués afin d'en savoir un peu plus sur ce processeur.
A noter qu'il existe aussi une 'distribution' Arduino pour cette carte mais uniquement utilisable sous Linux, le compilateur utilisable par le système Arduino ne semble pas être, pour l'heure, disponible sous Windows.
Et pour commencer, un peu de Forth. Je ne vais pas détailler ici ce langage avec sa syntax en polonaise inverse, mais vous trouverez un début de son historique sur Wikipédia : https://fr.wikipedia.org/wiki/Forth_(langage). La question que l'on peut se poser est de se demander sur quel type de plateforme matérielle il serait possible d'expérimenter ce langage. Je ne poserai pas non plus la question de l'intérêt d'un tel langage, sachant que tout passionné d'informatique y trouvera matière à découverte, expérimentation et... satisfaction!
Il y a quelques années de cela j'ai développé une petite carte d'expérimentation à base de processeur NXP LPC1114FN28 :
Cette carte propose tout ce qu'il faut pour mener diverses expérimentations électroniques sans avoir à se soucier du câblage minimum nécessaire à la mise en fonction du processeur. Un simple câble USB et un terminal série suffit pour développer du code sur ce matériel. Le processeur utilisé ici n'est malheureusement plus disponible. NXP ayant arrêté la fabrication de cette version en boitier DIP. Ce type de processeur à cœur ARM M0 existe bien évidemment sous d'autres formats de boitier.
Comme je possède un certain nombre de ce processeurs LPC1114FN28 mais aussi de LPC810FN8, voici donc l'occasion de corriger les quelques petites imprécisions du circuit, histoire de finaliser effectivement le concept :
Repris et modifié d'une ancienne version de Kicad vieille de quelques années, avec la nouvelle version 5 sortie il y a quelques semaines. L'occasion aussi de rencontrer quelques légers 'bugs' de jeunesse de cette nouvelle version de Kicad.
Matthias Koch a développé un interpréteur Forth pour une multitude de plateformes matérielles dont ce processeur LPC1114. Le fichier hexadécimal directement programmable dans ce processeur ARM se trouve sur https://sourceforge.net/projects/mecrisp/. Il y a quatre ans la version disponible était la 2.1.3. Nous sommes passés à la version 2.4.5. C'était donc l'occasion de vérifier le bon fonctionnement de cette nouvelle version.
Pour programmer cet interpréteur Forth dans le LPC1114FN28, il suffit d'utiliser le logiciel Flash Magic disponible à cette adresse : http://www.flashmagictool.com.
Une fois fait, le démarrage du système ne pose aucun problème. A noter qu'avec l'interface USB de tye FTDI utilisée sur la carte de développement, il est nécessaire d'effacer les signaux RTS et DTR qui sont positionnés par défaut. Cela se fait très facilement en utilisant le logiciel RealTerm par exemple :
Dès lors que ces deux signaux sont effacés, le message d'invite apparaît :
La première chose à faire par la suite, consiste évidemment à faire clignoter une LED, le fameux 'Hello World', de l'embarqué :
Le code source directement envoyé à l'interpréteur est le suivant :
\ Blink a LED on P0.3$4004402C constant IOCON_PIO0_3$50003FFC constant GPIO0_DATA$50008000 constant GPIO0_DIR
: blinky ( -- )
$00IOCON_PIO0_3! \ SetP0.3 as GPIO without Pullup/Pulldown.8GPIO0_DIR! \ SetP0.3 as Outputbegin8GPIO0_DATA!10000000doloop0GPIO0_DATA!10000000doloop
key? until
;
A noter que le source diffère quelque peu de celui fourni en exemple avec la distribution Forth de Matthias Koch en ce sens que la LED intégrée à la carte de développement n'utilise pas le même port.
Ici il ne s'agit pas du port PIO1_8, mais du port PIO0_3. Contrairement à mes tests effectués il y a quatre ans maintenant ou j'avais connecté une LED sur le port PIO1_8, j'ai cette fois directement modifié le code source pour coller directement avec la réalité matérielle. Cela consiste principalement à modifier l'adresse des trois registres du processeur afférant au port PIO0_3 :
Pour trouver facilement l'adresse des ces ports, il 'suffit' de rechercher un fichier 'include' sur le net du genre LPC11xx.h et de reconstruire les adresses à partir des données trouvées dans ce fichier. La plupart du temps, il s'agira d'une adresse de base à laquelle il suffit d'ajouter un offset.
Exemple de fichier de déclaration des ressources d'un processeur de type LPC11XX :
Le code ainsi modifié à fonctionné immédiatement. La LED clignote un peu plus rapidement qu'au Hertz malgré deux boucles d'un million d'itérations, soit 2 millions d'itérations par seconde. Pas mal pour un processeur qui fonctionne à à peine plus de 10MHz!
Remarque intéressante : il existe une instruction compiletoflash qui permet de rendre le code permanent. Quelques informations peuvent être trouvées au sujet de ce système sur le site de Jean-Claude Wippler https://jeelabs.org/2015/07/22/forth-on-a-dip/.
A tester, notamment la liaison série et un afficheur LCD par exemple.
A suivre...
UPDATE [01 novembre 2018] Autre plateforme de test.
La version DIP28 du LPC1114 fournie par NXP est dorénavant obsolète, cependant le LPC1114 existe toujours en version 28 pattes en boitier TSSOP (LPC1114FDH28/102) au prix de 2,13€ chez Mouser et en boitier LQFP48 (LPC1114FBD483021) au prix de 2,60€HT toujours chez Mouser (pub gratuite). Il y a quelques années de cela, j'avais acheté chez WaveShare une petite carte de développement à base de ce processeur LPC1114 en version 48 pattes LQFP :
Cette carte possède une interface de type SWD pour la programmation du processeur. J'avais bien envie de tester ce type de programmation mais cela implique l'achat d'une interface de programmation, parfois à prix élevé. Segger propose une interface assez simple à utiliser puisque se connectant au port USB d'un PC et proposant une interface multiple pouvant fonctionner en mode SWD, il s'agit de l'interface de programmation J-Link :
J'ai acquis cette interface il y a quelques années et, ne m'en étant jamais servi, j'ai pensé que sa mise en pratique sur cette carte de développement était bienvenue.
Le 'seul' petit problème de cette interface de programmation est qu'elle n'est pas prise en compte par le programme graphique J-Flash :
C'est bien dommage et frustrant. 50€ en gros pour cette version de J-Link et plus de 400€ pour finalement la même version mais programmée avec un firmware 'acceptable' par ce logiciel graphique, bof! Il va donc falloir utiliser l'appareil en ligne de commande, version 'old style' DOS :-(
Mais bon, cela fonctionne, et puis pour un besoin simple de programmation cela suffira. Il convient donc lancer une session 'DOS', de configurer le processus de programmation puis de lancer la programmation de la flash du processeur. Un compte rendu express d'une session typique de programmation peut se résumer à ceci :
En gros cela se résume à sélectionner le type d'interface de programmation de type SWD, à choisir le processeur ainsi que la vitesse de l'interface de programmation. Par la suite, la programmation se lance par la simple commande 'loadfile', suivi du fichier *.hex dans mon cas, ainsi que l'adresse flash ou doit se loger le programme, 0x80000000 dans le cas du LPC1114.
Photo du montage avec le programmateur J-Link :
Force est de constater que la programmation se déroule de façon très rapide et très efficace. Afin de préparer la petite carte à recevoir le logiciel Forth, j'y ai raccordé un câble USB/Série TTL de chez FTDI en version 3,3V. Une fois la programmation du processeur effectuée, une session terminale se déroule de la même façon qu'avec la carte de développement que j'ai développé :
J'y ai donc téléchargé le petit programme de clignotement d'une LED, cette fois sans l'adapter à l'une des quatre LEDs présent sur la carte. J'ai tout simplement connecté une LED externe munie de sa résistance de limitation au port PIO0_3 de la carte. le lancement du clignotement de la LED se fait tout simplement par la commande 'Blinky', invoquant le programme précédemment envoyé à l'interpréteur Forth. Et de nouveau, aucun problème, tout fonctionne comme prévu.
Conclusion n° 1(provisoire) : J'ai mis un certain temps à me décider à utiliser l'interface J-Link ainsi que cette carte de développement. En fait, arriver à un résultat concluant m'a pris moins de temps que celui nécessaire à la rédaction de cet update. Je suis toujours impressionné par la rapidité de ce Forth embarqué. J'avais prévu l'utilisation d'un afficheur LCD comme prochaine étape de ma découverte de ce langage de programmation. Je maintiens donc cet objectif suivant.
Conclusion n°2 : j'ai voulu tester la programmation de cette carte WaveShare par la méthode série et bootloader. Le câble FTDI ne fournissant pas l'ensemble des signaux nécessaires à cette configuration, j'ai donc récupérer l'ensemble du bus sur une de mes cartes de développement. Le bus est constitué des signaux TX, RX, DTR et RTS.
Photo du montage de programmation par liaison série et bootloader:
J'utilise donc cette fois le logiciel Flash Magic :
Cela me permet de vérifier le bon fonctionnement de l'ensemble. Une demande de signature de circuit me renvoi l'information suivante :
Cela semble se passer correctement. Il ne reste plus qu'à effacer le composant et à le programmer de nouveau avec le firmware Forth :
La programmation semble s'être bien passée. J'avais laissé la vitesse de communication à 9600 bauds par défaut. Les opérations de programmation et de vérification prennent donc significativement plus de temps qu'avec l'interface SWD de l'outil de programmation Segger J-Link. D'instantané, ou quasi, par le biais de la liaison série le processus complet prend presque 30 secondes à 9600 Bauds.
Après vérification, le firmware Forth est correctement installé dans le processeur. Le téléchargement du programme Blinky fonctionne aussi parfaitement :
Cette façon de faire est un peu plus artisanale, puisqu'un certain nombre de bouts de fils sont à connecter en l'air. Par contre, le coût de l'ensemble est très significativement moins élevé que la solution Segger. L'interface graphique fournie par FlashMagic est largement suffisante et bien plus pratique que le mode DOS imposé par Segger avec sa version EDU de l'interface J-Link.
A noter par contre, que l'interface Segger est en mesure d'effectuer du débogage temps réel avec le logiciel approprié, même en version EDU. Ce qu'est bien évidemment incapable de faire la solution de programmation par liaison série. Cela n'est d'ailleurs pas son objectif.