Découverte de l’Epaper (papier électronique) et connexion au réseau [version française]

Attention !

Ce projet (schéma électrique, programmes, ce document) est distribué sous licence GPL (version 3 et suivantes) et sans garantie aucune. Rien n’a été endommagé lors de sa création mais vous devriez être prudent et tout vérifier par vous-même. Nous ne sommes pas responsables de ce qu’il pourrait se produire...

Maintenant que l’avertissement légal est fait, allons-y !

Après mon dernière article publié l’été 2007 à propos des capteurs en salle serveur (Centrale interactive de capteurs), je suis de retour en juillet 2008 avec un nouveau projet pour le centre Erasme. Cette fois la chance m’a été donnée de travailler sur un écran de type papier électronique vendu par la société Nemoptic.

Cette technologie récente est très intéressante, le principal avantage est que l’affichage est bistable, c’est à dire qu’il ne s’effacera pas mais si l’alimentation électrique est coupée. Cela permet des utilisations "à emporter" (emmener son écran avec soi comme une feuille de papier) ou plus intéressant : en électronique embarquée sur batterie car cette technologie consomme peu d’énergie.

Ce produit est appelé Binem et la version choisie est au format HVGA (480x320 pixels, noir et blanc). Il s’agit d’un kit de développement avec une carte de prototypage basée sur un microprocesseur ARM. Les images sont stockées durant la procédure de compilation. On peut enregistrer 85 images au format HVGA dans la mémoire propre du Binem.

En quelques mots, mon travail a été de remplacer cette carte par une autre disposant uniquement des fonctionnalités désirées : être capable d’envoyer une image sur l’écran sans procédure compliquée comme la compilation... Cette carte est appelé dans le texte suivant : "carrier board" (nom anglais gardé par souci de simplicité). Au début nous avions imaginé une connexion entre elle et l’ordinateur via USB ; le schéma électrique, la carte en elle-même, le programme sur l’AVR et celui sur le PC ont été créés avec cette idée en tête. Cela fonctionnait bien !

Voici à quoi la carte ressemble :

Une version haute résolution est disponible dans l’archive zip. De même pour le circuit électrique correspondant.

Donc nous avons décidé de franchir une étape supplémentaire : l’ethernet. Nous avons acheté l’AVRWebServer de chez TuxGraphic (appelé "serveur" dans le texte suivant) qui est utile pour connecter notre carte au réseau ethernet. Le logiciel a été écrit par Guido Socher et est ouvert : je l’ai modifié (suppression des modules TCP non utiles dans notre cas et ajout du support de la connexion série via le module UART de l’AVR) et alors le serveur a été capable de recevoir des commandes via des trames UDP et de les transmettre à nouveau vers la carrier board par la connexion série (connexion qui fût initialement prévue sur la carrier board pour débugguer...)

Comment transférer une image du PC vers l’écran ?

Pour envoyer une nouvelle image à l’écran, on doit choisir un numéro d’image (entre 1 et 85 inclus) pour calculer le numéro de page mémoire (1 image = 3 pages mémoire, vous faîtes le calcul...). Tout d’abord le PC demande au serveur s’il est déjà occupé avec un autre client ou pas (déjà en train de transférer une image par exemple). S’il n’est pas occupé, il lui dit que nous souhaitons transférer une nouvelle image à la page numéro N. Puis il envoie chaque morceau de l’image. Pour finir, l’ordinateur envoie un code signifiant que le transfert est terminé.

Toutes les commandes reçues par le serveur sont transmises à la carrier board via la ligne série. Cette carte reçoit les commandes et les traduit en quelque chose de compréhensible par l’écran (couche d’abstraction matérielle : "hardware abstraction layer").

Protocole utilisé au dessus de l’UDP

Un protocole très simple a été créé. Les données sont
[Code Commande (1 octet)][Paramètre, dépend de la commande]

Faits généraux : on doit avoir au moins 2 octets de données, donc quand nous utilisons un Code Commande qui n’a pas besoin de Paramètre : nous ajoutons au moins 1 octet de bourrage ("garbage" en anglais, données sans importance) qui sera ignoré...

La taille des données en UDP est limitée, donc nous devons découper l’image en parties. Par exemple, une image HVGA pèse 19 200 octets de données, découpés en 80 morceaux de 240 octets car 240 est inférieur à 255 qui est le maximum admis (sans compter le premier octet de Code Commande).

• Code commande = 1 : dire à l’écran que l’ordinateur est prêt à transférer une nouvelle image (Paramètre : numéro de page mémoire du binem à partir de laquelle l’image sera stockée)

• Code commande = 2 : envoyer un nouveau morceau d’image (Paramètre : numéro de morceau (1 octet) suivi par les données du morceau)
• si le serveur a bien reçu l’image, il renvoie un Code Commande 6 avec le Paramètre "y"

• Code commande = 3 : dire à l’écran que le transfert de l’image est terminé (aucun Paramètre)

• Code commande = 4 : afficher une image (Paramètre : numéro de page mémoire du binem où le début de l’image est stocké)

• Code commande = 5 : effacer l’écran (aucun Paramètre)

• Code commande = 6 : demander au serveur s’il est prêt ou pas (aucun paramètre)
• le serveur renvoie un Code Commande 6 avec pour Paramètre "y" s’il est prêt, et "n" sinon

Protocole sur ligne série

Quand nous avons créé la carrier board, les trois "pins" (Tx, Rx, Gnd) pour la connexion série de l’AtMega ont été câblés pour les utiliser à des fins de déboguage. Je ne les ai pas utilisé, mais quand nous avons décidé d’ajouter la carte serveur il a été facile de les utiliser pour relier les deux cartes !

Il s’agit d’une connexion série classique à une vitesse de 38 400 bauds (le serveur n’a pas une horloge très précise, les vitesses plus élevées sont inutilisables).

Toutes les commandes envoyées au serveur sont transmises à la carrier board de cette manière sans aucun changement, à part la suppression des données de bourrage ("garbage") et la non-transmission du Code Commande 6.

Protocole pour communiquer avec l’écran

Nous utilisons un connecteur ZIF 30 fils. Le protocole est expliqué dans la documentation officielle Nemoptic. Il y a quelques fils de contrôle, et davantage pour les données. Pour une description plus détaillée, veuillez vous référer à la documentation BVGP fournie avec le kit.

Vous pourrez comprendre une partie du protocole, juste en examinant le schéma électrique et le programme de la carrier board....

Format de l’image

Ecran HVGA noir et blanc donc images en noir et blanc mode 1 bit par pixel. 480x320 pixels. Format BMP. Si toutes ces conditions sont respectées, la taille du fichier image doit être de 19 262 octets (entêtes BMP incluses).

Contenu de l’archive ZIP

Main archive

COPYING : copie de la licence GPL version 3 (anglais)

avrserver/* : programme à utiliser dans le serveur, version modifiée du code écrit par Guido Socher

binemAVR-serial/* : programme à utiliser dans la carrier board

binem-ether/* : programme à utiiliser sur le PC écrit en C (ligne de commande)

binem-qt/* : programme (équivalent du précédent plus possibilité de convertir les images) à utiliser sur le PC écrit en Python avec une interface Qt

eagle/* : schéma électrique et typon de la carrier board, à ouvrir avec le logiciel Eagle

Les codes source sont commentés, veuillez vous y référer.

A propos de moi

Clément Notin, agé de 18 ans, vivant en France près de Lyon. Etudiant ingénieur à l’INSA Lyon.

Mail : clement@notin.org

Gallerie