mardi 21 août 2018

blue pill, MECRISP Forth

MECRISP est un Forth développé par Matthias Koch originalement pour les µC MSP430 mais a été depuis porté sur de nombreuses plateformes. Dans cet article j'installe MECRISP sur une carte blue pill et le met à l'essaie.

Les références utilisées pour cet article sont les suivantes.

Installation de MECRISP sur la carte blue pill

Le projet MECRISP est sur sourceforge. Il faut télécharger le fichier https://sourceforge.net/projects/mecrisp/files/mecrisp-stellaris-2.4.4.tar.gz/download et le décompresser.

$ tar -zxf mecrisp-stellaris-2.4.4.tar.gz
Vous devriez lire le fichier README qui se trouve dans le répertoire racine de MECRISP. Il contient des informations utiles comme une brève description de chaque mot du vocabulaire de base.
On va dans le répertoire contenant les fichiers du stm32f103
$ cd mecrisp-stellaris-2.4.4/stm32f103
$ ls
1w.fs lcd-ptinting.fs si4432_spi.fs
font16x30.fs mecrisp-stellaris-stm32f103.bin si-test.fs
lcd-base.fs mecrisp-stellaris-stm32f103.hex stm32f103.fs
lcd-graphics.fs precompiled
Le fichier mecrisp-stellaris-stm32f103.bin est celui qu'on va utiliser pour programmer la carte blue pill en utilisant l'utilitaire st-flash avec la commande write.
st-flash write mecrisp-stellaris-stm32f103.bin 0x8000000
st-flash 1.4.0-47-gae717b9-dirty
2018-08-13T16:57:12 INFO usb.c: -- exit_dfu_mode
2018-08-13T16:57:12 INFO common.c: Loading device parameters....
2018-08-13T16:57:12 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-08-13T16:57:12 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-08-13T16:57:12 INFO common.c: Attempting to write 15696 (0x3d50) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08003c00 erased
2018-08-13T16:57:12 INFO common.c: Finished erasing 16 pages of 1024 (0x400) bytes
2018-08-13T16:57:12 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2018-08-13T16:57:12 INFO flash_loader.c: Successfully loaded flash loader in sram
16/16 pages written
2018-08-13T16:57:13 INFO common.c: Starting verification of write complete
2018-08-13T16:57:13 INFO common.c: Flash written and verified! jolly good!
Il n'y a pas de message d'erreur tout semble avoir fonctionné. il s'agit maintenant de connecter la carte blue pill à un adapteur USB-RS232 car l'interface utilisateur de MECRISP est un terminal RS-232.

Utilisation de MECRISP FORTH

Pour voir la liste des mots du dictionnaire MECRISP consultez le fichier README. En plus des mots commun à toutes les plateformes il y a une section pour chaque µC pour les mots spécifiques à chacun.

Au démarrage MECRISP compile les nouveaux mots dans la mémoire RAM. Donc à la réinitialisation les nouvelles définitions sont perdues. Une fois qu'une définition est testée on peu la redéfinir en mémoire flash. Le mot compiletoflash permet de compiler en mémoire flash. Le mot compiletoram permet de revenir à la compilation en mémoire RAM. Pour savoir si la compilation à lieu en mémoire RAM il y a le mot compiletoram? qui retourne -1 si c'est le cas sinon retourne zéro.

branchement de la carte au port sériel.

Il n'y a que 4 fils à brancher.

description
GND commun de l'alimentation
3v3 alimentation pour la carte et l'adapteur RS-232
TX broche A9 de la carte va à RX de l'adapteur RS-232
RX broche A10 de la carte va à TX de l'adapteur RS-232.
mon installation de base

J'utilise minicom pour la communication entre le PC et la carte. Ouvrons un terminal et lançons minicom.

$ minicom -D/dev/ttyS0 -b115200
L'option -D indique quel port sériel utilisé pour la communication avec la carte blue pill.
L'option -b indique la vitesse de communication, soit 115200 BAUD.
Bienvenue avec minicom 2.7

