Greetings from the free side / T'as le bonjour du libre !

Aller au contenu | Aller au menu | Aller à la recherche

Tag - développement

Fil des billets - Fil des commentaires

mercredi 30 mai 2007

Au boulot ! Driver, carte de test, udev, ports en user-space

J'ai toujours l'impression d'être un mauvais développeur. D'avancer moins vite que les autres. Le fait de ne pas avoir de "mentor", de personne qui me tire vers le haut (côté code) dans mon entourage professionnel ou personnel y est sans doute pour beaucoup. Alors évidemment, quand je lis Richard Hugues et ce qu'il fait alors qu'il finit à peine ses études, j'ai la larme à l'oeil, moi qui n'ai jamais eu de cours d'UML ou design patterns, ni d'architecture logicielle... J'ai dû apprendre sur le tas...

Mais c'est mon métier, alors je ne lâche pas l'affaire :-) (et puis bon, j'ai déjà repris du code - professionnel -, et ça m'a fait suffisamment peur pour que je me dise que ça vaut le coup de continuer, parce qu'il y a largement pire que moi...)

Les designs patterns, j'ai vu ça en fin d'année dernière, après avoir acheté le fameux Head First Design Patterns (merci à pvanhoof pour ça ;-)). Alors oui, je me dis que voir ça 5 ans après être sorti de l'école et 8 ans après avoir commencé ma vie professionnelle, c'est quand même dommage. Jj'aurais préféré avoir vu ça en école d'ingé, mais l'option de dernière année que je souhaitais faire, "génie logiciel", n'a pas ouvert, faute de demande. Alors je me suis retrouvé en "systèmes numériques" (ce qui était bien aussi, parce que que j'aime aussi l'électronique numérique).

Mais en ce moment je fais des choses intéressantes au boulot. Certes, ça n'avance pas très vite (bon, j'ai l'habitude), mais je ne vois pas le temps passer. Alors voilà un peu sur quoi je m'amuse depuis jeudi dernier...

Développement de driver E/S
Je dois développer un driver pour le kernel 2.6.18, afin de commander des entrées/sorties numériques. Je n'ai jamais développé de driver auparavant, alors j'ai dû fouiller un peu.
Liens utiles:
Writing device drivers in Linux: A brief tutorial
Linux Device Drivers, Third Edition

Carte de test E/S
Qui dit hard à contrôler dit souvent carte de test. Comme je ne suis pas du tout sûr des commandes que j'envoie pour commander les E/S, je me suis monté une carte de test (un grand mot pour 4 LED et 4 résistances) pour vérifier que les connecteurs ont été bien reliés par le sous traitant (c'est pas gagné apparemment), et vérifier que mes commandes font bien ce que j'attends.
C'est bien sûr beaucoup plus drôle quand on ne sait pas comment le sous traitant a relié le connecteur (DB9) aux pins de la carte mère (10 broches). Où serait le fun sinon ?

Code de test dans l'espace utilisateur
Comme les E/S de cette carte se commandent bizarrement, (une interruption qui appelle une sous-fonction dans le BIOS), et que je ne sais pas encore vraiment quelles commandes envoyer, j'utilise pour la mise au point un programme en user-space. Il doit tourner en root pour pouvoir accéder au matériel, et c'était une des solutions possibles (et simple), mais je ne souhaite pas que l'application finale tourne sous root (sécurité oblige).
Lien utile:
Linux I/O port programming mini-HOWTO

Recherche de bug de règle udev
Pour un autre périphérique, le fournisseur me donne un driver et une règle udev. J'ai trouvé sa règle codée comme un goret. La procédure d'install est un truc à base de Makefile fait à la main, et quand on est habitué aux trucs cleans fournis par les distributions... on se rend compte que d'autres en sont encore loin.
Le périphérique est une caméra usb. La règle udev du constructeur cherche à modifier les droits d'accès du périphérique dans /proc/bus/usb/, et il n'y a que comme ça qu'on peut lancer sans être root une application qui verra le périphérique connecté. Sauf que sa règle ne marche pas sous ma Fedora Core 6, alors que ma règle fonctionne (change les permissions du device, et le groupe), mais dans /dev/bus/usb/. Pourquoi diable passent ils par /proc ? C'est ce qui se faisait avant udev ?
Update:
Mon contact me dit que c'est ce qui se faisait avant le kernel 2.6.14.

Lien utile:
Writing udev rules


Bref, tout ça c'est très motivant, mais ça me prend aussi beaucoup de temps, surtout que tout ça est à 80% nouveau pour moi ! C'est dans ces moments que je ne suis pas mécontent d'habiter à 15 minutes en voiture du boulot :-)

mardi 27 mars 2007

Oisiweb: Comment afficher une chaine de caractères avec des accents ?

Cher oisiweb (oisif+web, traduction libre de lazyweb),
je me sens actuellement désoeuvré devant ce problème qui semble pourtant simple: afficher des caractères accentués dans mon programme en mode texte.

C'est un programme d'une extrême complexité, je te laisse juger:

#include <glib.h>
int main (void)
{
g_print("éèân");
return 0;
}
Pourtant, que le fichier soit enregistré en iso-8859-1 ou en utf8, pas d'accents. J'ai essayé aussi les entêtes spéciaux (coding cookie):
/* -*-coding: utf-8; -*- */
J'ai aussi essayé l'option -finput-charset de gcc, mais non, je n'obtiens aucun résultat concluant. Alors cher oisiweb, aurais tu la solution à ce problème ?

Update 1:
D'après les exemples du guide officiel du développeur GNOME, j'ai vu un cas qui fonctionnait.
Fichier en UTF8, coding cookie en entête, et c'est magique, ça marche. Quelle est la différence entre mon exemple et les siens ? Le coding cookie ? Non, en l'enlevant, on obtient le même résultat, c'était sans doute nécessaire en 2003-2004 pour aider gcc à trouver l'encodage du fichier, mais apparemment plus maintenant.

Non en fait, la différence c'est qu'il appelle gtk_init dans son exemple. Mais pourquoi diable doit-on se lier à GTK pour une appli non graphique, juste pour avoir des traces en français (besoin de mon employeur) ? Si quelqu'un a une réponse, ou un autre moyen, je suis preneur...

Update 2:

Effectivement, comme l'indique Pascal dans les commentaires, il semble que ce soit un appel à setlocale qui soit a cause de mes soucis. Comme l'indique la documentation de gtk_set_locale, gtk_init appelle gtk_set_locale qui appelle setlocale(LC_ALL, "").
C'est cette dernière fonction qui va vérifier la locale utilisée, et ainsi affecter toutes les fonctions d'affichage.

La version corrigée de mon programme de test est donc:
#include <glib.h>
#include <locale.h>
int main (void)
{
setlocale(LC_ALL, "");
g_print("éèân");
return 0;
}