Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi)

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierPila's blog

BEOTOOTH 5500 : Un récepteur Bluetooth compatible Datalink

Par : Pila

Introduit en 1980 par le fabricant danois Bang & Olufsen avec le système Beolab 8000, le protocole Datalink 80 raccorde par un bus de données les différents appareils d’un même système , offrant à l’utilisateur un contrôle unifié sur ce dernier. Ainsi, une télécommande unique contrôle l’ensemble du système, et commencer la lecture sur un appareil provoque le basculement automatique de l’amplificateur sur l’entrée associée, ainsi que la mise en pause des autres appareils. Le protocole évolue au fil des années, voyant notamment, avec le Beosystem 5500, l’addition d’une transmission en temps réelle de l’état des appareils, alors affiché sur la télécommande (Master Control Panel 5500)

Master Control Panel 5500

Étant propriétaire d’un système 5500 (BEOMASTER 5500, BEOCORD 5500, BEOGRAM CD 5500, et MASTER CONTROL PANEL 5500), j’ai souhaité lui ajouter une fonction Bluetooth audio, qui, contrairement à un adaptateur Bluetooth Audio classique, exploiterait le protocole Datalink pour offrir la même interface de contrôle que les autres éléments du système.

Le BEOMASTER 5500 étant doté d’une entrée TP2 permettant le contrôle d’un second BEOCORD, j’ai entrepris de concevoir un récepteur Bluetooth capable de simuler un BEOCORD 5500 sur le bus Datalink. Ce récepteur relaie les commandes du système (PLAY/PAUSE, etc.) via Bluetooth et transmet les informations sur la piste en cours de lecture au système.

Après un premier prototype à base d’ESP32 ne me donnant par entièrement satisfaction (codec SBC seulement, et stabilité de la connexion marginale), j’ai remanié le projet autour d’un module BM83 de Microchip, et je suis parvenu à un résultat satisfaisant, que j’ai nommé le BEOTOOTH 5500.

Boitier BEOTOOTH 5500

Sous la forme d’un boitier de 66mm de coté, et 27mm de haut, il dispose d’un câble (solidement maintenu en place par un support anti-arrachement) terminé par une prise DIN 7 broches pour se raccorder aux prises TP ou TP2 des équipements B&O, ainsi que d’une prise USB-C pour son alimentation. (5V, 100mA). De part de d’autre de la prise USB-C sont disposées une LED rouge qui indique l’état de la liaison Bluetooth (En veille / Connecté / Appairage), ainsi qu’un bouton poussoir, qui permet par un appui court d’entrer en mode appairage, ou par un appui prolongé (10 secondes) d’oublier tous les appareils appairés.

Ses principales fonctions sont :

  • Transmission d’un signal audio de haute fidélité (codec AAC, et DAC TI PCM5102A) et même niveau que les autres appareils B&O
  • Contrôle de la lecture (Lecture / Pause / Piste suivante et précédente, Avance et retour rapide) à partir des terminaux B&O (Beolink & Master Control Panel)
  • Transmission de l’état actuel au système. (Lecture / Pause / Déconnecté)
  • Transmission au système des informations sur la piste en cours lecture (Numéro de piste / Nombre total de pistes / Compteur de temps de lecture).
  • Arrêt automatique lorsque l’appareil Bluetooth ne transmet pas ou est déconnecté.
  • Démarrage automatique du système lors du lancement de la lecture sur le périphérique Bluetooth.

La vidéo ci dessous démontre ces fonctionnalités :

Le BEOTOOTH 5500 est compatible avec tout appareil doté d’une interface Datalink (DIN 7 broches) et a été testé (par les membres du forum Beoworld) avec les systèmes suivants :

AppareilAffichage du statutNote
Beomaster 5500OuiEtat en temps réel sur entrée TP1 seulement
Beosystem 2500Non
Beocenter 9500Non
Beomaster 5000
BeoMaster 7000OuiStatut affiché sur MCP6500, mais pas sur Beolink 7000 ?
Confirmé OK contrôle et affichage status sur BL7000 et BL5000
Beosound OuvertureNon
MCL2AVNon
Beomaster 4500
BeoSound 3200NonAudio seulement ! Pas de liaison de donnée Datalink !
Compatibilité vérifiée avec différents systèmes

Il est possible de mettre à jour son micrologiciel simplement en le raccordant à un ordinateur (Windows ou Linux) via un câble USB-C.

Le BEOTOOTH 5500 est disponible assemblé et prêt à l’emploi, ou sous forme de kit incluant : la carte électronique préassemblée, la led rouge, le cable, la prise DIN 7 broche, le boitier usiné adéquatement, la pièce de support du câble, la visserie nécessaire, ainsi que l’étiquette. Le kit contient l’ensemble des éléments nécessaires à l’assemblage, mais nécessite des compétences en soudure électronique.

Un guide de montage et d’utilisation (en anglais) est disponible ici : Beotooth_Manual_V1.1

Si vous souhaitez acquérir un BEOTOOTH 5500, ou pour toute question, merci de publier un commentaire avec votre adresse e-mail, et je vous répondrai dans les plus bref délais.

Linux Mint / Ubuntu : Transmettre les informations de lecture multimédia via Bluetooth (AVRCP TG)

Par : Pila

Ayant récemment développé un projet de récepteur audio Bluetooth utilisant AVRCP pour récupérer les informations du lecteur multimédia actif, j’ai pu constater que Linux Mint ne communique aucune information sur le média en cours de lecture à travers la liaison Bluetooth.

Après quelques recherche, il s’avère que c’est le démon MPRIS-PROXY qui est chargé de cette fonction, mais celui-ci ne semble pas actif sous Mint. Pire, il est introuvable ni à son emplacement supposé (/bin), ni dans les paquets !

La frayeur est de courte durée, il est bien installé avec le paquet bluez, et se situe à /lib/bluetooth/mpris-proxy.

Il suffit pour l’activer de créer un fichier de configuration pour systemd en mode utilisateur :

$ mkdir ~/.config/systemd/user
$ nano ~/.config/systemd/user/mpris-proxy.service

Y ajouter le contenu suivant :

[Unit]
Description=Forward bluetooth media controls to MPRIS

[Service]
Type=simple
ExecStart=/lib/bluetooth/mpris-proxy

[Install]
WantedBy=default.target

Il ne reste plus qu’à l’activer :

$ systemctl --user start mpris-proxy.service
$ systemctl --user enable mpris-proxy.service

On peut vérifier son bon fonctionnement avec la commande suivante :

$ systemctl --user status mpris-proxy.service

Qui doit nous retourner cette réponse :

Et voilà, les informations de la lecture multimédia (état lecture / pause, piste en cours, et position) sont maintenant accessibles par les périphériques Bluetooth connectés.

Une application Kiosk Wayland, avec Weston

Par : Pila

Cet article contient une synthèse de la procédure à suivre pour exécuter une application en mode Kiosk sous Debian, en utilisant le compositeur Weston.

Il existe le compositeur « cage » dédié à ce rôle, mais son manque de flexibilité est vite limitant (il est notamment impossible de désactiver une sortie video).