OPTIONS: I18n
Compilé le Feb 7 2016, 13:37:27.
Port /dev/ttyS0, 09:32:44

Tapez CTRL-A Z pour voir l'aide concernant les touches spéciales
En mettant la carte blue pill sous tension la ligne suivante apparaît dans la fenêtre terminal.
Mecrisp-Stellaris 2.4.4 for STM32F103 by Matthias Koch
Il n'y a pas d'invite de commande en Forth on a donc simplement le curseur qui clignote au début de la ligne. En tapant la touche <ENTER> au terminal le message suivant s'affiche.
ok.
ok. n'est pas une invite de commande c'est un message de confirmation que la dernière commande a été interprétée sans erreur. Encore une fois le curseur clignote au début de la ligne suivante. Forth est toujours prêt à recevoir une nouvelle commande après que le message ok. a été affiché. S'il se produit une erreur un message est affiché à l'écran et l'interpréteur est réinitialisé en vidant les piles.
exemple: 

567 .ok
\ voyons l'état de la pile .ok
.s Stack: [1 ] 42  TOS: 567  *>                                             
 ok.                                                                            
\  le nombre 567 a ete empile  ok.                                              
xyz xyz not found.                                                              
\ xyz n'est pas un mot reconnu  ok.                                             
.s Stack: [0 ]  TOS: 567  *>                                                    
 ok.                                                                            
\ la pile est vide
Le mot .s sert à afficher le contenu de la pile de arguments. Comme on le voie lorsqu'on entre un entier il est simplement déposé au sommet de la pile. TOS signifit Top Of Stack, i.e. Sommet de la pile. Sur la première ligne j'ai saisi 567 et cet entier a été déposé au sommet de la pile.

Sur la deuxième ligne j'ai saisi xyz. L'interpréteur de commande n'a pas trouvé ce mot dans le dictionnaire, il affiche donc le message not found et vide les piles. Notez que TOS indique toujours 567. Cependant .s indique bien que la pile contient [ 0 ] éléments. La façon dont la commande .s travaille peu prêter à confusion. .s affiche toujours un élément de trop. Cet élément est le contenu de la mémoire RAM pointé par le pointeur de pile lorsque la pile est vide. Ainsi dans la première utilisation de .s le nombre 42 est indiqué alors qu'il ne fait pas partir des arguments disponibles. Dans le deuxième appel .s indique 567 au sommet alors que la pile est vide. Il faut considérer ça comme un bogue de la commande .s.

Maintenant on va créer un programme pour faire clignoter la LED verte qui est sur la carte. Cette LED est branchée sur PC15. C'est à dire le port C bit 15. 

\ les constantes pour les addresse des SFR tel 
\ que trouvé dans manuel de référence du STM32F103C8t6                                                          
$40011000 constant gpioc_crl  ok.                                               
$40011004 constant gpioc_crh  ok.                                               
$40011010 constant gpioc_bsrr  ok.                                              
$40011014 constant gpioc_brr  ok.                                               
$44644444 gpioc_crh !  ok.                                                      
: led_on ( -- ) \ allume led verte  ok.                                         
  13 pwr2 gpioc_brr ! ;  ok.                                                    
: led_off ( -- ) \ eteint led verte  ok.                                        
  13 pwr2 gpioc_bsrr ! ;  ok.                                                   
: delay ( u -- ) \ busy loop  ok.                                               
  1000 * 0 do i drop loop ;  ok.                                                
: blink ( speed -- ) \ clignote led verte jusqu'a touche enfoncee  ok.
  begin led_on dup delay led_off dup delay key? until key 2drop ;  ok.          
100 blink  ok.                                                                  
50 blink  ok.

