Développer sur STM32 avec stm32plus, OpenOCD et QtCreator

Cet article décrit très rapidement la procédure que j’ai suivie ( durant de nombreuses heures de tatonnements ) afin de mettre en place sous Linux Mint un environnement de développement pour stm32f042 basé sur QtCreator, stm32plus et OpenOCD, permettant de s’affranchir des logiciels ST.

Installation de la bibliothèque stm32plus

Cloner le dépot git situé à l’URL suivante :

https://github.com/andysworkshop/stm32plus

Installer les dépendances nécessaires :

$ apt install libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib scons gdb-multiarch cmake

Compiler la bibliothèque stm32plus : Exécuter la commande suivante dans le dossier stm32plus en modifiant si nécessaire le type de MCU, le mode ( fast, small ou debug ) ainsi qu’en précisant la fréquence en Hz de l’oscillateur interne ou externe utilisé (paramètre hsi ou hse)

$ scons mode=debug mcu=f042 hsi=8000000 -j4

Installer la bibliothèque compilée :

$ sudo scons mode=debug mcu=f042 hsi=8000000 -j4 install

Corriger les problèmes de stm32plus avec CMake :
Dans le dossier /usr/local/arm-none-eabi/lib/stm32plus-040100
Pour éviter un problème de fichier non trouvé, éditer le contenu du fichier stm32plus-config.cmake pour ne conserver que les 2 premières lignes ( copiées ci dessous )

include(${CMAKE_CURRENT_LIST_DIR}/stm32plus-config-${STM32PLUS_CONFIGURATION}i.cmake
OPTIONAL RESULT_VARIABLE STM32PLUS_CONFIG_FILE)

Modifier le fichier stm32plus-config-debug-f042-8000000i.cmake ( modification à répéter pour chaque version de stm32plus compilée ) : ajouter --specs=nosys.specs aux variables CMAKE_C_FLAGS et CMAKE_CXX_FLAGS.

Répéter éventuellement avec les autres modes pour disposer de la bibliothèque compilée pour chaque mode

Configuration générale de QtCreator

Récupérer l’exemple de compilation avec CMake fourni avec stm32plus dans le dossier stm32plus/cmake/example

Activer le plugin Bare Metal

Dans QtCreator : Aide -> Plugins, activer « BareMetal », et redémarrer QtCreator

Ajouter OpenOCD

Dans les options de QtCreator, catégorie « Appareils Mobiles », onglet « Bare Metal », cliquer « Add » et sélectionner « OpenOCD », remplir ainsi :
Name : OpenOCD for STM32F042
Startup mode : Pipe mode
Executable file : openocd
Root script directory : /usr/share/openocd/scripts
Configuration file : /usr/share/openocd/scripts/board/st_nucleo_f0.cfg

Puis cliquer sur Appliquer

Ajouter le périphérique STM32F042

Dans les options de QtCreator, catégorie « Appareils Mobiles », onglet « Périphériques », cliquer « Ajouter » et sélectionner « Bare Metal Device », remplir ainsi :

Nom : STM32F042
GDB Service Provider : OpenOCD for STM32F042

Cliquer sur appliquer

Ajouter le debugger GDB-Multiarch

Dans les options de QtCreator, catégorie « Kits », Onglet « Debugger », cliquer sur « Add » et remplir les champs suivants :

Name : GDB Multiarch
Path : /usr/bin/gdb-multiarch

Cliquer sur Appliquer

Ajouter un Kit

Dans les options de QtCreator, catégorie « Kits », Onglet « Kits », cliquer sur « Ajouter » et remplir les champs suivants :
Nom : STM32F042
Device type : Bare Metal Device
Device : STM32F042
Compiler C : GCC (C, arm 32 bits in /usr/bin)
Compiler C++ : GCC (C++, arm 32 bits in /usr/bin)
Debugger : GDB Multiarch
Qt Version : None
Cmake tool : System CMake at /usb/bin/cmake
CMake Configuration : cliquer sur « change », puis supprimer la ligne commençant par CMAKE_PREFIX_PATH

Cliquer sur appliquer

Configuration d’un projet QtCreator

Se rendre dans le dossier où l’on a précédemment copié l’exemple CMake fourni avec stm32plus

Ouvrir le fichier CMakeList.txt avec QtCreator, et sélectionner le kit STM32 précédemment créé.