Le compositeur ainsi que l’application sont exécutés par un utilisateur « kiosk » avec des droits restreints, évitant de compromettre toute la sécurité du système en cas de crash du compositeur / retour au shell

1. Installer weston et seatd

seatd arbitre l’accès au matériel d’entrée / sortie ( écran / clavier + souris ), et est nécessaire à l’utilisation de weston.

# apt install tmux weston seatd  

2. Fichier de configuration weston.ini

On créé le fichier weston.ini, que l’on place dans le répertoire personnel de l’utilisateur « kiosk » , avec pour contenu suivant :

[core]
backend=drm-backend.so
idle-time=0

[output]
name=HDMI-A-1
mode=1920x1080
transform=rotate-90

[output]
name=eDP-1
mode=off

Le bloc [core] spécifie l’utilisation du pilote « drm », qui prend directement la main sur la carte graphique sans passer par un autre compositeur, et désactive l’écran de veille.

Les blocs [output] configurent les différentes sorties video. Dans ce cas l’une est désactivée, tandis que l’autre est en mode portrait. Le nom des sorties provient du répertoire /sys/class/drm.

3. Script de lancement

Créer le script start_kiosk.sh dans le répertoire personnel de l’utilisateur « kiosk ». Son contenu est le suivant :

#!/bin/bash
weston --config /home/kiosk/weston.ini &
sleep 5s # could be less
export WAYLAND_DISPLAY=wayland-1
export DISPLAY=:1
exec /home/kiosk/kiosk_app --platform wayland 2>log_kiosk.txt

Modifier la commande de lancement pour correspondre au chemin du fichier weston.ini

La ligne « sleep 5s » pourrait être modifiée pour attendre une notification de démarrage de weston. Des solutions existent utilisant systemd, mais je n’ai pas trouvé de solution simple adaptée à mon cas.

Dans mon cas, j’exécute une application Qt nommée « kiosk_app », pour Qt il est nécessaire de spécifier –platform wayland, sans quoi l’application ne démarre pas.

4. Login automatique de l’utilisateur « kiosk »

Créé le fichier /etc/systemd/system/getty@tty1.service.d/autologin.conf avec pour contenu

[Service]
ExecStart=
ExecStart=-/sbin/agetty -o '-p -f -- \\u' --noclear -a kiosk %I $TERM
Type=simple
Environment=XDG_SESSION_TYPE=wayland

Il est nécessaire d’utiliser le tty1 plutôt que le traditionnel tty7 pour l’interface graphique, car le changement de terminal automatique n’est pas fiable.

5. Conclusion

Cette approche permet le lancement d’une application en mode kiosk, sans aucun bureau traditionnel installé. L’utilisation de Wayland améliore grandement la fluidité, et garanti notamment l’absence de « tearing » (affichage partiel de 2 images consécutives) qui est très visible voire dérangeant lors de la lecture de video avec X11.

Linux Mint : Compiler un noyau patché

Par : Pila

Il existe beaucoup de documentation sur la façon de compiler un noyau Ubuntu / Linux Mint à partir des sources, mais il s’avère que la plupart sont incomplètes et/ou obsolètes. L’utilisation d’une méthode inadaptée n’est décelable qu’après plusieurs heures de compilation, découvrir la bonne méthode par tâtonnement peut s’avérer particulièrement frustrant.

Voici la bonne méthode (source en anglais), éditée par mes soins pour éviter de dérouler toute la procédure en super-utilisateur (root), car cela n’est pas nécessaire.

1. Activer les dépôts de sources.

Depuis le menu Mint, lancer le logiciel « Sources de logiciels », et activer « Dépôts de code source ».

Cliquer ensuite sur « Valider » pour mettre a jour le cache.

2. Installer les outils de compilation

Exécuter en console les commandes suivantes :

sudo apt update
sudo apt build-dep linux linux-image-$(uname -r)

sudo apt install libncurses-dev gawk flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev autoconf llvm build-essential libncurses5-dev gcc bc dwarves

3. Récupérer le code source du noyau

Le code source du noyau Linux est disponible sur le site http://kernel.org, mais ce qui nous intéresse ici est le noyau patché par Ubuntu, qui est utilisé par Linux Mint. Téléchargeons les sources dans un dossier créé à cette fin :

mkdir linux-src
cd linux-src
apt source linux-image-unsigned-$(uname -r)

Plaçons-nous dans le dossier téléchargé, et donnons les permissions d’exécutions au scripts :

