[Lefinnois.net]      «Nisi credideritis, non intelligetis»

Certains le savent, juste derrière les leds, j'adore les écran LCD type HD44780 (lcdproc, lcd4linux, etc). Je viens de recevoir des 16T202DA1J de Samsung achetés sur eBay pour moins de 20 Euros pièces (port inclus). Certes, c'est deux fois plus cher que le LCD mais franchement, ça a une autre gueule. Comme le brochage est parfaitement compatible avec les LCD HD44780, c'est interchangeable directement sur mon module USB/série/AVR permettant un contrôle USB de l'affichage. De quoi décorer bon nombre de montages embarqués et mes serveurs...

Bon, on ne peut pas faire de PWM sur le rétro-éclairage (puisqu'il n'en en a pas) mais le rendu et la luminosité de l'ensemble compense largement.

Hé oui, le temps passe vite et nous sommes à nouveau le SysadminDay. Le jour dans l'année où l'on peut dire à son sysadmin qu'on l'aime car c'est grâce à lui que tout fonctionne, qu'on peut relever ses mails, qu'on retrouve un fichier bêtement supprimé et qu'on peut regarder du pr0n tranquillement au bureau...

Alors c'est le moment de lui offrir un mug, de lui faire sa patisserie préférée ou, pour une fois, de regarder s'il reste du papier dans l'imprimante avant de le déranger parce que "ça n'imprime pas".

Je viens tout juste de recevoir un nouveau programmeur AVR sur port USB. Bonne nouvelle, celui-ci propose non pas un port série de type ttyACM* mais deux (le second fournissant un port USB/TTL simple). Mauvaise nouvelle, une règle udev classique (voir ce billet) ne fonctionne pas. En effet, la règle match les deux interfaces et on se retrouve systématiquement avec un lien symbolique pointant sur la seconde interface. Le programmeur est inaccessible proprement via un Makefile.

Le problème ici est de mixer des attributs provenants à la fois du périphérique (product) et du périphérique parent (bInterfaceNumber). Ceci ne fonctionne donc pas :

SUBSYSTEMS=="usb", KERNEL=="ttyACM*", ATTRS{product}=="Pololu USB AVR Programmer", \
  SYMLINK+="POLOLU"

Pas plus que :

SUBSYSTEMS=="usb", KERNEL=="ttyACM*", ATTRS{product}=="Pololu USB AVR Programmer", \
  ATTRS{bInterfaceNumber}==02, SYMLINK+="POLOLU_SERIAL"
SUBSYSTEMS=="usb", KERNEL=="ttyACM*", ATTRS{product}=="Pololu USB AVR Programmer", \
  ATTRS{bInterfaceNumber}==02, SYMLINK+="POLOLU_SERIAL"

Il faut être plus tordu et réutiliser le nom d'un attribut du périphérique pour nommer le lien symbolique avec :

SUBSYSTEMS=="usb", KERNEL=="ttyACM*", ATTRS{product}=="Pololu USB AVR Programmer",  \
  SYMLINK+="POLOLU%s{bInterfaceNumber}"

Ce qui nous donne :

% ls -l /dev/POL*
13099267 lrwxrwxrwx 1 root root 7 jui 21 21:01 /dev/POLOLU00 -> ttyACM0
13099249 lrwxrwxrwx 1 root root 7 jui 21 21:01 /dev/POLOLU02 -> ttyACM1

Pareil en présence d'un autre programmeur ttyACM* :

13105697 lrwxrwxrwx 1 root root 7 jui 21 21:10 /dev/POLOLU00 -> ttyACM1
13105715 lrwxrwxrwx 1 root root 7 jui 21 21:10 /dev/POLOLU02 -> ttyACM2

Ça n'est pas exactement ce que je voulais (POLOLU0 et POLOLU1) mais c'est fixe et clair. On va pas chercher la petite bête...

Le tabletPC n810 de Nokia est un super jouet. La première chose installée est un client OpenVPN pour pouvoir se connecter à ses ressources en toute sécurité (relative) depuis n'importe où. Parmi ses ressources il y a un serveur Asterisk. Le n810 intègre, en effet, un client VoIP. De quoi s'amuser, téléphoner via un forfait depuis n'importe quel endroit et surtout recevoir des appels comme si on était chez soi.

Seulement voilà : çapamarche ! Impossible de s'enregistrer sur le serveur Asterisk pourtant  à l'autre bout du VPN. Après quelques recherche, il s'avère que le problème ne vient pas d'Asterisk et encore moins d'OpenVPN mais bien de la configuration sur le n810. Le bestiaux n'utilise pas l'adresse local VPN par défaut, il faut le lui préciser explicitement.