Editer le fichier CMakeList.txt pour refléter le MCU utilisé ainsi que le mode ( fast, small ou debug ) de compilation de stm32plus à utiliser. Spécifier aussi la fréquence de l’oscillateur, suivi de la lettre i ou e pour un oscillateur interne ou externe.

Dans mon cas, ce dossier était inexistant, j’ai copié le dossier system depuis l’example Blink ( sans CMake ), dans lequel j’ai renommé le dossier f042_48_8 en f042.

Renommer le fichier system/f042/startup.asm en system/f042/startup.s. Modifier le fichier CMakeList.txt pour refléter ce changement.

Dans la catégorie « Projet », sélectionner la variable CMAKE_PREFIX_PATH, et cliquer sur « unset », puis « Apply configuration change ». La variable doit se remplir avec le contenu suivant :

/usr/local/arm-none-eabi;/usr/arm-none-eabi

Dans QtCreator, Menu « Compiler », cliquer sur « Executer CMake ».

Il est maintenant (enfin) possible de compiler et de débugger le projet 🙂

Développer sur PSP en 2020

En 2004, Sony commercialisait la PSP, une console de jeu portable qui, pour un tarif d’environ 200€, possédait des capacités de traitements ( graphiques notamment ) bien supérieures à celles de la concurrence.

Aujourd’hui, il est possible de s’en offrir une d’occasion en déboursant moins de 50€. J’ai donc décidé de m’y intéresser, non pas en temps que console de jeu, mais comme plateforme de développement.

Les sécurités de la console ayant été contournée assez rapidement, la scène du développement amateur a produit de nombreux Homebrew, ainsi que les outils permettant de développer sur la console sans acheter le ( très onéreux ) SDK officiel.

Cet article a pour vocation de résumer mon parcours quant à l’installation logicielle nécessaire.

Lire la suite

ESP32 : Un script bash pour paramétrer les variables d’environnement

Attention : valable uniquement pour les versions de ESP-IDF non basées sur CMAKE ( versions < 4.0 )

Travaillant actuellement sur un projet nécessitant une interface audio en bluetooth, je me suis tourné vers la solution la plus en vogue, l’ESP32.

Embarquant Wifi, Bluetooth (dont BLE), un CPU dual core avec 4 Mo de Flash, mais également très abordable, il dispose également d’un SDK entièrement open-source, très bien documenté !

La procédure d’installation de ce SDK nécessitant de modifier certaines variables d’environnement ( en particulier la variable PATH ), et n’aimant pas modifier des éléments aussi critiques du système ( il est possible en modifier de PATH de remplacer certaines commandes du système à l’insu de l’utilisateur ! ), j’ai donc, avant toute expérimentation avec l’ESP32, pris le temps d’écrire un petit script bash.

Ce script permet de démarrer un nouvel interpréteur BASH contenant les variables d’environnements permettant le bon fonctionnement du SDK ESP32, sans affecter les variables d’environnement utilisées par tous les autres terminaux du système. De plus, il possède un prompt de commande personnalisé, afin de distinguer rapidement le terminal utilisé pour le SDK.

Son contenu, succin, est le suivant :

!/bin/bash
bash --rcfile <(cat ~/.bashrc; echo 'PS1="\e[33;1mesp32 \$\e[0m "' ; echo 'export PATH="$HOME/esp32/xtensa-esp32-elf/bin:$PATH"' ; echo 'export IDF_PATH="$HOME/esp32/esp-idf"')

Attention : il est supposé que l’ensemble des fichiers nécessaires au SDK se trouvent dans le dossier ~/esp32. Si ce n’est pas le cas, modifier les chemins en conséquence

Il suffit d’exécuter le script pour obtenir un interpréteur BASH adéquat, et de quitter l’interpréteur (commande »exit », ou CTRL+D) pour revenir à un terminal normal.

J’ai testé son fonctionnement quelques heures, et en suis tout à fait satisfait. N’hésitez pas à me communiquer tout bug, ou amélioration possible !

Acer SW5-011 : Installer Ubuntu

Préparation d’une clé USB bootable

Bien qu’étant un système 64 bits, la tablette est dotée d’un firmware UEFI en 32 bits, non supporté par la plupart des ISOs Linux standard. Pour créer une clé USB bootable sur cette tablette, procéder comme suit :