Je suis curieux de savoir comment MECRISP configure le system clock En consultant le manuel de référence on trouve 2 registres pour la configuration du clock, Clock Control Register rcc_cr et Clock Configuration Register rcc_cfgr Je vais définir les constantes pour ces registres et le mot prt-field pour voir le contenu binaire d'un champ du registre. 

$40021000 constant rcc-base-adr \ adresse de base rcc  ok.                      
rcc-base-adr constant rcc-cr \ offset 0  ok.                                    
rcc-base-adr 4 + constant rcc-cfgr \ offset 4  ok.                              
rcc-cfgr @ h. 0  ok.                                                            
rcc-cr @ h. 4A83  ok.
Les valeurs affichées pour rcc-cr et rcc-cfgr sont les valeurs à la réinitialisation du µC donc MECRISP ne confugure par le clock ce qui signifie que blue pill avec MECRISP fonctionne en utilisant l'oscillateur interne avec une fréquence de Fclock de 8 Mhz.

Un brin de Folie

Travailler directement dans minicom n'est pas pratique en autre pour corriger les erreurs ou inclure des fichiers source Forth. Heureusement Jean-Claude Wippler auteur du blog Jeelabs a créer une console sérielle pour nous faciliter la tâche. Cette console s'appelle Folie. Nous allons donc l'installer et l'utiliser à la place de minicom.

Des binaires de l'application sont disponible ici.

  1. Téléchargé le fichier folie-linux-x64.gz
  2. dézipper le fichier
  3. rendre le fichier exécutable
  4. créer un lien dans mon dossier ~/bin avec un nom plus court.
  5. Se déplacer dans le dossier mecrisp-Stellaris qui contient le fichier stm32f103.fs
  6. Lancer folie en indiquant le port sériel utilisé.
gunzip folie-linux-x64.gz
chmod +x folie-linux-x64
ln  "/home/jacques/Documents/blue pill/mecrisp/folie-linux-x64"
 /home/jacques/bin
cd "~/Documents/blue pill/mecrisp/mecrisp-*/stm32f103"
folie -p /dev/ttyS0
ok.

J'utilise geany comme éditeur. Geany reconnais les fichiers avec l'extension .fs comme étant des fichiers Forth et fait la coloration de la syntaxe. J'ai créer le fichier picatout.fs avec quelques définitions de mon cru.

Je vais d'abord compiler de fichier dans la mémoire RAM pour le tester et lorsque les erreurs seront corrigées je le compilerai dans la mémoire flash. Il suffit de faire la commande: 

include picatout.fs
Pour compiler le fichier. Folie ne semble interpréter les fins de lignes correctement. J'ai essayé avec des fins de lignes LF, CR et CRLF et aucune ne fonctionne correctement cependant la compilation fonctionne sans erreur même si l'affichage est défectueux. Testons les nouveaux mots. 
\ combien de mots dans le dictionnaire?  ok.
wc u. 350  ok.
\ flash libre?  ok.
flash-free u. 48800  ok.
\ ram-libre?  ok.
ram-free u. 19472  ok.
\ impression en binaire  ok.
45 bin. 101101  ok.
\ extraction d'un champ  ok.
45 3 3 bitfield bin. 101  ok.
\ puissance de 2  ok.
15 pwr2 u. 32768  ok.
Les définitions fonctionnent en va les flasher. 
forgetram \ efface les mots en RAM
compiletoflash \ compile en flash
include picatout.fs \ compile le fichier en flash
compiletoram \ revient à la compilation en RAM

Dans le dossier mecrisp-stallaris-2.4.4/stm32103 il y a plusieurs fichiers .fs qui peuvent-être inclus. Celui nommé stm32f103.fs contient la définitions des constantes pour toutes les adresses des registres spéciaux du stm32f103c8t6. Il y en plus de 500. Après cette inclusion, wc rapporte 852 mots et flash-free 32928 octets libres.

