Monthly Archives: mars 2011

Console série sur liseuse Samsung E60

Les bons plans Samsung de janvier avait déjà fait le tour du web, et je n’en reparlerais pas (sauf pour dire que j’en ai profiter pour acquérir une liseuse Samsung E60).

Une communauté s’est formée autour d’un forum (e60 sur hardware.fr) et d’un espace google code (e60-open).

On y trouve pas mal d’infos et en particulier la console série. De mon coté je dispose d’un adaptateur USB vers série en LVTTL 3.3V (à base de FTDI FT2232C) donc j’ai opté pour la connexion sur R232 et R233. Or RDX (R232) est déjà connecté au circuit MAX232 qui converti les niveau LVTTL vers les niveaux série, et apparemment ce petit gars était plus fort que mon FTDI… J’ai donc retiré R232 et connecté mon FTDI à la palace. Restait à savoir quel pad de R232 allait vers le CPU… Coup de pot, le premier que j’ai essayé était le bon: le coté le plus proche de la batterie.

Une petite photo de mes belles soudures :
mes belles soudures

Et voila, j’ai ensuite suivi la procédure pour tester un kernel en chargeant le kernel fourni sur le SVN du projet. Et ça à marché (à ceci prêt que j’ai dû déchargé le module secbulk, donc soit j’ai pas compris, soit il ne sert pas).

Prochain épisode, compilation et test d’un noyau Linux.

Test comparatif de microSD

Bon pour commencer, je n’ai pas demandé aux fabricants de m’offrir des cartes pour les tester, donc ce test est loin d’être exhaustif. En fait je ne compare que deux cartes !
Voila mon frère et moi avons acheté quelques cartes microSD SDHC 16G : une de marque SanDisk et une de marque Kingstone. Nous avons choisi des marques pour être à peu près sûrs d’avoir des performances correctes.

Méthode de test

J’ai cherché à définir un protocole de test, copier des fichiers de différentes tailles… puis je suis tombé sur ce blog: MicroSD class 6 Performance Benchmarks. Il propose d’utiliser un outil présent dans le bureau GNOME: palimpsest.
Bon alors cet outil ne veut pas tester la carte si il y détecte une table des partitions, le blog cité précédemment propose d’effacer toute la flash avec la commande suivante:

dd if=/dev/zero of=/dev/sdb

Brutaliser de la sorte une carte SD n’est peut être pas ce qu’il y a de mieux à faire. Surtout quand l’on sait que l’état « effacé » d’une flash est avec tous ses bits à 1, écrire 0 partout revient en fait à la remplir plus qu’à l’effacer…
Mais bon j’y ai pas trop réfléchit quand j’ai fait le test, donc je suis parti la dessus:

sync; date; sudo time dd if=/dev/zero of=/dev/sdb; sync; date

Les appels à date permettent d’avoir une première estimation du temps d’écriture, en fait, dd donne aussi quelques statistiques donc c’était pas nécessaire.

Puis le test proprement dit:

LANG=C palimpsest

Attention au port USB utilisé pour le lecteur SDHC, si les traces du noyau (dmesg) contiennent la ligne suivante, il faut trouver un autre port !

not running at top speed; connect to a high speed hub

Bon, assez de blabla…

Les résultats

Kingston microSD 16G SDHC Classe 4

Résultats de dd: 15997075456 octets (16 GB) copiés en 6491,87 s (1h48) soit 2,5 MB/s.

Performance en lecture (courbe bleue):

  • Débit de lecture minimal: 18,6 MB/s
  • Débit de lecture maximal: 20,9 MB/s
  • Débit de lecture moyen: 18,9 MB/s

Performance en écriture (courbe rouge):

  • Débit d’écriture minimal: 1,7 MB/s
  • Débit d’écriture maximal: 4,7 MB/s
  • Débit d’écriture moyen: 2,4 MB/s

Temps d’accès moyen: 2,2ms (courbe verte)

kingstone microSD 16G - graphique de performance

SanDisk microSD 16G SDHC Classe 4

Résultats de dd: 15931539456 octets (16 GB) copiés en 4934,48 s (1h22) soit 3,2 MB/s

Performance en lecture (courbe bleue):

  • Débit de lecture minimal: 20,6 MB/s
  • Débit de lecture maximal: 21,1 MB/s
  • Débit de lecture moyen: 21,0 MB/s

Performance en écriture (courbe rouge):

  • Débit d’écriture minimal: 1,3 MB/s
  • Débit d’écriture maximal: 5,7 MB/s
  • Débit d’écriture moyen: 2,4 MB/s

Temps d’accès moyen: 1,6ms (courbe verte)

SanDisk microSD 16G - graphique de performance

Conclusion

Ces deux cartes se valent à peu prés, avec un léger avantage pour la carte SanDisk.

Premiers pas en développement noyau

Je voulais me mettre au développement noyau, mais je ne savais pas par où commencer, alors un sage m’a dit: « pour apprendre rien de tel que de le faire: vous achetez un petit périphérique USB et vous en écrivez le driver. »
Ma réponse a été: « effectivement, je n’y avais pas pensé, en général on utilise la libusb pour ce genre de choses. »

Un périphérique USB

Et voila que quelques jours après, sans avoir trouvé de périphérique sympa je me suis dit, mais pourquoi pas le faire aussi ?
Comme je vous l’ai déjà raconté, j’ai déjà bricolé un périphérique USB: l’USBtinyISP, donc je suis allé rechercher le code original de usbtiny et je me suis monté un petit prototype avec 4 LED et 2 boutons:

Photo de mon prototype

Bon plutôt que d’utiliser un ATtiny, j’ai pris un ATmega8 histoire d’avoir un peu de place pour y ajouter du code plus tard ;-) (l’ATtiny2313 est déjà super plein pour l’USBtinyISP).

Et voila le schéma (en image, les sources gschem sont sous git dans le répertoire sch):

Le schéma

Une fois le montage prêt, quelques lignes de code basées sur l’exemple de tinyusb et hop un firmware pour l’ATmega (à la racine du projet).

Qu’il a fallut tester, hop la première méthode évoquée plus haut, quelques lignes de code avec libusb, disponible dans le répertoire test, m’ont permis de parfaire le firmware ;-)

Voila, tout marche, on va pouvoir entrer dans le vif du sujet.

Le gestionnaire de périphérique Linux

En fait j’ai tout simplement suivi et adapté les tutoriels suivants:

En regardant la version de usbled.c présente dans les sources de Linux afin de mettre à jour les derniers détails.

Cela donne un driver qui ajoute les pseudo-fichiers leds et keys dans le répertoire du périphérique déjà créé dans /sys/bus/usb/ par le noyau Linux.

Voila ! Vous je sais pas mais moi j’ai appris plein de choses ! ;-)

Tout le code est disponible sous GPL2 et GPL2+ sur mon gitweb: jvdg_usbgadget.git

Pour le nom un peu égocentrique, c’était surtout pour éviter tout risque de conflit, comme de toutes façons ceci n’a pas vocation à être intégré dans Linux (le périphérique utilise un ID USB réservé aux prototypes, donc inutilisable en grande série…)