Depuis une autre machine sous Linux, récupérer une image ISO 64 bits de la distribution souhaitée. Dans mon cas, il s’agit d’une Ubuntu 19.04, pour sa facilité d’utilisation avec un écran tactile, et la présence par défaut d’un noyau récent prenant en charge le matériel de la tablette ( en particulier la carte Wifi interfacée en SDIO, qui pose des problèmes avec des noyaux plus anciens ).

Insérer la clé USB qui recevra l’image ISO. Utiliser dmesg pour identifier son nom de périphérique. Ici je la nommerai /dev/sdX où X est à remplacer par la lettre adaptée à votre cas. La formater et y créer une partition de type EFI, qu’on montera dans le répertoire /mnt, grâce aux commandes suivantes :

$ sudo sgdisk --zap-all /dev/sdX
$ sudo sgdisk --new=1:0:0 --typecode=1:ef00 /dev/sdX
$ sudo mount -t vfat /dev/sdc1 /mnt

Y extraire le contenu de l »image ISO Linux téléchargée :

$ sudo 7z x /home/pila/Téléchargements/ubuntu-19.04-desktop-amd64.iso -o/mnt/

Récupérer le fichier bootia32.efi à l’URL suivante : https://github.com/jfwells/linux-asus-t100ta/blob/master/boot/bootia32.efi
Il s’agit d’un grub compilé pour EFI 32 bits, que l’on va maintenant copier dans le dossier EFI de la clé USB :

$ sudo cp Téléchargements/bootia32.efi /mnt/EFI/boot

La clé USB est maintenant prête, il ne reste plus qu’à la démonter proprement :

$ sudo umount /mnt

sources :
http://www.cedric-augustin.eu/index.php?post/2015/08/24/Installer-Ubuntu-1504-sur-un-Acer-Aspire-switch-10

Machine a pince EXPENDEDORA « A-BIFUCA » : Configuration et mod

Ayant été confronté à la configuration de cette machine à pince, et devant le peu de documentation disponible sur le web, j’ai décidé de rédiger ce bref article regroupant mon expérience avec cette machine

source : http://www.mapefe.com/gruas.html
Lire la suite

Édition de tag RFID MIFARE sous Linux avec le lecteur ACR122

Ayant récemment acquis un lecteur NFC ACR122, je m’attendais à trouver un logiciel me permettant de l’exploiter simplement sous Linux Mint.

Étonnamment, je n’en ai pas trouvé, et l’emploi du lecteur pour programmer des tags Mifare s’est avéré moins intuitif que je ne l’espérait.

Après quelques heures de galère, voilà un résumé de la procédure :

Installation

Installer libnfc et ses outils :

$ apt install libnfc-bin

Modifier le fichier /etc/modbprobe.d/blacklist-libnfc.conf pour inclure le driver pn533_usb. En effet, celui ci (ainsi que les autres déja inclus dans ce fichier ) interfèrent avec le bon fonctionnement du pilote utilisé par libnfc :

$ echo "blacklist pn533_usb" >> /etc/modprobe.d/blacklist-libnfc.conf

Redémarrer la machine ( cette fois ci le bon pilote sera chargé ).

Lister les tags visibles

Lister les tags visible s’effectue avec la commande nfc-list :

A vide (sans tag sur le lecteur )


$ nfc-list
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opene

Avec un tag Mifare sur le lecteur ( UID = A4 0B 44 76 )

$ nfc-list 
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): a4 0b 44 76
SAK (SEL_RES): 08

L’option -v permet d’en savoir plus sur le tag détecté ( ici un tag différent de celui lu précédemment ) :

$ nfc-list -v
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
    ATQA (SENS_RES): 00  04  
* UID size: single
* bit frame anticollision supported
       UID (NFCID1): ec  11  9c  1e  
      SAK (SEL_RES): 08  
* Not compliant with ISO/IEC 14443-4
* Not compliant with ISO/IEC 18092

Fingerprinting based on MIFARE type Identification Procedure:
* MIFARE Classic 1K
* MIFARE Plus (4 Byte UID or 4 Byte RID) 2K, Security level 1
* SmartMX with MIFARE 1K emulation
Other possible matches based on ATQA & SAK values:

0 Felica (212 kbps) passive target(s) found.

0 Felica (424 kbps) passive target(s) found.

0 ISO14443B passive target(s) found.