NOTE:
Je ne sais pas si le problème est avec mon ordinateur mais lorsque je fais une commande include dans Folie, quelque secondes après la fin de l'opération le disque dur de mon ordinateur se met à trasher et l'ordinateur ne répond plus m'obligeant à l'éteindre. C'est à 3ième fois que je recommence la section de cet article consacrée à Folie, hum!!

installation de hackaday-forth

A lieu d'installer MECRISP de base vous pouvez installer la version hackaday-forth.

  1. Clonez le dépôt sur votre ordinateur
    git clone https://github.com/hexagon5un/hackaday-forth
  2. Déplacez-vous dans le dossier ROMS et faites la commande:
    st-flash write mecrisp-stellaris-hackaday-edition.bin 0x8000000
    Cette version prend beaucoup plus de mémoire flash, il ne reste que 31744 octets pour les applications.
  3. Lancez minicom si ce n'est pas déja fait
Hackdaday-forth Configure le µC pour qu'il fonctionne à sa fréquence maximale de 72 Mhz. Vous trouverez dans ce dépôt plusieurs exemples de programmes.

retour à l'introduction
Publié par Aucun commentaire:

blue pill, programmation en C

Dans cet article j'explique comment programmer la carte blue pill sans autre outils que ceux fournis par l'open source gnu-arm-none-eabi. Cet article est une adaptation de l'article en anglais produit par Jacob Mossberg. Même si l'article original réfère à une carte STM32-H103 et un programmeur ARM-USB-OCD-H, les outils logiciels et la procédure sont les même pour la carte blue pill et le programmeur STLINK/V2 que j'utilise.

Installation des outils logiciels

  • Les utilitaires pour travailler avec les fichiers binaires. Sur mon système la version la plus récente est 2.26.1 
    
sudo apt install binutils-arm-none-eabi
  • Le compilateur GCC. Sur mon système la version la plus récente est 5.4.0 
    
sudo apt install gcc-arm-none-eabi
  • Le débogueur. Sur mon système la version la plus récente est 7.11.1 
    
sudo apt install gdb-arm-none-eabi
Jacobs Mossberg mentionne aussi la possibilité d'utiliser la toolchain fournie par ARM.

Compiler le programme exemple

Téléchargez les 3 fichiers exemples fournis par Jacobs Mossberg.

  • Le code d'initialisation du µC startup.c
  • Le fichier pour le linker stm32.ld
  • Finalement le fichier makefile.
  • Dans mon dépôt blue_pill dans le dossier C il y a les fichiers blink.c et stm32f103c8.h que je vais utiliser comme programme de démonstration.

compiler le programme.

  1. J'ai modifié le fichier makefile
  2. Sur la ligne de commande à partir du dossier contenant les fichiers sources il suffit de faire la commande: 
    
make build
    pour créer le fichier blink.bin
  3. La commande suivante suppose que la carte blue pill est branchée au stlink/v2 et que ce dernier est branché au PC. 
    
st-flash write blink.bin 0x8000000
Sitôt l'opération complétée la LED verte devrait clignoter à environ 1 cycle par seconde. Essayez le bouton reset de la carte si ça ne fonctionne pas d’ambler.

Déboguer un programme avec gdb et stlink/v2

Le programme est déjà déboguer mais on va supposer qu'il ne l'est pas et on va le recompiler pour le débogage avec la commande 

make build_debug
st-flash write blink.bin 0x8000000
La différence entre la version débogage est que le compilateur n'optimise pas le code et le fichier blink.elf contient toute l'information qui permet à gdb de faire le lien entre les lignes du code source et le code exécuté sur le µC. Si vous utilisez une version non debug de blink.elf, gdb va afficher le message [ no source code available ].

Séance de débogage

Dans la console déjà ouverte on lance: 

st-util
Il faut ouvrir une 2ième console de commande (maximisez la fenêtre) et dans cette nouvelle console lancez gdb. Par défaut st-util utilise le port 4242 il faut donc configurer gdb pour qu'il utilise aussi ce port. 

arm-none-eabi-gdb -tui --eval-command="target remote localhost:4242" blink.elf