cd linux-hwe-6.2-6.2.0  # A mettre à jour avec le nom de votre noyau
chmod a+x debian/scripts/*
chmod a+x -R ./scripts

4. Appliquer vos patches

En exécutant, pour chaque patch, la commande suivante

patch -p1 <CHEMIN_DU_FICHIER_PATCH>.patch

5. Copier la configuration

cp /boot/config-$(uname -r) ./.config

# update config for new kernel
make oldconfig

6. Lancer la compilation

En exécutant la commande suivante :

make -j16 deb-pkg LOCALVERSION=-custom

L’argument « -j16 » permet de sélectionner le nombre de tâches exécutées en parallèle, une valeur plus élevée nécessitant plus de ressources matérielles (RAM notamment). La valeur idéal correspond généralement au nombre de thread exécutables en parallèle sur le système (par exemple 4 dans le cas d’un processeur 2 core / 4 threads).

7. Installer le nouveau noyau

# change to parent dir
cd ..

dpkg -i *.deb

update-grub

8. Démarrer sur le nouveau noyau

Le nouveau noyau est maintenant disponible au démarrage, dans le menu du chargeur d’amorçage Grub. Attention, ce n’est pas forcément le choix par défaut ! Il est reconnaissable a son préfixe « custom ».

Programmer sur microcontrôleur CH55x avec SDCC sous Linux

Par : Pila

Mes notes succinctes à ce sujet :

Installation

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

$ apt-get install sdcc

Copier 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).

Flasher le code

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 -r

Execution 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.

Acer Aspire R13 : Faire fonctionner l’entrée micro jack

Par : Pila

Ajouter la ligne suivante à la fin du fichier /etc/modprobe.d/alsa-base.conf

options snd-hda-intel model=auto,dell-headset-multi

Réparation d’un « boitier à chaine » STILE RF

Par : Pila

Le « boitier à chaine » STILE RF est un appareil permettant l’ouverture / fermeture d’une fenêtre battante à l’aide d’une télécommande.

Photo du STILE RF
Boitier à chaine STILE RF

L’exemplaire en ma possession refuse totalement de fonctionner, et ne donne aucun signe de vie. Voyons si il est possible de le réparer.

Le démontage est rapide, il suffit de dévisser 7 vis pour retirer le capot arrière, puis 2 vis supplémentaires libèrent le mécanisme de la chaîne, révélant l’électronique de contrôle.

Photo PCB électronique STILE RF
L’électronique de contrôle est logée sous la chaîne.

Le principe de fonctionnement est sommaire : un moteur 230V à double enroulement ( un pour chaque sens ) est piloté par 2 relais sur la carte électronique . Un microcontrôleur R5F2126 se charge de leur contrôle, en fonction de l’état de 3 microswitchs indiquant la position de la chaîne, ainsi que des ordres de la télécommande, reçus par un récepteur radio Si4355 de chez Silicon Labs. Une EEPROM ( de type 93xx66 ) est présente, probablement pour stocker les codes des télécommandes associées. Un régulateur BUCK ( no isolé ) fourni la tension de 12V utilisée pour le pilotage des relais, à partir de laquelle un régulateur linéaire fourni une tension de 3.3V pour l’alimentation de la logique.

Je misais à priori sur une défaillance du régulateur BUCK ( problème courant sur ce type de montages ), mais après une mesure rapide des tensions ( attention ! pas d’isolation du secteur, toute l’électronique est à un potentiel dangereux ! ), il s’avère que toutes sont présentes. Pour la suite je déconnecte l’alimentation 230V, et fourni le 12V à partir d’une alimentation de laboratoire, pour pouvoir expérimenter sans risque.

Les transistor assurant le contrôle des relais, ainsi que les sorties du microcontrôleur les pilotant sont testées à ohmmètres, et ne semble pas endommagés.

Je décide alors d’instrumenter les broches d’ I/O de l’EEPROM ainsi que du récepteur radio, afin de vérifier le bon fonctionnement du microcontrôleur. J’y trouve de l’activité à la mise sous tension du système ( lecture de l’EEPROM et configuration du récepteur radio ), mais également à chaque appui sur un bouton de la télécommande : le microcontrôleur semble donc opérationnel ! Dans ce cas, pourquoi les relais ne sont-ils jamais pilotés ?

Je trouve un début de réponse dans le manuel utilisateur : La télécommande est associée à l’appareil à sa première mise sous tension ; par la suite il faut disposer d’une télécommande fonctionnelle associée pour pouvoir en associer une nouvelle.

Et si ? Et si ma télécommande n’était plus associée à cet appareil ? Les symptômes seraient identiques !

L’empreinte pour un bouton poussoir est présente sur le PCB, mais non peuplée. Peut-être s’agit-il d’un bouton d’association, finalement non monté ? Court-circuiter ses broches provoque un BIP du buzzer, mais rien de plus.

Il me faut un moyen de retourner l’appareil à sa configuration d’usine. Je décide d’effacer l’EEPROM présente sur la carte. Pour cela, le microcontrôleur est désactivé en raccordant sa broche RESET à la masse, afin de l’empêcher de manipuler les I/O de l’EEPROM, que je raccordes par ailleurs à une carte de développement ESP32 ( idéale, car en logique 3.3V ). Cette carte est programmée pour lire chaque adresse de l’EEPROM, en effacer le contenu, et effectuer une nouvelle lecture pour valider que l’effacement est effectif. Ce programme est disponible dans l’archive ci-dessous.

Une fois sa tâche accomplie, la carte ESP32 est déconnectée, et l’alimentation de l’appareil coupée, puis restaurée. 3 bips se font entendre, indiquant d’après le manuel utilisateur qu’aucune télécommande n’est associée. Je procède à l’association de la télécommande, et après appui sur un des boutons : Victoire ! Un des relais commute ! Le moteur ne tourne pas, mais c’est attendu, l’appareil n’est pas raccordé au secteur, je ne lui fourni d’une alimentation +12V . L’appareil est rapidement remonté, alimenté, et je peux constater que la chaîne est bien mise en mouvement en fonction des ordres de la télécommande !

Je n’ai pas du déterminer qui, de l’appareil ou de sa télécommande, est à l’origine de cette défaillance. Il ne semble pas y avoir de code de correction d’erreur permettant de détecter une corruption de l’EEPROM, mais son écriture est interdite à sa mise sous tension, et doit être déverrouillée par l’envoi d’une commande spécifique. Du coté de la télécommande, pas d’EEPROM, le code est probablement stocké directement dans son microcontrôleur. Quelle qu’en soit la cause, ce mode de défaillance, purement logiciel, est incroyablement stupide, l’appareil est rendu inutilisable alors qu’il est en parfait état de fonctionnement ! Pourquoi le fabricant n’a-t-il par prévu une procédure permettant d’associer une nouvelle télécommande sans disposer d’une télécommande précédemment associée ?? Disposer de 2 télécommande permettrait-il de mitiger le problème ? ( en utilisant la seconde télécommande pour associer à nouveau une télécommande « oubliée » ).

Kit E-Paper pour Beolink 5000

Par : Pila
Ma Beolink 5000, après le remplacement de son écran défaillant par un afficheur E-Paper

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.

Le PCB supérieur de la Beolink 5000, avec le contrôleur LCD d’origine, la nappe de l’écran LCD sectionnée

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.

Le PCB d’interface, soudé directement sur le PCB supérieur de la télécommande
L’écran de démarrage affichage la version du firmware
Menu de configuration de la télécommande
Au dos, le support de l’afficheur, réalisé par impression 3D
L’afficheur E-Paper raccordé au PCB d’interface

Fonctionnalités principales :

  • Afficheur E-Paper lisible depuis l’avant.
  • Supporte tous les textes et indicateurs de l’afficheur LCD d’origine.
  • Texte en haut résolution ( 29*14 pixels par caractères, contre 7*5 d’origine )
  • Écran de veille.
  • Basse consommation : Pas de dégradation significative de l’autonomie de la télécommande.
  • Indicateur de batterie faible.

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’afficheur E-Paper.
  • Le PCB d’interface.
  • Le support de l’afficheur, imprimé en 3D.
  • Un fil ( nécessaire pour raccorder le VBAT sur le PCB )

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 :

Mk1 PCB : Preuve de concept
Mk2 PCB : Première intégration physique dans la télécommande

Si vous etes interessés, jetez aussi un oeil à BEOTOOTH 5500 : Un récepteur Bluetooth compatible Datalink

Acer SW5-011 : Installer Ubuntu

Par : Pila

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

MacPro 1,1 : Installer Linux Mint avec amorçage EFI

Par : Pila

J’avais déjà il y a quelques temps publié un article décrivant comment installer Linux sur un MacPro 1.1 sans carte graphique ni EFI. Cet article proposait une méthode d’installation utilisant le mode de démarrage en mode « compatibilité BIOS », qui a pour principaux inconvénient de nécessiter un passage par un CD d’amorçage pour l’installation, et, une fois l’installation terminée, implique des temps de démarrage de plus d’une minute. Ayant depuis mis la main sur une carte graphique avec le firmware Apple adéquat, cet article décrit l’installation de Linux Mint avec amorçage EFI.

La méthode décrite dans cet article nécessite une carte graphique Apple fonctionnelle afin de pouvoir afficher le menu d’amorçage !

Création de la clé USB d’installation

Utiliser GParted pour créer une nouvelle table de partition GPT sur la clé USB.

Créer 2 partitions sur la clé USB :

  • Une partition « EFI », de type FAT32, de taille 200Mo, avec le fanion « boot »
  • Une partition de type ext4 occupant le reste de la clé.

Copier l’intégralité des fichiers de l’ISO d’installation sur la partition ext4.

Sur la partition EFI, créer le dossier /efi/boot, et y copier le fichier bootia32.efi. (source).

Créer également le dossier /boot/grub, et y copier les fichiers vmlinuz et initrd.lz obtenus dans le dossier casper de l’ISO d’installation. Y copier également le fichier grub.cfg obtenu dans /boot/grub.

Editer le fichier grub.cfg, y insérer le contenu suivant ( avant la première entrée de menu ) :

menuentry "Install Mint MacPro" --class linuxmint {
linux /boot/grub/vmlinuz live-media-path=/casper/ ignore_uuid root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX boot=casper nosplash noefi --
initrd /boot/grub/initrd.lz
}

en remplaçant PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX par l’identifiant de la partition où l’on a copié les fichiers de l’ISO d’installation, obtenu à l’aide de la commande blkid.

Démarrage sur la clé USB d’installation

Immédiatement après avoir appuyé sur le bouton de mise sous tension du MacPro, maintenir appuyer la touche Alt du clavier, jusqu’à l’apparition d’un menu de sélection du périphérique d’amorçage. (Cela devrait prendre environ 5 secondes après le gong sonore de démarrage ) .

Le menu de sélection du périphérique d’amorçage

Appuyer une fois sur la flèche de droite pour sélectionner le périphérique USB EFI Bootpuis appuyer sur entrée.

Le lanceur grub démarre. Appuyer sur entrée pour procéder à la sélection de la première entrée, intitulée Install Mint MacPro.

Le démarrage de l’image d’installation prend jusqu’à 5 minutes, sans que rien ne s’affiche à l’écran, cela semble normal, et est vraisemblablement due à la faible vitesse d’accès USB de l’implémentation EFI sur ces machines.

Procéder à l’installation de manière usuelle.

A la fin de l’installation, ne pas redémarrer !

Procéder au montage de la partition du disque sur lequel l’installation a été effectuée, et éditer le fichier /boot/grub/grub.cfg, et rechercher la ligne contenant les arguments noyaux pour le démarrage par défaut (Il doit s’agit de la 1ere ligne commençant par la commande linux). Y ajouter l’arguement noefisi il n’y figure pas. ( Cette modification est nécessaire pour permettre un bon démarrage du noyau ).

linux	/boot/vmlinuz-5.8.0-48-generic root=UUID=dabdd8d7-32f0-46a3-9c20-ba8cf5c342aa ro quiet splash noefi

Une fois la modification effectuée (et enregistrée), redémarrer la machine.

Après l’installation

Editer le fichier /etc/default/grub pour y faire figurer la modification précédemment effectuée :

GRUB_CMDLINE_LINUX="noefi"

Si l’on souhaite par la suite utiliser une carte graphique ne possédant pas le firmware Apple, y apporter également la modification suivante, sans laquelle ma machine (dotée d’une carte graphique AMD R9 380) se fige à l’extinction lorsque plusieurs écrans y sont raccordés.

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nosplash"

Regénérer les fichiers de configuration de grub incorporant ces modifications, à l’aide de la commande suivante :

# update-grub

Conclusion

La machine démarre maintenant en 40 secondes montre en main, ce qui représente une nette amélioration du temps de démarrage précédemment obtenu avec la compatibilité BIOS, qui était supérieure a la minute, sans présenter d’autre inconvénient que de nécessiter une carte graphique Apple pour procéder à l’installation. (j’ai tenté par la suite de reproduire la procédure « à l’aveugle », sans résultat).

Il ne reste plus qu’à baillonner l’interruption gpe11, et optimiser le refroidissement de la carte graphique.

Cependant, l’argument noefi étant nécessaire au bon démarrage du noyau, mon ambition de pouvoir enfin editer la variable EFI assurant le réglage du volume du gong de démarrage est tombée à l’eau. Je me contenterai du temps de démarrage raccourci !

Sources :

https://forums.linuxmint.com/viewtopic.php?t=333755

https://help.ubuntu.com/community/MacPro

Notes :

Contrairement à l’installation effectuée en mode BIOS, le paramètre noyaux amdgpu.dc=0 n’est plus nécessaire pour obtenir un affichage avec ma carte graphique AMD.

Pour résoudre le problème rencontré à l’extinction de la machine, les arguments noyau suivant ont été essayés, sans résultat : amdgpu.runpm=0, reboot=pci, acpi=noirq et irq=off

Linux Mint : Installation avec BTRFS + Chiffrement Disque

Par : Pila

Cet article décrit la procédure pour installer Linux Mint avec un système de fichier BTRFS (permettant notamment de bénéficier de « snapshots » offrants une possibilité de restaurer le système à un état antérieur en cas de problème), tout en activant le chiffrement complet du disque dur.

L’installation débute comme une installation standard, puis :

1. A l’écran « Type d’installation« , choisir « Autre chose » :

2. Si nécessaire, créer une table de partition en cliquant sur le bouton « Nouvelle table de partition ». Attention, cette opération détruira la table de partition courante, et provoquera la perte des partitions actuellement sur le disque !

3. Créer une partition de type « Partition Système EFI », de taille 1024 Mo (c’est un peu excessif, mais cela évite de devoir la redimensionner plus tard). Pour cela, sélectionner l' »espace libre » en fin de disque, et cliquer sur le bouton « + ».

4. Créer une partition de type « Système de fichier ext2 », avec point de montage « /boot« , également de taille 1024 Mo.

5. Créer une partition de type « volume physique pour le chiffrement », occupant tout l’espace restant. Saisir la clé de sécurité qui sera demandée au démarrage de l’ordinateur pour déchiffrer le disque dur.

6. Un disque virtuel, contenant une seule partition de type ext4 , apparait alors, sous le nom /dev/mapper/xxx_crypt.

7. Choisir Btrfs comme système de fichier à la place de ext4, avec le point de montage « / ». Pour cela, sélectionner la partition, puis cliquer sur le bouton « modifier ».

8. Les différentes partition de votre système doivent correspondre à la capture d’écran ci-dessous. Cliquer alors sur « installer maintenant », et procéder à la suite de l’installation. Dans le cas d’une erreur, il est plus sage de redémarrer et de recommencer l’installation, l’installateur pouvant avoir un comportement erratique si l’on recommence l’installation après avoir déjà créé une partition chiffrée.

9. C’est terminé ! A chaque démarrage, l’écran suivant demandera le mot de passe permettant le déchiffrement du disque dur :

Cette procédure laisse par contre l’utilisateur sans espace d’échange (swap) configuré. Je n’ai pas encore expérimenté sur le sujet, mais la mise en place d’un fichier de swap (swapfile) sur une partition btrfs est assez bien documentée ( par exemple, ou encore ) , je me pencherai sans doute dessus à l’avenir.

Bonjour tout le monde !

Par : pilatomic

Bienvenue sur WordPress. Ceci est votre premier article. Modifiez-le ou supprimez-le, puis commencez à écrire !

Compiler Marlin en ligne de commande

Par : Pila

Cet article résume le process nécessaire pour compiler Marlin en ligne de commande sous Linux avec PlatformIO Core.

1. Installer 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é.

ABetterXinputCalibrator : un outil pour faciliter la calibration d’écran tactiles sous X11

Par : Pila

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

Screenshot :

https://gitlab.com/Pilatomic/abetterxinputcalibrator/-/raw/master/doc/Screenshot.png

Dépot gitlab :

https://gitlab.com/Pilatomic/abetterxinputcalibrator

MacPro 1,1 : Optimiser le refroidissement d’un GPU AMD sous Linux

Par : Pila

Sur ces machines, la ventilation est réalisée en 3 canaux séparés

  • Canal 1 : CPU & RAM : 2 ventilateurs, 1 en façade et 1 à l’arrière en extraction, dont la vitesse est régulée en fonction de la température CPU
  • Canal 2 : GPU et cartes d’extensions : 1 ventilateur en façade
  • Canal 3 : Alimentation & lecteurs optiques.

Sur mon système, si les canaux 1 et 3 sont gérés correctement par le SMC ( le chip chargé de la gestion du système ), le ventilateur du canal 2 a sa vitesse fixe à 500 tr/min. J’imagine que la cause est à trouver dans mon utilisation peut habituelle de cette machine : un GPU non officiel (AMD R9 380) sous un OS non officiel (Linux).

Pour pallier à ce problème, et effectivement piloter ce ventilateur en fonction de la demande en refroidissement du GPU, j’ai écrit un script bash, qui contrôle ce ventilateur en fonction de la commande PWM du ventilateur du GPU ( attention, à ma connaissance cette information n’est disponible que sur le pilote graphique libre AMD ) :

$ cat /opt/IO_fan_control.sh
#!/bin/bash

BASE_FAN="/sys/devices/platform/applesmc.768/fan2"
GPU_PWM_FILE="/sys/class/drm/card0/device/hwmon/hwmon0/pwm1"
GPU_PWM_MIN=75
GPU_PWM_MAX=250

function setfancontrolmanual()
{
        echo $1 > $BASE_FAN"_manual"
        if (( $? == 0 ))
        then
                if (( $1 == 0 ))
        then
                        echo "Returning fan control to SMC"
                else
                        echo "Taking control of fan from SMC"
                fi
        else
                if (( $1 == 0 ))
        then
                        echo "Failed to return fan control to SMC"
                        exit 1
                else
                        echo "Failed to take control of fan from SMC"
                        exit 1
                fi
        fi
}

function abort()
{
        setfancontrolmanual 0
        exit
}

function checkforroot()
{
        if(( $(id -u)  != 0 ));
        then
                echo "Need to be run as root";
                exit
        fi
}

checkforroot
if [ "$1" == "release" ]; then
        setfancontrolmanual 0
        exit
fi

trap abort SIGINT
setfancontrolmanual 1

while true
do
        INPUT_RPM=$(<$BASE_FAN'_input')
        MAX_RPM=$(<$BASE_FAN'_max')
        MIN_RPM=$(<$BASE_FAN'_min')
        GPU_PWM=$(<$GPU_PWM_FILE)

        #compute MAC fan RPM from GPU fan PWM
        if (( $GPU_PWM >= $GPU_PWM_MAX )); then
                TARGET_RPM=$MAX_RPM
        elif (( $GPU_PWM <= $GPU_PWM_MIN )); then
                TARGET_RPM=$MIN_RPM
        else
                TARGET_RPM=$(( ($MAX_RPM - $MIN_RPM) * ( $GPU_PWM - $GPU_PWM_MIN ) / ($GPU_PWM_MAX - $GPU_PWM_MIN) + $MIN_RPM))
        fi

        #clamp value between MIN_RPM and MAX_RPM
        if (( $TARGET_RPM < $MIN_RPM )); then
                OUTPUT_RPM=$MIN_RPM
        elif (( $TARGET_RPM > $MAX_RPM )); then
                OUTPUT_RPM=$MAX_RPM
        else
                OUTPUT_RPM=$TARGET_RPM
        fi

        echo $OUTPUT_RPM > $BASE_FAN'_output'

        echo 'INPUT_RPM: '$INPUT_RPM' MAX_RPM: '$MAX_RPM' MIN_RPM: '$MIN_RPM' GPU_PWM: '$GPU_PWM' TARGET_RPM: '$TARGET_RPM' OUTPUT_RPM: '$OUTPUT_RPM

        sleep 2
done

Les variables GPU_PWM_MIN et GPU_PWM_MAX correspondent respectivement aux 2 valeur PWM à laquelle le ventilateur du canal 2 sera commandé à sa vitesse minimum, et celle où il sera commandé à sa vitesse maximum.

Ce script est exécuté automatiquement au démarrage grâce à systemd

$ cat /etc/systemd/system/system_mac-io-fan-control.service
[Unit]
Description=MacPro IO fan control from GPU temperature
After=systemd-udevd.service

[Service]
ExecStart=/opt/IO_fan_control.sh
Restart=always
StartLimitIntervalSec=10
ExecStopPost=/opt/IO_fan_control.sh release

[Install]
WantedBy=multi-user.target

Il ne reste plus qu’à activer l’unité systemd créé :

$ sudo systemctl enable system_mac-io-fan-control.service
$ sudo systemctl start system_mac-io-fan-control.service

La vitesse du ventilateur du canal 2 est maintenant asservie à celle du GPU, facilitant le refroidissement de ce dernier, et réduisant le niveau sonore de la machine.

MacPro 1,1 : Linux trucs & astuces

Par : Pila

Installation réalisée sous Linux Mint 20 avec un kernel 5.4

Boot avec PlopKexec.

Une distro 64bit fonctionne parfaitement. Se référer à mon précédent article http://pila.fr/wordpress/?p=1078

Obtenir un affichage avec un GPU AMD

Les cartes graphiques AMD exploitant le nouveau code d’affichage « DC » provoquent un kernel panic. Il faut ajouter la commande suivante dans le fichier /etc/default/grub pour utiliser l’ancian code :

amdgpu.dc = 0

Ne pas oublier d’appliquer les changements :

$ sudo update-grub 

Bâillonner l’interruption gpe11

Sur cette machine, le taux d’occupation CPU restait important même au repos. Il s’avère que l’IRQ 9 est déclenchée à une fréquence très élevée (indiqué par le compteur du fichier /proc/interrupts), et monopolise à elle seule un des coeurs CPU. Les compteurs lisibles dans les différents fichiers à l’emplacement /sys/firmware/acpi/interrupts nous permettent de déterminer la source de cette IRQ : gpe11. Un service systemd nous permet de la désactiver, en créant le fichier /etc/systemd/system/disableGPE11.service avec le contenu suivant :

[Unit]
Description=Disables GPE 11 going crazy on this MacPro
[Service]
ExecStart=/bin/bash -c 'echo "disable" > /sys/firmware/acpi/interrupts/gpe11'
[Install]
WantedBy=multi-user.target

Ce service est rendu actif par la commande suivante :

$ sudo systemctl enable disableGPE11.service


Développer sur STM32 avec stm32plus, OpenOCD et QtCreator

Par : Pila

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

Par : Pila

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.

Installation de l’émulateur PPSPP

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

Installation de la toolchain

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.

Isolement de la toolchain

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.

Compilation des examples

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 :

L’exemple CUBE du PSPSDK

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à !

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

Par : Pila

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 !

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

Par : Pila

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

Configuration

La configuration s’effectue en enclenchant l’interrupteur situé derrière le monnayeur. Attention, contrairement aux apparences, il s’agit d’un interrupteur 2 à positions stables : 1 appui passe en mode configuration, et un second appui est nécessaire pour en sortir.

Les différents paramètres sont reconnaissables par leur numéro sur l’afficheur 7 segment. On passe au paramètre suivant en poussant le joystick vers la gauche, et on change la valeur en poussant le joystick vers la droite. Certains paramètres ne sont pas modifiables, comme les compteurs de nombre de parties.

L’ensemble des paramètres disponibles sont regroupés dans le tableau suivant. Malheureusement, le rôle de certains m’échappent encore (la fonction de ces paramètres est marquée d’un point d’interrogation dans le tableau), si vous en savez plus, n’hésitez pas à me contacter, je mettrai à jour cet article.

ParamètreValeur origValeurs possiblesIncrémentFonction
10[0:1]1?
210[0:10]1Nombre arrêt descente pince possibles
30[0:1]1Descente pince dans conduit
4500 + [50:99]1Rentabilité ?
50[0:1]1Désactiver son descente pince
60[0:1]1Désactiver autre son ( son gagnant ) ?
70 4155Compteur nombre de crédits
80 0622Compteur parties gagnées
90 0002Compteur triche monayeur ?
10?
1110[10:30]5Durée partie
122[0:10]1Nombre de pièces (1€) pour jouer
131[0:10]1Nombre de parties
140[0:1]1Autoriser mouvement pince au sol
151[0:1]1?
160[0:1]1?

Pour valider la configuration souhaitée, il suffit de repasser en mode exploitation, en appuyant sur le bouton situé derrière le moniteur.

Mise en lecture seule de l’EEPROM

Dans l’environnement où cette machine est utilisée (coupures de courant fréquentes), il est vite apparu que cette machine avait un gros défaut de fiabilité. Des dysfonctionnement réguliers, allant du changement de valeur aléatoire de certains paramètres de la configuration, au refus pur et simple d’accepter des pièces, furent observés. Tous ayant pour point commun des valeurs aberrantes de certains paramètres ( parfois totalement en dehors de la gamme de valeurs possibles ). Il est vite devenu évident que l’EEPROM stockant les paramètres devenant corrompue, probablement à la suite d’une coupure de courant intervenue au mauvais moment (lors de l’écriture de l’EEPROM).

Située dans un coin de la carte, il s’agit d’une CI 24LC04B, une EEPROM 4K interfacée en I²C, produite par Microchip.

La documentation de ce CI indique qu’une broche (nommée WP), permet, en la raccordant au VCC, d’empêcher l’écriture de l’EEPROM, ce qui résoudrait sans doute mon problème de fiabilité !
Malheureusement, cette broche est reliée à la masse via une piste située juste en dessous de l’EEPROM. Il est donc d’abord nécessaire de dessouder cette dernière, pour pouvoir couper cette piste :

Ensuite, il ne reste plus qu’à réinstaller l’EEPROM, une résistance de 1kohms tirant cette broche à la masse, et un petit cavalier permettant de la raccorder directement au VCC, engageant ainsi la protection en écriture :

Attention tout de même : il est nécessaire de retirer le cavalier avant de modifier la configuration de la machine, sans quoi les modifications ne seront pas appliquées. De plus, en cas de coupure de courant pendant une partie, les crédits en cours ne sont plus sauvegardés ! Dans mon cas, la machine étant exploitée comme objet de décoration, il s’agit plus d’un avantage que d’un inconvénient.

Modification du monnayeur

Cette machine étant utilisée en décoration et comme objet de loisir, le monnayeur a été retiré, et remplacé par un détecteur optique ( réalisé à partir d’un détecteur optique à fourche), créditant toute pièce et la rendant immédiatement au joueur. Quelques photos de cette modification :

  • La fourche optique donneuse
  • La partie émetteur/bornier
  • La partie émetteur installée
  • La partie récepteur installée dans le monnayteur modifié (retrait du bloc monnayeur, replacé par un guide pièce en plexiglas doté de chicanes pour ralentir la pièce)
  • Récepteur, coté pistes
  • Emetteur, coté piste

Si cet article vous a été d’une aide précieuse, ou si vous pensez qu’une information est manquante, n’hésitez pas à m’en faire part dans les commentaires !

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

Par : pilatomic

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

Par : pilatomic

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

Par : Pila

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

Configuration du Raspberry Pi

Installer les packages nécessaires :

$ apt-get install pulseaudio avahi-daemon dbus-x11

Configurer PulseAudio, en ajoutant à la fin du fichier /etc/pulse/system.pa, la ligne suivante (dans ce cas, tous les clients du réseau 192.168.0.0/24 sont autorisés à se connecter)

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24

Ajouter ensuite un service systemd pour PulseAudio, en créant le fichier /etc/systemd/system/pulseaudio.service, avec pour contenu :

[Unit]
Description=PulseAudio Daemon

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
PrivateTmp=true
ExecStart=/usr/bin/pulseaudio --system --realtime --disallow-exit --no-cpu-limit

Il ne rester qu'à activer le service, puis à le démarrer :

$ systemctl enable pulseaudio

$ systemctl start pulseaudio

A ce stade, la mise en place du coté du Raspberry Pi devrait être achevée. Cependant, chez moi, cette configuration produisait des craquements très audibles.

Le problème a été résolu en éditer le fichier /etc/pulse/system.pa, et en remplaçant la ligne

load-module module-udev-detect

Par

load-module module-udev-detect tsched=0

A partir de là, 2 choix (qui ne sont pas mutuellement exclusifs, les 2 cohabitent très bien) s'offrent à vous :

Découverte manuelle :

Plus fiable que la découverte automatique, mais plus contraignante (nécessite de configurer chaque ordinateur voulant exploiter la sortie son du Raspberry, et ne fonctionne pas si le Raspberry n'est pas joignable au démarrage de l'ordinateur source)

Sur l'ordinateur source, ajouter dans le fichier /etc/pulse/default.pa la ligne suivante :

load-module module-tunnel-sink-new server=XXX.XXX.XXX.XXX sink_name=Remote sink_properties="device.description='Raspberry'" channels=2 rate=44100

En indiquant l'adresse IP du Raspberry

Découverte automatique

Sur le Raspberry, installer les packages nécessaires :

$ apt-get install pulseaudio-module-zeroconf

Toujours sur le raspberry, configurer PulseAudio, en ajoutant à la fin du fichier /etc/pulse/system.pa, la ligne suivante

load-module module-zeroconf-publish

Sur l'ordinateur source, installer le paquet de configuration du PulseAudio

$ apt-get install paprefs

Exécuter paprefs, puis activer la découverte des appareils en réseau :

Redémarrer ensuite l'ordinateur cible, le Raspberry devrait être disponible comme nouvelle sortie son !

Conclusion

En commençant cette manipulation, j'avais peur que la latence de l'audio ne la rende inutile.

Si un peu de latence se fait en effet sentir (+200ms mesurés par rapport à une sortie sur la carte son interne du PC), elle est toutefois suffisamment faible pour ne pas perturber un usage d'écoute musicale.

Pour une utilisation Home Cinéma en revanche, il se peut que cette latence pose problème, à vous de juger !

Source :

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

Par : Pila

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

Par : Pila

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 !

Asus GTX780 ROG Poseidon : Réparation du système de refroidissement

Par : Pila

Commercialisée par ASUS début 2014, la GTX780 ROG Poseidon est une carte graphique haut de gamme, dotée de 3 Go de VRAM, et d'un système de refroidissement hybride : celui-ci est en effet composé d'un large dissipateur, épaulé par 3 caloducs, et refroidit par 2 ventilateurs, mais intègre également un (court) circuit eau, permettant un refroidissement par watercooling.

Ce système de refroidissement est également muni d'un logo "Republic Of Gamer" rouge clignotant, jouant sans aucun doute un rôle extrêmement important dans le fonctionnement de la carte, tel que changer un PC en discothèque, ou pire encore ...

l'ASUS GTX780 ROG POSEIDON (ventilateurs débranché)

Et c'est justement ce système de refroidissement qui m'a donnée du fil à retordre, puisqu'un beau jour, les ventilateurs ont tout bonnement cessé de fonctionner. Si cela ne pose aucun problème visible en utilisation bureautique de la carte (la fréquence ainsi que la tension d'alimentation du GPU étant fortement réduites dans ce type d'utilisation, la faible dissipation thermique qui en résulte permet de maintenir le GPU dans une plage de température acceptable, même sans aucun ventilateur en fonction), lors d'une utilisation pour du rendu 3D (principalement en jeu), c'est une toute autre histoire, la température du GPU augmentant rapidement de manière alarmante, jusqu'à son arrêt pur et simple, provoquant une perte de l'affichage jusqu'au redémarrage de la machine.

J'ai donc entrepris d'en réparer le système de refroidissement ...

Les 2 ventilateurs ne démarrant pas, mais tournant cependant librement sur leur axe, ma première hypothèse fut que le contrôleur des ventilateurs, intégré à la carte, avait cessé de fonctionner. Pour vérifier cela, rien de plus simple, il suffit de démonter les ventilateurs, et de les tester indépendamment. Séparer les les ventilateurs du dissipateur n'est pas une mince affaire, et implique de se battre contre plusieurs clips plastiques, visibles après coup sur la photo ci dessous :

Les ventilateurs enfin séparés du dissipateur

Les ventilateurs sont alors testés séparément, à l'aide d'une alimentation de laboratoire, réglée pour fournir 12V (1A max) via le connecteur 5 points qui les relie normalement à la carte graphique, et ...

Rien ne se passe ....

Comment ça, rien ?? Enfin, pas exactement rien, l'alimentation de labo indique 0V, 1A, c'est un court circuit franc ! Fichtre, un des ventilateurs est sans doute décédé ...

Avant d'aller plus loin, observons le câblage des dits ventilateurs : comme écrit précédemment, ceux-ci sont raccordés à la carte graphique par le biais d'un connecteur 5 points, véhiculant les signaux suivants : Masse, +12V, commande PWM pour la vitesse, ainsi que 2 signaux de retour indiquant la vitesse effective de chaque ventilateur. De ce connecteur partent 2 séries de fils : l'une va sur un ventilateur, tandis que l'autre dessert un second connecteur, d'où partent également 2 séries de fils : l'une desservant le second ventilateur, et l'autre alimentant le logo ROG clignotant.

Et si ... ?

Essayons à nouveau avec le fameux logo ROG débranché :

Le logo ROG débranché, les ventilateurs reviennent à la vie

Cette fois, les ventilateurs s'animent ! Plus de court circuit, qui provenait donc du logo clignotant.

En le démontant, on découvre un PCB relativement simple, comportant quelques leds, un jeu d'AOP LM324, ainsi que quelques composants génériques, rien de bien folichon :

Je n'ai pas pris le temps d'autopsier ce module, peu importe, son fonctionnement était agaçant de toute façon...

Ses ventilateurs réinstallés, la carte prend place dans mon PC, et c'est l'instant fatidique : démarrage !

la GTX780 en phase de test

Et les ventilateurs ne tournent toujours pas...

Ce qui, après réflexion, semble assez logique : un court circuit aussi franc que celui qui a eu lieu ici sur l'alimentation des ventilateurs à forcément endommagé le circuit d'alimentation des ventilateurs. Sans doute trouvera-t-on une piste brulée, ou un shunt grillé sur le PCB de la carte.

Cette recherche nécessite de séparer le système refroidissement du PCB de la carte, opération que j'avais jusqu'alors soigneusement évitée, étant précédemment en pénurie de pâte thermique, indispensable lors du ré-assemblage pour remplacer la pâte thermique d'origine, qui ne survit pas au démontage.

Le système de refroidissement séparé du PCB

Une fois le PCB entièrement accessible, on s’intéresse aux pistes menant au connecteur 5 pins qui alimente les ventilateurs. Et il ne faut pas longtemps pour identifier un coupable potentiel :

Juste à coté du connecteur, ce shunt semble avoir rendu l’âme

A proximité du connecteur, raccordé à la broche délivrant le +12V au système de refroidissement, une résistance marquée 0 (ayant donc un rôle de shunt ou de fusible) porte des traces de dommages. Elle est immédiatement remplacée :

La résistance remplacée. note pour la prochaine fois : acheter du nettoyant de flux

Une fois la résistance remplacée, la carte est réassemblée, le GPU recouvert de pâte thermique Artic Silver MX2, et reprend place dans mon PC.

Démarrage, et les ventilateurs s'animent enfin !

Windows se lance sans problème, mais surtout, la carte reste en fonctionnement lors d'applications 3D, avec des températures honorables de l'ordre de 70 °C !

Bref, une franche réussite. Il est cependant dommage que cette panne soit causé par un élément aussi insignifiant (et inutile) que le logo clignotant ! Il aurait été sage de la part d'ASUS de lui fournir son propre rail 12V, ou encore plus simplement, de le doter de son propre fusible, afin que sa défaillance n'interfère pas avec le fonctionnement du système de refroidissement !

Réparation d’une mini-chaine Dynabass DBT150

Par : Pila

Cet article décrit la réparation d'une minichaine Dynabass DBT150, qui refusait obstinément de s'allumer.

La DBT150 est une minichaine sur pied, avec fonctions radio / CD / USB / AUX / Bluetooth... et celle-ci refuse de fonctionner !

On y découvre que le transformateur d'alimentation est endommagé au delà de toute possible réparation, et comment contourner le problème en remplaçant toute l'alimentation par des éléments courants.

La séparation du pied, puis le démontage du panneau arrière s'effectuent en retirant les multiples vis de la face arrière :

L'intérieur est spartiate...

Mes premiers soupçons se portent sur la carte située entre la prise secteur et le transformateur :

Le rôle de cette carte semble être de commuter, sur demande du microcontrôleur central, l'alimentation du transformateur général. Soit celui-ci est relié directement au secteur, soit il l'est à travers le condensateur rouge. S'agirait-il d'une bizarrerie visant à respecter les normes de consommation en réduisant la consommation du transformateur lorsque l'appareil est en mode de veille ?

Quoi qu'il en soit, la carte est rapidement mise hors de cause, le primaire du transformateur s'avère être ouvert. La cause semble être une diode de redressement située sur l'un des enroulements secondaires du transformateur qui est en court circuit ; le secondaire du transformateur s'est alors retrouvé en court circuit une alternance sur 2, causant un fort échauffement, et le déclenchement du thermofusible intégré à son enroulement primaire.

Feu le transformateur d'alimentation

Malheureusement, la construction du transformateur empêche toute tentative de débobinage / réparation de ce dernier, et ses caractéristiques non standard prohibent l'obtention d'une pièce de remplacement. Il va donc falloir recréer une alimentation complète. Commençons par étudier la topologie du système :

 

L'alimentation utilise 2 enroulements secondaires du transformateur

Étrangement, le bloc lecteur CD / USB est alimenté par un enroulement dédié du transformateur, son alimentation est totalement isolée du reste de l’électronique sur la carte principale. Cette conception m'a initialement fait craindre que les deux rails d'alimentation ne partagent pas la même masse, ce qui aurait compliqué la réalisation d'une nouvelle alimentation basée sur des éléments préexistants. Heureusement, les masses sont en réalité raccordées au sein du bloc lecteur CD / USB. Le fait de ne pas les raccorder sur la carte principale a probablement pour objectif réduire le bruit qui pourrait être causé par une boucle de masse.

Cependant, lors de la réalisation de la nouvelle alimentation, je vais devoir mettre en commun les masses au niveau de l'alimentation. Je prévois en effet une alimentation principale délivrant la tension de 26V, et l'emploi d'un convertisseur buck (DC/DC non isolé) pour générer la seconde alimentation destinée au bloc lecteur CD / USB. Ne pas raccorder la masse au niveau de l'alimentation signifierait que tout le courant retournant du bloc lecteur CD/USB circulerait à travers la masse du câble de petite section destiné aux signaux audio, ce qui au mieux dégraderait la qualité sonore de façon bien plus marquée d'une boucle de masse, ou au pire pourrait endommager ce câble.

Le schéma de la nouvelle alimentation est le suivant :

La topologie de la nouvelle alimentation

Celle-ci repose sur un chargeur de PC portable pour générer la tension principale de 19V alimentation l'amplificateur et l'essentiel de l'électronique. Bien qu'inférieure à la tension originale de 26V, celle-ci devrait suffire à délivrer un niveau sonore satisfaisant. Un module DC/DC à base de LM2596, qui prend place dans l’alcôve du transformateur, permet de générer la tension d'alimentation de 11V pour le bloc lecteur CD / USB.

Les raccordements du convertisseur DC/DC et du chargeur de PC portable sont réalisés à la place des ponts de diodes

L'emplacement original de la connectique secteur contient maintenant le raccordement du chargeur de PC portable

Vient le moment fatidique, la mise sous tension !

Tout fonctionne parfaitement, aucune saturation détectable à l'oreille (c'était ma principale inquiétude quant à l'emploi d'une tension plus faible que celle d'origine)

La chaine en fonctionnement avec sa nouvelle alimentation

Un effet intéressant lié à l'utilisation d'une alimentation à découpage à place de l'ancienne alimentation : lorsque l'on débranche le secteur, l'alimentation se maintient pendant plusieurs seconde (le chargeur de PC portable est prévu pour délivrer jusqu'à 4A, ici on consomme rarement plus de 0.5A). Donc pas d'interruption de la musique en cas de micro-coupure du réseau EDF !

En espérant que si toi lecteur tu es arrivé jusqu'ici, c'est que cet article t'a permis de réparer ta minichaine 😉

Un minitel comme terminal linux USB. Partie 3 : Et avec systemd ?

Par : Pila

Il y a 2 ans déjà, je publiais 2 articles décrivant comme réutiliser un Minitel comme terminal linux USB :

Cependant, si le premier article est toujours aussi pertinent, avec la migration des distributions Linux vers systemd, le nouveau gestionnaire de démarrage, le second article ne permet plus de configurer les Linux moderne pour utiliser le Minitel comme terminal.

raspi-config Minitel

l'outil de configuration raspi-config sur Minitel

Cet article vise donc à décrire la procédure nécessaire pour réaliser cette opération avec systemd sur Raspberry Pi sous la distribution Raspbian, mais cette procédure devrait s'appliquer, éventuellement avec des modifications mineures, à tout autre matériel exécutant une distribution Linux dotée de systemd.

Tout d'abord, systemd n'utilise plus le fichier innitab et les scripts de démarrages, mais raisonne en terme de services, chaque service étant décrit par un fichier contenant la commande à exécuter, des diverses informations, telles que les dépendances du services.

Un service en particulier est dédié à la gestion des terminaux série : serial-getty@.service

Cependant, il ne comporte pas les bonnes options de configurations pour dialoguer avec un Minitel, nous allons donc créer notre propre service, adapté à cet effet. :

Commençons par créer une copie du service, qu'on modifie ensuite :

sudo cp /lib/systemd/system/serial-getty@.service /etc/systemd/system/serial-getty-minitel@.service
sudo nano /etc/systemd/system/serial-getty-minitel@.service

Les modifications apportées au fichier concernent la ligne de commande exécutée (getty avec les options adéquats, à la place de agetty), et la suppression de l'attente de plymouth pour démarrer ( en gras ci-dessous)

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Serial Getty on %I
Documentation=man:agetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
After=dev-%i.device systemd-user-sessions.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

[Service]
ExecStart=-/sbin/getty -L -i -I "\033\143" %i 4800 minitel1b-80
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target

Ensuite, il ne reste plus qu'à ajouter un lien sur ce fichier dans le répertoire getty.target.wants. Ce lien comporte une indication sur le périphérique concerné (ici ttyUSB0). systemd remplacera toutes les occurrences de %i dans le fichier serial-getty-minitel@.service par cette valeur.

sudo ln -s /etc/systemd/system/serial-getty-minitel@.service /etc/systemd/system/getty.target.wants/serial-getty-minitel@ttyUSB0.service

On redémarre le processus de systemd :

sudo systemctl daemon-reload

Puis on lance manuellement notre service (ou on redémarre le raspberry)

sudo systemctl start serial-getty-minitel@ttyUSB0.service

Et voilà, on retrouve le même fonctionnement obtenu précédemment en modifiant le fichier inittab 🙂

 

 

Pour plus d'info sur l'utilisation du minitel comme terminal sous Linux, voir les parties précédentes :

Source  : doc serial-getty@.service

❌