0 ISO14443B' passive target(s) found.

0 ISO14443B-2 ST SRx passive target(s) found.

0 ISO14443B-2 ASK CTx passive target(s) found.

0 Jewel passive target(s) found.

Lecture / écriture

Les opérations de lecture / écriture sur un tag Mifare Classic s’effectuent avec la commande nfc-mfclassic. Les clés par défaut sont utilisées mais il est possible de spécifier sont propre fichier de clé ( cf man nfc-mfclassic)

Lecture du contenu du tag et enregistrement dans le fichier mifare.mfd

$ nfc-mfclassic r a mifare.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): a4 0b 44 76
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Reading out 64 blocks |……………………………………………………….|
Done, 64 of 64 blocks read.
Writing data to file: mifare.mfd …Done.

Ecriture du tag depuis le fichier mifare.mfd

$ nfc-mfclassic w a mifare.mfd
NFC reader: ACS / ACR122U PICC Interface opened
Found MIFARE Classic card:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): a4 0b 44 76
SAK (SEL_RES): 08
Guessing size: seems to be a 1024-byte card
Writing 64 blocks |………………………………………………………|
Done, 63 of 64 blocks written.

Edition du contenu

Pour l’édition, l’emploi d’un editeur hexadécimal est nécessaire. Je recommande bless. Pour faciliter la lecture du contenu, je préconise d’ajuster la taille de la fenêtre pour afficher 16 octets sur chaque ligne, ainsi chaque ligne contient 1 bloc du tag :


En rouge le bloc 0 contient l’UID de la carte

En jaune le bloc 4 contient les données que j’y ai écrit

Le premier bloc de chaque secteur contient les permissions d’accès. Par défaut l’accès en lecture / écriture est possible avec les clés d’origines. Le bloc 0 est en lecture seule. Attention de ne pas modifier la longueur du fichier ( utiliser le mode remplacement plutôt que le mode insertion avec la touche « insert » du clavier )

Les 16 caractères d’un bloc me suffisant pour mon application, et n’ayant pas de problématique de sécurité, cet article touche à ça fin. Peut être le compléterais-je plus tard si je venais à devoir stocker des données sur plusieurs blocs, ou à mettre en place différentes clés pour l’accès aux données. Ce second cas est cependant improbable, étant donné que les carte Mifare sont gravement défaillante d’un point de vue sécurité (cf les nombreux article sur le web concernant la récupération des clés, ainsi que la possibilité d’obtenir des cartes dont le bloc 0 est accessible en écriture )

Raspberry Pi : Du son en réseau avec Jack

Il y a déjà 5 mois, j’expérimentais la transmission de son en réseau avec PulseAudio.

Bien que concluant, le système péchait par sa latence (certes faible, mais toujours perceptible), et son manque de stabilité.

Je me suis depuis penché sur Jack. Il s’agit d’un serveur son pour Linux, axé productivité musicale.

Il est possible de le configurer pour transmettre du son sur le réseau, mais le manque de documentation rend la tâche ardue.

J’ai pu obtenir un système assez stable après de nombreux essais, permettant d’utiliser un Raspberry Pi comme sortie son distante, avec une latence quasiment imperceptible.

Le projet repose sur l’utilisation de NetJack2, la 2ème révision du protocol réseau de Jack, ainsi que l’utilisation de Jack_Autoconnect, et a pour objectif de rendre le fonctionnement aussi fiable que possible.

J’ai rendu l’ensemble disponible sur GitLab : https://gitlab.com/Pilatomic/networkedjack

Le résultat est très satisfaisant, mis a part un unique problème restant : le client ne doit pas être stoppé pendant que le serveur est en fonctionnement, sous peine de devoir redémarrer le serveur. Il est sans doute possible de le régler avec un petit script bash, qui ping continuellement le client, et arrête le serveur lorsque le client n’est pas joignable, mais cette situation n’étant pas pénalisante dans mon cas, je ne me suis pas penché sur le sujet.

L’ensemble est suffisamment fiable, je l’utilise pour de la transmission de son en temps réel en entreprise

Raspberry Pi : Du son en réseau avec PulseAudio

Cet article décrit comment utiliser le Raspberry Pi comme sortie son ( sink ) distante ( en réseau ), pour un ordinateur sous Linux.