On ouvre donc un terminal (j'adore des périphériques mobiles avec un terminal), on passe en root avec root et on utilise :

mc-account set sip0 string:local-ip-address=ADRESSE_LOCALE_DU_VPN

Magie, le client sip/VoIP se connecte et tout roule.

Il est possible d'automatiser la configuration mais j'étais trop impatient pour configurer cela avant de poster. Explications sur : http://talk.maemo.org/archive/index.php/t-20921.html

Heureux propriétaire que je suis d'une carte FXO X100P pour mon Asterisk, j'ai eu la mauvaise idée de mettre à jour mon kernel en 26.29 sur ma chère Debian. Là impossible de recompiler le module avec m-a. Après recherche et environs 50 checkout SVN... je me suis rendu compte qu'il n'y a pas que zaptel-source dans la vie mais aussi dahdi-source.

Ainsi, aptitude install dadhi-source, m-a -t a-i dahdi-source et modprobe wcfxo... et :

[874853.416148] dahdi: Telephony Interface Registered on major 196
[874853.416151] dahdi: Version:
[874853.418471] wcfxo 0000:03:07.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[874853.460005] NOTICE-wcfxo: WCFXO/0: Unknown DAA chip revision: REVB=0
[874853.460008] Failed to initailize DAA, giving up...
[874853.460058] wcfxo: probe of 0000:03:07.0 failed with error -5

Voir la suite »

Coup de nostalgie ! Bien avant MP3, bien avant GNU/Linux... il y avait des machines de rêve comme l'Amiga, le ST... et pour mal part le C64 (mais rien à voir). En ce temps là, il y avait un format : le MOD.

Pour faire revenir les sons du passé dans le présent, sur mon iPod Nano, il me fallait convertir ces MODs en MP3. Après 5mn de recherches infructueuses, j'ai décider d'utiliser la méthode bouts-de-ficelles :

#!/bin/bash
MIKMOD=/usr/bin/mikmod
LAME=/usr/bin/toolame
SOX=/usr/bin/sox
ID3V2=/usr/bin/id3v2
HEAD=/usr/bin/head

SONGNAME=`basename $1 .mod`

$MIKMOD  -p 0 $1
mv music.raw $SONGNAME.raw

$SOX -r 44100 -c 2 -w -s $SONGNAME.raw $SONGNAME.wav
rm $SONGNAME.raw

$LAME $SONGNAME.wav $SONGNAME.mp3
rm $SONGNAME.wav

$ID3V2 -t "`$HEAD -c 20 $1`" -A "MODFILES" -a "MODlovers" $SONGNAME.mp3

mikmod, par défaut produit un fichier RAW, stéréo, 16bits, 44100Hz. Sur la base de ces informations, on peut utiliser sox pour en faire un WAV qui sera, ensuite compresser en MP3 avec toolame.

Enfin, le format MOD permet d'inclure un titre au morceau sous la forme des 20 premiers octets du fichier (avec un padding avec des espaces). On peut donc utiliser head pour récupérer ces infos et en faire le tag "titre" ID3v2 du MP3 avec id3v2.

Bon, clairement, je ne sais pas trop à quoi cela pourrait servir mais c'est possible. Donc, bon.

En faisant quelques recherche avec Google, j'ai remarqué que l'indicateur de popularité du site (à gauche de l'URL en vert) dans les résultats de recherches n'était pas un fichier PNG mais des données PNG embarquées directement dans le HTML. En creusant un peu, voici...

On fait un petit script PHP pour simplifier les choses :

#!/usr/bin/php
<?php
while($line=fgets(STDIN)){
  echo (rawurlencode($line));
}
?>

Puis on utiliser tout simplement cat pour dumper les données et les envoyer sur STDIN du script et rediriger le tout dans un fichier :

% cat ~/deblogo.png | ./rawurlencode > /tmp/index.html

On ajoute ensuite les balises HTML qui vont bien :

<html>
<body>
<img src="data:image/png,%89PNG%0D%0A%1A[...]%AEB%60%82" width="48" height="48">
</body>
</html>

Et voilà ! Ça peut toujours servir pour une interface HTML d'un système embarqué...

Ah oui ! Il est aussi possible d'encoder en base64, ce qui évite d'utiliser PHP :

% base64 -w 0 ~/deblogo.png > index.html

La syntaxe du tag précise alors l'encodage en question :

<img src="data:image/png;base64,iVBORw0KGgoAA[...]FTkSuQmC" width="48" height="48">