Les commandes les plus utiles sont les suivantes:

  • hbreak arg, pour créer un point d'arrêt matériel. Comme argument on peut utiliser le nom d'une fonction ou un numéro de ligne.
    exemples: 
    
(gdb) hbreak main
(gdb) hbreak main.c:29
  • continue ou c, pour relancer l'exécution. S'il n'y a pas de point d'arrêt faire <CTRL-c> pour arrêter l'exécution.
  • step ou s, pour exécuter une seule ligne de code.
  • next ou n, même chose que step mais saute les appels de fonctions.
  • layout regs, pour ouvrir une fenêtre qui affiche le contenu des registres du CPU.
  • print var, pour imprimer le contenu d'une variable.
  • delete, pour supprimer les points d'arrêt.
  • clear no|nom, pour supprimer un point d'arrêt par le numéro de ligne no ou le nom de la fonction.

Une meilleure version de blink

Cette version de blink est loin d'être idéale car elle utilise une boucle de code pour le délais. Ce qui fait que le délais varie en fonction de l'optimisation du code par le compilateur et aussi avec la fréquence du clock. Pour améliorer le programme on va utiliser une minuterie et pourquoi pas brancher la sortie PC13 à un PWM ainsi une fois l'initialisation complétée le µC n'aura plus rien à faire. Au va profiter de l'occasion pour configurer le clock à 72 Mhz en utilisant l'oscillateur externe et le PLL au lieu de l'oscillateur interne.

2018-09-01

J'ai terminé la version améliorée de blink. Elle est dans le dossier blink_v2. Cette version utilise le cristal externe avec le PLL pour obtenir une fréquence SYSCLK maximale de 72 Mhz. Le CPU Cortex-M3 possède un compteur interne de 24 bits incrémenté à la fréquence du clock AHB ou AHB/8. J'ai configuré se compteur pour produire un délais d'une milliseconde avec la fonction millisec() qui est appelé par la fonction delay() qui détermine la fréquence de clignotement de la LED.

Voici la nouvelle version de blink_v2.c

Une autre amélioration à apporter serait d'ajouter une interruption sur le coretimer et de créer un variable globale systicks qui serait incrémmentée à l'intérieur de cette interruption à toute les milliseconde.

2018-09-03

J'ai ajouté systick_demo. Ce programme démontre comment installer une routine d'interruption. La routine d'interruption systick_int incrémente la variable ticks et décrémente la variable timer si sa valeur est non nulle. systick_int gère l'interruption du coretimer qui est programmée pour se produire à intervalle de 1 milliseconde.

2018-09-16

Je poursuis mes expérimentations de programmation bare metal de la blue pill en C. j'ai ajouté plusieurs démos dans le dépôt git

  • Expérimentation avec le core timer
  • Expérimentation avec les interruptions
  • Expérimentation avec le RTC
  • Expérimentation avec les appels systèmes.

retour à l'introduction
Publié par Aucun commentaire:

mercredi 4 juillet 2018

projet VPC-32V

Dans cet article je présente mon dernier projet. Il s'agit d'un petit ordinateur fabriqué autour d'un PIC32MX170F256B.

En fait il s'agit d'une reprise d'un projet qui date de 2013 et que j'avais abandonné. Fin janvier 2018, je l'ai repris en apportant de nombreuses modification à la plateforme matérielle ainsi qu'au logiciel. Depuis janvier
je travaille presque à tout les jours sur ce projet et dernièrement j'en suis rendu à la documentation qui est elle-même presque complété.

Je ne donnerai pas beaucoup de détail dans cet article car j'ai créer un site web qui lui est dédié: https://picatout.github.io/vpc-32v/index.html

Voici un vidéo de démonstration filmé en remote console avec capture vidéo en utlisant Kazam sur Ubuntu.



Liens

source du projet.

Publié par Aucun commentaire:
S'abonner à : Messages (Atom)