Il exploite les capacités réseau de PulseAudio, tant coté Raspberry que sur l’ordinateur source.

2 méthodes de connexions sont proposées :

  • La découverte automatique du Raspberry par Pulseaudio, simple et pratique, mais pas toujours très fiable
  • La configuration manuelle du Raspberry comme sortie son « tunnel » sur l’ordinateur source

Lire la suite

Raspberry Pi : Commandes utiles pour réaliser un affichage dynamique en mode portrait

Cet article est un mémo contenant lqes commandes utiles pour la réalisation d’un affichage dynamique vertical avec un Raspberry Pi

Désactiver la mise en veille de l’écran

sudo nano /boot/cmdline.txt

ajouter sur la même ligne :

consoleblank=0

source : https://www.raspberrypi.org/documentation/configuration/screensaver.md

Affichage en mode portrait

sudo nano /boot/config.txt

ajouter sur une nouvelle ligne :

display_rotate=1

Fichiers temporaire en RAM (pour économiser des cycles d’écriture sur la carte SD)

sudo nano /etc/fstab

ajouter les lignes suivantes :

tmpfs /tmp tmpfs defaults,noatime 0 0
tmpfs /var/log tmpfs defaults,noatime,size=64m 0 0

Système de fichier en lecture seul

sudo nano /etc/fstab

ajouter « ro » dans les attributs du système de fichier racine

Repasser le système de fichier en lecture / écriture à chaud

sudo mount -no remount,rw /

Point d’accès Wifi pour administration

https://frillip.com/using-your-raspberry-pi-3-as-a-wifi-access-point-with-hostapd/

Grbl Overseer : Une interface de contrôle touch-friendly pour CNC

Mon hackerspace local disposant depuis peu d’une fraiseuse à commande numérique pour la gravure de PCB, j’ai beaucoup joué avec.

La machine (low cost, mais robuste) est dotée d’un firmware libre dédié au contrôle de CNC par un hardware basé sur Arduino : Grbl

Plusieurs interfaces utilisateurs (pour PC) existent déjà pour Grbl. Cependant, aucune d’entre elles ne semble permettre la gestion automatisée de plusieurs tâches, ni n’offre d’interface optimisée pour un écran tactile. Ce sont là 2 des objectifs de ce projet.

Capture d’écran avec le panneau « Jobs » déployé

Ses principaux atouts sont :

  • Une interface utilisateur simple, optimisée pour un usage clavier / souris mais aussi sur écran tactile
  • Une prise en main facile
  • Une vue 3D des différentes tâches, ainsi que de la position actuel de l’outil
  • La planification de plusieurs tâches, avec des points d’origine différents
  • La vérification automatique de la validité du gcode, afin d’éviter de rencontrer des erreurs pendant la phase de production
  • Le support de Grbl à partir de sa version 1.1 (celle ci fige enfin l’interface de commande)
  • Commandes de déplacement manuelles exploitant d’interface de « jog » de Grbl 1.1
  • Une console série « futée », afin d’avoir un aperçu clair et détaillé des communications avec la machines
  • Une barre d’état « futée », affichant toujours l’état et la position de la machine, et permettant une lecture rapide même à distance de l’écran
  • Un éditeur de configuration pour les différents paramètres de Grbl
  • Multiplateforme : Windows, Linux, MacOs + Android (en cours de développement)

Le point le plus intéressant, et qui fut même le point d’origine de ce projet, réside dans sa compatibilité avec les plateforme Android.

En effet, les tablettes Android représentent, par leur faible consommation, leur faible encombrement, et leur utilisation intuitive, une plateforme idéale pour une interface utilisateur.

Le support Android, à l’état de preuve de concept, est toujours en développement. Si l’application démarre sur la grande majorité des périphérique, une version  d’Android >= 3.1 et compilée avec le support USB Host est nécessaire pour s’interfacer avec la fraiseuse à travers un convertisseur USB / UART.

Le code source de Grbl Overseer et les instructions de compilation pour Linux sont disponibles sur Gitlab : >> ICI <<

Une archive contenant l’exécutable pour MS Windows est disponible >> LA <<

De nombreux bug subsistent encore, notamment dans la gestion particulière de l’USB et du rendu Open GL ES propre à Android.

Sur PC en revanche, le logiciel devrait se montrer stable, n’hésitez pas à l’essayer, et à me faire remonter vos remarques !