Connexion
Mes notes succinctes à ce sujet :
Récupérer la bibliothèque ch554_sdcc : https://github.com/Blinkinlabs/ch554_sdcc (copie ci dessous si disparition du repo)
Récupérer l’outil de programmation ch552_tool : https://github.com/MarsTechHAN/ch552tool (copie ci dessous si disparition du repo)
Installer sdcc
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) $ apt-get install sdccCopier un exemple et l’utiliser comme base (le Makefile pointe vers un Makefile.include qui contient le nécessaire pour compiler vers le MCU cible).
Le MCU contient un bootloader USB, activé en connectant D+ au +5V à travers une résistance de 10kohms à la mise sous tension.
Utilisation de ch552tool :
$ sudo python3 ch55xtool/ch55xtool.py -f FIRMWARE.bin -rExecution en root nécessaire. Crash après la programmation si l’option « -r » (reset avec flash) est utilisée, à cause de la déconnexion du device cible.
Produite entre 1991 et 1996 par le fabricant danois Bang & Olufsen, la Beolink 5000 est une télécommande permettant de contrôler les différents appareils de la marque, ainsi que de monitorer leur état grâce à l’écran LCD translucide présent à son extrémité. Ce modèle représentait en son temps l’état de l’art dans le domaine des télécommandes multimédia.
Malheureusement, bon nombre de ces télécommandes ont maintenant 30 ans d’age, et si certains composants vieillissants sont facilement remplacés ( notamment les condensateurs électrochimiques assurant la stabilité de la communication infrarouge ), les adhésifs chargés de maintenir en place l’écran et sa nappe montrent eux aussi des signes de faiblesse, avec pour conséquence un détachement partiel ou complet de la nappe de l’écran, ce dernier perdant de ce fait ses capacités d’affichage. La grande majorité des télécommandes encore existantes sont affectées par cette maladie. Certaines fonctions qui requièrent un écran fonctionnel, telles que le paramétrage de la télécommande, ou des équipements associés, deviennent alors inutilisables.
L’exemplaire en ma possession présentait un état encore plus dramatique, l’écran complètement séparé de la télécommande, la nappe le raccordant à son électronique de contrôle s’étant déchirée sous son poids. J’ai décidé de consacré une partie de mon temps libre de l’année dernière à la conception d’un remplacement.
L’écran LCD d’origine, translucide, et collé sur une plaque de verre trempé, est conçu spécialement pour cette usage, tout comme la nappe qui le relie à son contrôleur. Peu de chances de trouver un remplacement ou un équivalent, sans parler de l’équipement nécessaire au raccord de sa nappe. Ma recherche s’orientait initialement vers les afficheur OLED transparent, ayant dans l’idée d’ajouter une touche moderne à cette télécommande ( les afficheurs OLED étant capable d’émettre leur propre lumière, tandis qu’un afficheur LCD ne peut que la bloquer ). Si je n’ai pas pu identifier de modèle dont les dimensions permettraient son intégration en lieu et place de l’afficheur LCD d’origine, il existe un autre type d’afficheur qui accepte de se prêter à ce jeux : il s’agit d’un afficheur E-Paper.
Utilisés principalement dans les liseuses électroniques, les afficheurs E-Paper ont une apparence semblable à celle du papier, offrant un contraste inégalé, et la capacité de conserver leur affichage sans alimentation, au prix d’un temps de rafraîchissement particulièrement long, pouvant durer plusieurs secondes.
Ayant maintenant une solution possible, je me suis attelé à la conception d’un circuit capable de contrôler l’afficheur E-Paper, occupant le ( faible ) volume mécanique disponible dans la télécommande, et interprétant les commandes d’affichage transmises par le microprocesseur de la télécommande à la place du contrôleur LCD d’origine.
La tâche s’est avérée plus ardue que prévu, notamment car l’écran d’origine étant transparent, il est peut être lu d’un coté ou de l’autre en fonction du coté où sont situés les boutons en rapport avec la situation. Dans le cas d’un texte lisible par l’arrière, certains caractères ne sont pas transmis par le microprocesseur sous forme de texte, mais sous forme de bitmap, nécessitant la reconnaissance du caractère correspondant avant de pouvoir l’afficher. ( L’affichage direct des bitmaps n’est pas possible, la résolution de l’afficheur E-Paper n’étant pas un multiple de la résolution de l’afficheur d’origine ).
Le résultat est le suivant, et s’intègre directement dans la télécommande.
Fonctionnalités principales :
Le « clignotement » pendant le rafraîchissement, tel que visible sur la vidéo ci-jointe, est normal et inhérent à ce type d’afficheur.
Un guide d’installation en PDF est disponible ci dessous :
Un kit contient :
L’installation nécessite des compétences et de l’équipement de soudure électronique ( notamment une station de soudure, et une station à air chaud ), ainsi que de manipuler délicatement des pièces chaudes ( pour séparer la plaque de verre de l’écran )
Contactez moi pour acheter un kit. Je peux également réaliser l’installation sur votre télécommande.
Liens : Fil sur le Forum Beoworld ( anglais )
Par soucis d’exhaustivité, ci dessous des photos des premières itérations de PCB :
Si vous etes interessés, jetez aussi un oeil à BEOTOOTH 5500 : Un récepteur Bluetooth compatible Datalink
Cet article résume le process nécessaire pour compiler Marlin en ligne de commande sous Linux avec PlatformIO Core.
2. Ajouter PlatformIO au PATH local :
export PATH=$PATH:~/.platformio/penv/bin
3. Récupérer le code source de Marlin.
4. Si on récupère le code source officiel (et pas une version déjà customisée pour une machine spécifique ), récupérer les fichiers de configuration dans le dépot git MarlinFirmware/Configurations, et copier les fichiers de configuration adéquat dans le dossier Marlin / Marlin /
5. Se placer dans le dossier Marlin ( contenant platformio.ini ).
6. Identifier la valeur de MOTHERBOARD, en gras dans l’exemple ci dessous, à partir du fichier Configuration.h. ( pour une carte BTT SKR E3 MINI V2.0 )
$ cat Marlin/Configuration.h | grep MOTHERBOARD
#ifndef MOTHERBOARD
#define MOTHERBOARD BOARD_BTT_SKR_MINI_E3_V2_0
If not defined the default pin for the selected MOTHERBOAR
7. Identifier les environnements PlatformIO compatibles à partir du fichier pins.h ( attention à supprimer le BOARD dans la valeur de MOTHERBOARD ):
$ cat Marlin/src/pins/pins.h | grep BTT_SKR_MINI_E3_V2_0
elif MB(BTT_SKR_MINI_E3_V2_0)
#include "stm32f1/pins_BTT_SKR_MINI_E3_V2_0.h" // STM32F1
env:STM32F103RC_btt env:STM32F103RC_btt_512K
env:STM32F103RC_btt_USB env:STM32F103RC_btt_512K_USB
8. Compiler avec l’environnement adapté ( dans mon cas gestion de l’USB mais pas 512K de ROM ) :
$ platformio run -e STM32F103RC_btt_USB
9. Récupérer le fichier firmware.bin à l’emplacement suivant :
.pio/build/STM32F103RC_btt_USB/firmware.bin
10. Le copier sur une carte SD ( sans altérer son nom ), et la mise à jour s’effectue à la mise sous tension de l’imprimante. Le fichier sera alors renommé en FIRMWARE (sans extension).
11. Si présence d’un fichier EEPROM.DAT sur la carte SD lors de la mise à jour firmware, le contenu de l’EEPROM (calibration, réglages) sera écrasé.
Il s’agit d’un petit logiciel que j’ai développé sous Qt, facilitant la calibration d’un écran tactile / tablette graphique, notamment quand l’écran en question est un écran secondaire
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.
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
Récupérer l’exemple de compilation avec CMake fourni avec stm32plus dans le dossier stm32plus/cmake/example
Dans QtCreator : Aide -> Plugins, activer « BareMetal », et redémarrer QtCreator
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
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
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
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
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
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.
La première étape consiste à se doter d’un émulateur capable d’exécuter du code PSP, permettant de valider le fonctionnement du code compilé.
Pour cela j’ai choisi PPSPP, donc le code source est disponible sur github. Les instructions de compilation sous Linux sont décrites ici.
Récupérer une copie du code source et de ses sous-modules
git clone https://github.com/hrydgard/ppsspp.git
git submodule update --init --recursive
Plusieurs front-end sont disponibles, j’ai choisi d’utiliser celui basé sur Qt, principalement pour ma familiarité avec ce framework. Installer les paquets nécessaires :
apt install qt5-qmake qtmultimedia5-dev qttools5-dev-tools qtmultimedia5-dev libqt5opengl5-dev
Lancer la compilation :
cd ppspp
./.sh --qt
Une fois la compilation terminée, l’exécutable se trouve dans le dossier build
Les scripts permettant l’installation de la toolchain se situent sur le dépot git ici : https://github.com/pspdev/psptoolchain
Les récupérer avec la commande suivante :
git clone https://github.com/pspdev/psptoolchain.git
Se placer dans le dossier ainsi créé :
cd psptoolchain
Exécuter ensuite le premier script, qui se charge de l’installation des dépendances pour Debian et ses dérivés ( Ubuntu et Linux Mint notamment ). Ce script va notamment remplacer le lien symbolique /bin/sh pointant vers le logiciel DASH, par un nouveau lien symbolique pointant vers BASH, DASH ne permettant pas de mener l’installation de la toolchain sans erreurs.
./prepare-debian-ubuntu.sh
Ensuite, exécuter le script d’installation à proprement parler. Celui ci nécessite les droits super utilisateurs, d’où sont appel avec la commande sudo
sudo ./toolchain-sudo.sh
L’installation se déroule ensuite normalement. Sur ma machine, plutôt véloce, celle-ci a duré une bonne demi-heure.
L’installation va déposer les fichiers nécessaires dans le répertoire /usr/local/pspdev, et automatiquement modifier les variables d’environnement pour permettre l’appel des bons exécutables lors de la compilation, en modifiant notamment la variable d’environnement PATH. Ce système ne me plaisant guère ( pour des raisons décrites dans l’article précédent ), je vais déplacer l’ensemble de la toolchain dans un dossier séparer, empêcher la modification du PATH, et ajouter un petit script permettant le fonctionnement de la toolchain seulement dans le terminal où il sera appelé.
Déplacer la toolchain dans mon home, et en devenir propriétaire :
sudo mv /usr/local/pspdev ~/
sudo chown -R MON_NOM_DUTILISATEUR ~/pspdev/
Empêcher la modification automatique du PATH au démarrage :
sudo rm /etc/profile.d/psptoolchain.sh
Créer le script permettant de configurer un terminal capable d’utiliser la toolchain :
nano ~/pspdev/setupPspEnv.sh
Y insérer le contenu suivant :
#!/bin/bash
bash --rcfile <(cat ~/.bashrc; echo 'PS1="\e[33;1mpspdev \$\e[0m "' ; echo 'export PATH="#/pspdev/bin:$PATH"' ; echo 'export PSPDEV="~/pspdev/"')
Il suffit ensuite d’exécuter ce fichier pour mettre un place, uniquement dans le terminal actif, les variables d’environnement nécessaires au fonctionnement de la toolchain.
La toolchain contient PSPSDK. Il s’agit d’un SDK amateur qui fournissant toutes les fonctions nécessaires aux développement d’une application sur PSP. De nombreux exemples sont disponibles dans le dossier pdpdev/psp/sdk/samples.
Malheureusement, beaucoup ne compilent pas correctement. La commande make produit bien un exécutable EBOOT.PBP lisible par ppspp, mais ceux-ci provoquent souvant le crash de l’émulateur, sans plus d’information qu’un laconique « segmentation fault ».
Il s’avère que la LIBC utilisée normalement par le compilateur GCC ne produit pas du code valide en ce qui concerne le traitement des nombres flottant. Il suffit d’ajouter une ligne au Makefile de chaque example ( et plus tard aux Makefile de nos propres projets ) :
...
PSP_EBOOT_TITLE = Reflection Sample
USE_PSPSDK_LIBC = 1
PSPSDK=$(shell psp-config --pspsdk-path
...
Cette ligne spécifie au compilateur d’utiliser la LIBC fournie avec PSPSDK, et non celle fournie avec GCC.
j’ai finalement pu compiler les exemples ( notamment ceux liés à l’unité graphique (GU) de la console, afin de ma familiariser avec sa programmation, comme l’atteste le screenshot suivant :
Cet article n’est que le premier pas d’un projet centré autour d’une PSP, qui fera l’objet d’un futur article. En attendant, j’espère que celui-ci vous épargnera les nombreux tâtonnements qui m’ont été nécessaires pour en arriver là !
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 !
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 :
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 !
