Nabaztag

J'ai reçu à Noël dernier une jolie petite bestiole. Un bon gadget de geek Le Nabaztag.

Très bonne idée à la base, le concept est intéressant, c'est typiquement le genre de truc qui m'intéresse. Sauf ... que ce Nabaztag est finalement un peu trop inutile à mon goût et surtout bien trop contrôlé par la société qui le vend, à savoir la société Violet. Déjà, qu'est-ce que cette petite bestiole ? Il s'agit en fait d'un terminal connecté à Internet en wifi par lui même et qui peut interagir à la fois avec du contenu sur Internet et avec l'utilisateur. Il est alors possible de lire la météo, suivre ses emails, écouter la radio, écouter des podcast, lire des flux en streaming, suivre des flux RSS, etc. Notre ami lapin clignote de partout et bouge les oreilles dans tous les sens et peut même lire des puces RFID. Bref une bonne idée dans l'absolu, mais finalement ce lapin m'a plus énervé que servi pour l'instant. J'écoute beaucoup de webradio sur Internet, on peut charger des radios sans problème ... sauf que notre ami lapin lit comme un abruti les trames METADATA (titres des musiques entre autres) des flux http des radios. Du coup on a droit à des gros parasites aléatoires dans la musique, parce que le lapin essaye de faire lire du texte au lieu du flux mp3... ahah bien joué !

Second truc qui m'embête pas mal. Le lapin se connecte par Internet au serveur de Violet. Le système embarqué au sein du lapin n'est pas super puissant, donc tout le traitement a lieu, semblerait-il, de manière déportée, le lapin ne reçoit que des commandes.En gros si la société fait faillite ou arrête le développement du lapin ... le lapin devient hors d'usage. J'ai quand même du mal à me savoir dépendant d'une société pour utiliser un objet comme celui-ci. En dehors du fait que le lapin n'est pas super fiable, dépend du serveur de violet pour fonctionner comme réveil ou lire ses mails etc, le gadget reste intéressant, mais hélas ça reste un gadget. Je n'ai pas réussi à l'intégrer dans ma vie de tous le jours. Dommage.

En dehors des services de base proposés par Violet pour le nabaztag, la société a créé une API pour permettre aux propriétaires de Nabaztag de le commander eux mêmes, c'est à dire faire bouger les oreilles, lancer des flux mp3 à la demande, lancer le synthétiseur de parole, etc. Mais, même problème ce ne sont que de simples requêtes HTTP qui ne permettent pas d'aller bien loin. Et puis accessoirement, le lapin est carrément manipulable depuis n'importe quel coin de la planète, du moment qu'une personne a l'identifiant de votre lapin (sorte d'adresse MAC). Vous avez vite fait de tomber par hasard sur l'adresse d'un lapin existant.

Bref, après moins de 2 semaines de tentatives d'utilisation je n'ai pas résisté à la tentation de démonter cette petite bestiole. Il s'avère qu'elle cache du matériel plutôt sympathique, et j'ai découvert avec joie qu'elle disposait d'un port JTAG, permettant de programmer le processeur directement.

Nabaztag Démonté

Carte embarquée du Nabaztag

J'ai pu donc diséquer le lapin et découvrir ce qu'il se trouvait à l'intérieur:

• 2 moteurs continus pour faire bouger les oreilles
• Un lecteur de puce RFID
• Un micro
• Une prise jack reliée à la carte son
• Un potentiomètre pour régler le volume
• Une carte wifi
• Un haut parleur
• Des DELs associées et leurs cônes de direction pour avoir de jolies petits ronds lumineux sur la coque par transparence

MCBSTM32 - Carte de développement pour processeur ARM

Je ne vais pas détailler minutieusement tous les composants de la carte principale. Quelqu'un s'en est déjà chargé sur ce blog. Je peux lire sur le processeur "OKI L670405I - INNN, ARM 722EBAUJ". Il semblerait qu'il s'agisse d'un processeur ARM7 TDMI, ce processeur pourrait d'après mes recherches (je n'en suis pas sûr) être programmé par une carte de développement qui vaut 229$. Ahah la bonne blague ! Il doit peut être y avoir moyen de trouver un moyen moins cher, mais je ne le connais pas encore.

Du coup j'essaye de découvrir comment reprogrammer le processeur pour y mettre un Firmware maison et libre de surcroit. En gros dans l'idée de permettre aux gens d'utiliser leur nabaztag sur des serveurs qui ne sont pas ceux de Violet. (Free your rabits !!!) Cela impliquerait un certain travail, analyse minutieuse des specifications matérielles, reprogrammation des drivers, reprogrammation des protocoles de communication, reprogrammation d'un serveur etc. Mais c'est le genre de projet qui m'intéresserait vraiment : refaire de A à Z le firmware à des fins pédagogiques. J'essaye de contacter des gens sur Internet qui semblent intéressés par la libération des lapins, pour l'instant pas de réponse positive. Mais je cherche toujours ! Pour l'instant je ne sais pas trop par où commencer avec le peu de connaissances et de matériel que j'ai à ma disposition. Mais si par hasard, vous êtes intéressé par une telle entreprise n'hésitez pas à me contacter.

Je réalise mon rêve d'enfance en ce moment, la réalisation d'un robot de A à Z. Je regrette de finir mes études à l'UTT dans 2 mois, ça commence à devenir vraiment passionnant ! Donc en fait je travaille sur un robot wifi commandé par manette de wii. J'ai réussi à caser ça comme projet dans mon cursus, au lieu de faire un cours bouche trou pour finir ma 5eme année, bah je me suis lancé avec un autre étudiant dans le développement d'un chti robot Il ne s'agit pour l'instant que de notre premier prototype, comme vous pouvez le voir il n'est pas entièrement autonome. On doit encore travailler sur l'alimentation du système embarqué (Carte Fox), du routeur wifi et des servomoteurs. Pour l'instant on a des gros fils rattachés au robot. On cherche des batteries adaptées pour alimenter tout ça. C'est que ça pompe du courant ce ptit machin.

Il reste encore du boulot, le robot a la fâcheuse tendance à se mettre en mode autiste et à faire n'importe quoi. On a écarté un problème lié au wifi, donc ça doit venir du code qui marche paaaas bien Reste ensuite à faire marcher la pince, qui n'a pas encore été implémentée dans le code. Ensuite on pourra utiliser OpenCV pour faire un peu de traitement d'image et donner la possibilité au robot de repérer un certain nombre de choses.

Je suis en train de me préparer un blog perso exprès pour présenter l'avancement de mes projets de robotique, et de programmation en générale. Je posterai de temps en temps sur Coder-Studio mon avancement du projet et donnerai à l'occasion l'adresse pour compléter mes billets sur mes robots. Sinon, désolé pour la vidéo, elle est assez courte et on ne voit pas trop la manette de wii. En fait je n'avais plus de place sur ma carte mémoire...

Voilà donc c'est un premier aperçu très rapide du projet. Je ferai une vidéo plus complète au prochain épisode avec un billet contenant plus de détails sur le robot

J’ai quitté l’équipe de Simerion, après 5 ans de conception et développement, il y a un peu plus d’un mois pour différentes raisons que j’aborderai plus loin. Mais je profite de ce billet pour faire une sorte de bilan du projet, de mon point de vue. L’idée étant de faire un retour d’expérience afin de pointer du doigt ce que nous avons pu apprendre mais aussi afin de mettre en évidence les erreurs que nous avons commises. Le tout dans l’espoir de pouvoir aider des personnes s’engageant dans un projet similaire.
Tout d’abord, je précise que le jeu n’est pas arrêté. Il est toujours en développement, je n’ai fait que quitter l’équipe. Donc si mon article vous donne envie d’en savoir plus ou de rejoindre l’équipe de développement, n’hésitez pas à vous rendre sur www.simerion.fr

Tout d’abord, un rapide historique :

2005 : Wett et moi-même avons ressorti du fond d’un tiroir les bases d’un projet que j’avais esquissé 2 ans plus tôt. Durant 5 mois nous mettons ainsi à plat toutes nos idées sur un forum et wiki. Mais très rapidement nos études respectives (classes prépa) nous ont poussées à mettre en pause le projet.
Juillet 2006 : Un an plus tard nous reprenons notre projet en main et continuons à travailler sur la conception durant un mois de manière soutenue.
Août 2006 : Nous commençons enfin le développement et devenons membre de l’association Nainwak qui nous hébergera par la suite.
Août 2007 : Un an plus tard, avec l’aide d’Altheran qui nous a rejoint en mars, nous sortons notre première version alpha avec une cinquantaine de joueurs.
Mars 2009 : Plus d’un an et demi plus tard, la beta alors que je quitte l’équipe.

Voici donc une suite de points, qui maintenant avec le recul me semblent importants à souligner.

Travailler en équipe

A travers ce projet j’ai pu découvrir la nécessité de travailler à plusieurs. Et cela pour plusieurs raisons. Tout d’abord afin de s’entre-motiver lorsque certains d’entre nous sont démotivés. Voir d’autres personnes travailler sur le projet peut très facilement nous remonter à bloc. Le développement d’un jeu web comme Simerion ne doit pas se faire en comité réduit. Attention l’effet inverse n’est pas pour autant une bonne idée. S’entourer de trop de monde peut être néfaste pour le projet. Il faut prendre le juste nombre de programmeurs, en prenant en compte leurs disponibilités et leurs compétences.

Bien choisir son langage

Notre choix s’est porté initialement sur le PHP couplé à de l’Ajax afin de bénéficier d’un jeu accessible partout depuis Internet avec une grande interaction avec les joueurs. Pourquoi le PHP ? Parce que ce langage m’était déjà familier et était simple à prendre en main. Cependant avec le recul, nous n’aurions sans doute pas dû employer celui-ci préférant sans doute le JAVA ou le C++ afin de réaliser un véritable MMORPG. A maintes reprises nous nous sommes mordus les doigts quant à notre choix de technologie. Nous avons très rapidement atteint les limites du PHP et de l’Ajax. Nous avons été bridés par nos choix initiaux qui nous ne ont pas permis pleinement de faire ce que nous souhaitions réaliser. Mais il était trop tard pour changer.
Je conseille vraiment au départ de faire le tour de toutes les technologies lorsque l’on s’aventure dans un projet web d’ampleur. Chaque langage possède ses avantages et inconvénients qu’il faut comparer. Nous ne l’avons pas fait, et cela nous a desservis.

Ne pas réinventer la roue

Une autre erreur que nous avons commise a été de ne pas faire le tour des Frameworks PHP et Ajax existants. En jeunes fous que nous étions, nous avons créé notre propre moteur de jeu de A à Z et notre propre Framework Ajax. Nous avons réinventé la roue et avons perdu un temps fou. D’un autre côté, nous ne savions pas forcément que des outils tout fait existaient, cela nous a toutefois permis de comprendre le fonctionnement d’un certain nombre de techniques et technologies. Mais si c’était à refaire j’utiliserais au maximum des outils déjà disponibles.
Avant de commencer un projet conséquent. Je pense qu’il faut vraiment regarder, comparer les outils à sa disposition et ne pas fonce dans le tas tête baissée. Utiliser des outils déjà faits peut faire réellement gagner un temps précieux.

Utiliser des schémas et diagrammes UML

L’utilisation de diagrammes UML est assez primordiale. Il est difficile d’être rigoureux sur la durée afin de mettre sur papier les idées avant de coder. Mais c’est un mal pour un bien au final, car c’est un gain de temps non négligeable. Toutefois les diagrammes UML ne sont utiles que si l’on ne change pas d’idée en permanence. Auquel cas, les diagrammes sont en permanence remis en cause, ce qui est pour ce coup-ci une grosse perte de temps.

Eviter l’approche du « tout objet »

L’approche objet d’un jeu web est assez complexe. A première vue, le « tout objets » peut sembler être une bonne chose, mais les objets ne sont pas les amis des bases de données. Qui dit objets, dit attributs, et qui dit attributs dit base de données derrière chargée et mise à jour en permanence. Travailler avec les objets et leurs instances implique d’optimiser en permanence le code afin que le serveur ne s’écroule pas sous les requêtes SQL. Par exemple, si je veux charger une instance d’appartement d’un joueur dans Simerion, nous devons charger un objet qui va définir son type (classe), puis un objet qui va définir son instance de conteneur (bâtiment) ainsi que la classe de celui-ci. Vu que nous avons besoin parfois de localiser cet appartement, nous avons besoin de charger la région dans laquelle se trouve notre bâtiment (une table supplémentaire). Comme il y a plusieurs planètes il faut également charger sur quelle planète se trouve cette région (une table de plus). Au final la création d’un objet devient pharamineuse en terme de ressources, nécessitant une flopée de requêtes SQL. Imaginez comment charger des collections entières d’appartements... De quoi mettre à terre le serveur. Nous sommes alors obligés d’optimiser en nous éloignant peu à peu du système classique d’objets. Travailler en objet est intéressant, mais dès que l’on se met à travailler sur des pages qui vont recevoir énormément de visites, l’intérêt en prend un sérieux coup.
Je pense qu’il n’y a pas de solution absolue et qu’il faut privilégier les objets pour la maintenabilité du code. Par contre, en ce qui concerne le lien avec les BDD, il faut trouver un compromis et essayer de s’éloigner du schéma classique qui consiste à tout charger lors de la création de l’objet. Je pense qu’il suffirait de regarder du côté des gros Frameworks ce qu’il se fait en la matière. La liaison avec la BDD est une chose assez pointilleuse et complexe, je pense que même au bout de 5 ans, le code n’est pas optimisé au maximum de ce côté-là. Par conséquent, aller voir les outils qui existent déjà peut être d’une très grande aide.

Ne pas remettre en question son code en permanence

Une des choses qui nous a fait le plus perdre de temps a été la permanente remise en question de notre code. C’est bien plus facile à dire qu’à faire, mais il faut à tout pris se contenter au plus tôt de son travail pour avancer de l’avant. De la même façon, il faut éviter d’optimiser à mort tout et tout de suite, il faut le faire au fur et à mesure en trouvant un juste milieu. J’aborderai plus loin la question du travail étape par étape, mais il est très très important, d’après l’expérience que j’ai tirée de Simerion, de se contenter de ce qui fonctionne et aller de l’avant pour avoir du concret et non pas du code en permanence remanié. Une fois que le code fonctionne il est alors possible de l’optimiser, mais il faut viser à mon sens le fonctionnel avant de foncer tête baissée sur la sécurité et l’optimisation du jeu.

Bien choisir son cycle de développement

Le choix de notre cycle de développement n’a définitivement pas été le bon. Et ce dernier est à mon sens la raison de notre (mon) échec. 5 ans ! Nous avons passé 5 ans sur ce projet et toujours pas de jeu jouable en version publique à mon départ … C’est entre autres une des raisons de mon arrêt. C’est même un exploit d’avoir tenu aussi longtemps. Nous avons choisi en effet de n’ouvrir le jeu que lorsqu’une version du jeu serait suffisamment jouable pour retenir le joueur. Or, le principe de Simerion est de pouvoir tout faire. Tout est interdépendant, et tout s’équilibre. Il est alors impossible de sortir une version jouable tant que TOUT le jeu n’a pas été programmé. Quelle erreur nous avons faite ici !
Dès que le concept est posé sur papier un jeu amateur doit, selon moi, sortir au plus vite en production. A la fois pour avoir des retours des joueurs, mais aussi afin de se motiver dans son travail de développement. C’est extrêmement déprimant de ne pas avoir de retour de joueurs avant des mois, voir des années dans notre cas. La motivation est naturellement en constante baisse, et pas un joueur pour vous rebooster. Il ne faut compter que sur les membres de l’équipe qui eux aussi sont en manque de motivation.
Donc vraiment je conseille vivement de développer les jeux web sur des versions fréquentés par les joueurs (tout du moins pour les jeux amateurs). Il faut sortir régulièrement les versions de développement et surtout ne pas attendre aussi longtemps que nous entre chaque version. En faisant cela on entretient la communauté de joueurs qui nous supporte et nous est très utile, et on entretient notre motivation dans le projet. Sans cela, tout s’effondre au bout de X mois ou années. Et tout l’investissement aura été vain.

Créer une communauté autour de son jeu

Comme je le disais précédemment, il est nécessaire de s’entourer dès le début d’une communauté de joueurs. Ces derniers pourront tester votre jeu, donner leur avis, proposer leurs idées d’améliorations etc. N’ayant pas lancé de version jouable durable de Simerion, nous n’avons pas eu de communauté derrière nous pour nous soutenir dans notre développement. Et c’est une conséquence très négative, qui va avec notre mauvais choix de cycle de développement.
Je conseille donc vraiment de travailler dès le début à la création d’une communauté entourant le projet à la fois pour y puiser de la motivation, mais aussi afin de se faire aider. Car bien souvent, la communauté gravitant autour de votre jeu est source de nouveaux membres pour votre équipe de développement.

Les amateurs ne peuvent pas rivaliser avec les pros

Cela fait mal à dire, mais la création d’un jeu RPG complexe n’est pas à la portée d’une équipe d’amateurs. Qu’on me montre le contraire et j’en serais ravis ! Mais le fait est que la création d’images, de décors, d’histoires, de scénarios, de quêtes et de missions nécessite un travail pharaonique. J’ai les 95% du temps endossé le rôle du développeur, du scénariste et de l’illustrateur à la fois. Ceci est quasiment impossible à gérer dans un tel projet. Idéalement il faudrait avoir dans son équipe au moins un graphiste / illustrateur et plusieurs scénaristes pour remplir le jeu. Mais il s’agit d’atouts rares, et il faut bien souvent ne compter que sur soi même. Sur cet aspect je suis assez pessimiste hélas, je pense qu’un jeu de l’envergure de type Fallout, Baldur’s gate, Final Fantasy, ou même Zelda n’auraient pas pu être réalisés par des amateurs. Cela demande trop de travail en dehors de la partie programmation. Le jeu ultime est à mon sens impossible à développer par des amateurs, hélas… A mon sens, un jeu amateur ne doit pas voir trop gros dès le départ. Il faut y aller au fur et à mesure, en se faisant plaisir et tout en gardant à l’esprit que nous ne pouvons pas rivaliser avec les grands. Le jeu ultime amateur n’est pas réalisable, cela demande beaucoup trop de travail. Avec Simerion nous sommes partis sur un concept trop complexe, trop utopique … La clé de la réussite est un cadrage dès le départ qui trouve un compromis entre un concept novateur et le minium de code possible.

Tenir un cahier des charges et une documentation à jour

Un point important dans le cycle de développement réside dans la tenue d’un cahier des charges et d’une documentation à jour. En effet, il n’est pas rare de mettre en pause le projet pendant X mois. Et reprendre le code après une période d’inactivité est vraiment très difficile (même pour du code tapé soi même). Le cahier des charges permet de garder une vue globale sur le projet avec un certain recul, il vous permet de poser au clair toutes les idées et mieux structurer ses idées. La documentation permet, elle de son côté d’expliquer le fonctionnement du jeu (aspect technique) mais aussi d’expliquer pourquoi tel ou tel choix d’algorithme. La documentation peut vous faire gagner un temps fou pour vous remettre dans votre code, ou pour comprendre le code d’un autre programmeur. Ces deux outils permettent également l’intégration de nouveaux membres à l’équipe de développement (chose à laquelle on ne pense pas forcément). Le fait est que Simerion est devenu une véritable usine à gaz et que plusieurs personnes se sont cassées les dents à essayer de comprendre notre code pas toujours commenté ni expliqué. Le manque d’explication peut alors être un frein au recrutement de nouveaux développeurs.

Se faire soutenir

Nous avons rejoint dès le départ l’association Nainwak, qui nous a hébergés, soutenus et conseillés. Nous n’aurions sans doute pas tenu autant de temps sans elle. Nous avons même eu la chance grâce à elle d’être exposant à 2 reprises au festival du jeu vidéo. Nous avons pu rencontrer des professionnels qui ont été intéressés par notre jeu. Cela fut une expérience très enrichissante.
Je conseille vivement à toute personne se lançant dans un jeu web sérieux de contacter Nainwak. La mission de cette association est d’aider les amateurs, et elle y travaille à merveille.

Bilan

J’ai complètement arrêté Simerion tout d’abord parce que je ne prenais plus aucun plaisir à travailler dessus. Le développement était devenu interminable et j’avais besoin de passer à autre chose. A cela se sont ajoutés des problèmes de santés plus une saturation du web en général. Abandonner Simerion alors que ce projet me tenait tellement à cœur a été une chose très difficile, mais je pense qu’au bout de 5 ans, il fallait simplement passer à autre chose.
Simerion a été une expérience vraiment très enrichissante. J’ai pu apprendre énormément et rencontrer beaucoup de monde. Mais je pense que si nous nous étions pris autrement dès le départ nous aurions sans doute bien mieux réussi, et je serais encore sur le projet. Mais tout cela fait partie de l’apprentissage. C’est chuter pour mieux se relever et mieux démarrer mes prochains projets.
Toutefois, nous nous sommes lancés dans un concept dément, où tout devait être possible. Le jeu ultime en quelques sortes. Un tel jeu n’est tout bonnement pas réalisable et complètement utopique (A moins d’être un studio de jeu vidéo avec de la monnaie sonnante et trébuchante pour assurer le coup). Mauvais choix de départ, concept trop ambitieux, mauvaise démarche de développement, réinvention de la roue ont été autant d’erreurs qui ont amenés Simerion à ne pas arriver au point escompté. On apprend de ses erreurs et j’espère que les nôtres pourront vous êtes bénéfiques également.

Carte Fox

J'ai été amené à travailler dans le cadre de mes études sur un petit projet de développement d'une Interface GSM sur un système Linux embarqué. Ayant découvert la puissance du système, j'ai pensé vous faire part de mes découvertes sur l'utilisation de cette carte.

Dans mon cas le principe était de créer un système autonome d'envoi de SMS aux étudiants de mon école. L'idée étant de pouvoir envoyer les résultats des examens directement par SMS aux étudiants, ce qui est ma foi fort sympatique

Le Matériel

Alors, tout d'abord : Carte FOX Késako !? Il s'agit d'un système embarqué à bas coût utilisant le système d’exploitation Linux. La carte est dotée d’un processeur AXIS à 100MHz et de 32 MB de RAM, de connectiques USB, Ethernet, d’un port série console ainsi que 40 pins pouvant être reliées à plusieurs BUS de données. Elle permet de développer en bon nombre de langages : C, C++, PHP, PYTHON, Shell, … et permet des connections HTTP, FTP, SSH et TELNET. De petite taille et faible consommation électrique (1 W) est idéale pour mettre en place rapidement des projets de type embarqué.

Modem GSM

Le modem GSM utilisé ici est un modem de la marque Telit. Il est relié à la carte FOX par l’intermédiaire d’une carte d’extension. La carte FOX peut communiquer avec le modem par l’intermédiaire du port série /dev/ttyS2. Une simple utilisation de carte SIM classique permet de se connecter au réseau GSM. Il est possible de trouver cette carte seule sur le site d'ACME SYSTEMS à 176 € frais de port tout compris. Si l'on ajoute le kit GPRS cela monte jusqu'à 626 €, ce qui commence déjà à faire beaucoup. Je pense qu'une solution plus abordable serait de relier la carte basique à un téléphone portable pour communiquer en série étant donné que dans notre cas nous n'avons pas besoin de tous les éléments de la carte d'extension.

Les modems GSM utilisent un protocole de commandes appelées "commandes AT". Chaque constructeur fait un peu ce qu'il veut avec ses normes, ce qui fait que chaque modem est plus ou moins différent et qu'il faut se référer à la doc du constructeur. Ces commandes AT sont donc envoyées via le port série pour soumettre différentes commandes au modem. On peut notamment dans notre cas manipuler et envoyer des SMS par l’intermédiaire de celles-ci.

Environnement de développement

La compilation d’un programme en C sur la carte fox nécessite un compilateur croisé permettant de compiler le code C pour les processeurs AXIS. La compilation directe sur la carte n’étant pas possible, il faut par conséquent utiliser un SDK pour compiler le programme. J'ai travaillé avec le SDK Axis fourni pour la carte fox.

Avant toute chose il faut se rendre dans le dossier du SDK (~/devboard-R2_01 pour ma part) et y taper la commande suivante afin d’initialiser l’environnement de développement.

. init_env

Ensuite, il faut choisir le compilateur AXIS

make cris-axis-linux-gnu

On doit alors créer un Makefile pour notre programme. Voici celui que j'ai créé :

AXIS_USABLE_LIBS=UCLIBC GLIBC
include $(AXIS_TOP_DIR)/tools/build/Rules.axis
PROGS = sms
INSTDIR= $(prefix)/mnt/flash
INSTMODE= 0755
INSTOWNER= root
INSTGROUP= root
OBJS = main.o atcommand.o modem.o
all: $(PROGS)
$(PROGS): $(OBJS)
$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
scp sms root@fox01:/mnt/flash/tx
clean:
rm -f *.o
rm -f sms

Il n’y a alors plus qu’à faire un make pour compiler le programme et à l’envoyer sur la carte en FTP ou SCP. Ayant dû compiler à de très nombreuses reprises mon programme, j’ai rajouté l’envoi du fichier dans le makefile via la commande scp. Les fichiers utilisateurs sont déposés sur la carte Flash dans le répertoire /mnt/flash. Attention toutefois, car la mémoire flash EPROM est limitée en nombre d'écritures. Il vaut mieux tant que possible éviter d'écrire dans cette mémoire régulièrement. Privilégier la RAM (dossier /var par exemple) plutôt que sur la carte flash. Seul soucis, la carte se réinitialise à chaque redémarrage, par conséquent les tests peuvent être faits en RAM et une fois que l'application compilée est stable il est préférable de la déposer sur la carte flash afin de ne pas perdre le programme à chaque reboot.

La connexion à la carte fox se fait en telnet (ou ssh) simplement à l’aide de la commande suivante grâce à un simple telnet

telnet adresse_ip_de_la_fox

Développement du programme

Utilisation des commandes AT

Le modem se commande directement grâce aux commandes AT.  Ces commandes AT suivent une certaine syntaxe et nécessitent une mise en forme particulière pour leur envoi sur le modem. Ce dernier reconnaît plusieurs caractères de contrôle :

<CR> : Caractère de retour chariot : Sa valeur ASCII en décimal est fixée à 13 par défaut. (et peut être changée grâce au paramètre AT S3) Sa valeur hexadécimale quant à elle est 0x0D.

<LF> : Caractère d’interligne : Sa valeur ASCII en décimal est fixée à 10 par défaut

<CTRL+Z> : Combinaison des touches CTRL et Z. Sa valeur hexa est 0x1A

Ces caractères sont demandés et utilisés par le modem pour identifier les commandes AT. Chacune d’entre-elles utilise ces caractères de contrôle plus ou moins différemment. Voici un aperçu des différentes commandes que j’ai utilisées avec leurs caractères de contrôle.

ATE0<CR>
Cette commande permet de désactiver la commande écho (ATE1 la réactive). Cela demande donc au modem de ne pas répéter systématiquement les commandes qui lui sont envoyées.

AT+CMGF=1<CR>

Cette commande permet de régler le format de message pour l’envoi de SMS. Par défaut, le modem est en mode PDU (AT+CMGF=0). C'est-à-dire que l’envoi de message se fait en hexadécimal. AT+CMGF=1 permet de passer en mode texte, ce qui simplifie les manipulations de SMS.

AT+CMGS="06XXXXXXXX"<CR>

Cette commande permet de commencer la rédaction d’un SMS. On précise en argument le numéro de téléphone choisi. En retour on obtient le caractère d’invite de commande « > » qui nous invite à rentrer le texte du SMS.

Texte du SMS<CTRL+Z><CR>
Cette fin de commande permet alors de préciser le texte et de valider l’envoi du SMS par un CTRL+Z et un retour chariot.

Il est important de noter que l'envoi de la commande AT d'envoi de SMS se fait en 2 parties et pas en un coup. (j'ai testé pendant plusieurs semaines... ça ne marche pas ^^)

Le modem répond à ces commandes par des messages de retour. Ces derniers indiquent si celles-ci ont été exécutées avec succès ou non. La plupart de ces réponses sont entourées des caractères <CR><LF> Il y a toutefois des exceptions, notamment pour AT+CMGS qui renvoie +CMGS: <mr> ou +CMS ERROR: <err> Mais dans la plupart des cas les retours sont rapportés de la manière suivante :
<CR><LF>OK<CR><LF>
<CR><LF>ERROR<CR><LF>
<CR><LF>...<CR><LF>

Ces commandes AT doivent être transmises au modem par le port série /dev/ttyS2. Il existe plusieurs façons de communiquer sur le port série :

Termnetd (http://foxlx.acmesystems.it/?id=69)

Il s’agit d’un processus permettant de relier un port TCP/IP à un port série de manière transparente. Une fois que le deamon est lancé sur la carte fox, il est possible de se connecter depuis l’extérieur grâce à la commande telnet adress_ip_fox 7000. Le port 7000 (choisi dans la config de termnetd) redirige directement sur le port série et il est alors possible de rentrer manuellement des commandes AT et de voir leur comportement direct sur le modem. Ce programme est utile pour comprendre le fonctionnement des commandes AT.

Script Chat (http://linux.about.com/od/commands/l/blcmdl8_chat.htm)
Il est possible d’utiliser la commande UNIX chat permettant de dialoguer de manière automatisée avec le modem.

/usr/sbin/chat -V -s -f <fichier_script> > /dev/ttyS2 < /dev/ttyS2 2><fichier_resultat>

La réponse du modem est alors enregistrée dans le fichier de résultat choisi.

Programme en C
Il est également possible de dialoguer avec le modem via un programme C. Le dialogue se fait alors en écrivant et en lisant sur /dev/ttyS2. La prise en main est beaucoup plus complexe que les 2 précédentes méthodes, mais permet une totale maitrise du modem.

Développement en C

Le code pour envoyer un SMS n'est pas bien compliqué, mon but n'est pas là de copier/coller intégralement mon code, mais plutôt d'expliquer les grandes lignes son fonctionnement et de vous donner envie de bidouiller une carte fox ^^

L'idée est donc d'initialiser tout d'abord la connexion série à l'aide de Termios. La documentation sur le site du constructeur regorge d'informations et propose du code tout fait pour gérer la connexion série. Une fois la configuration réalisée (c'est très rapide à réaliser), il n'y a plus qu'à faire un write sur /dev/ttyS2

char command1[50];
char command2[50];
sprintf(command1, "AT+CMGS="%s"x0D", number);
sprintf(command2, "%sx1Ax0D", text);
write (tty_fd, command1, strlen(command1));
sleep(1); // attend la réponse du modem afin d'envoyer la seconde partie
write(tty_fd,command2,strlen(command2));

Et le SMS est envoyé ! Après libre à vous de rajouter à la suite une lecture de la réponse du modem (gentil petit read). Dès lors il est possible de se faire une petite fonction d'envoi de SMS à partir d'arguments tels que le numéro de téléphone et le texte du message. J'en ai profité pour me rajouter un système de logs et de manipulation du modem (redémarrage, arrêt). Je me suis créé une interface web en bash (scripts cgi) et par simples appels de notre programme C il est alors possible de se construire une application métier complexe. On a plus qu'à brancher notre carte fox sur le réseau et celle-ci peut envoyer des SMS à distance de manière assistée grâce à des formulaires web !

Préparation de la carte FOX

Dernier point de précision: au démarrage, le modem n’est pas allumé ni configuré. Il faut par conséquent créer un script de démarrage à déposer dans /etc/init.d/boottime . Voici le script que j'ai utilisé:

#!/bin/sh
# démarrage du modem
setbits -p b -b 7 -s 1
# Lancement de termnetd (pour les tests)
/mnt/flash/termnetd
# Initialisation série du modem (mon petit programme d’initialisation de la connexion série)
/mnt/flash/tx/sms -init
sleep 20
# Initialisation AT du modem
/usr/sbin/chat -V -s -f /mnt/flash/tx/scripts/scriptAT.chat >
/dev/ttyS2 < /dev/ttyS2 2> /mnt/flash/tx/scripts/scriptAT_result.txt
# Ecriture des logs (pour le fun ^^)
echo “`date` : MODEM start” >> /mnt/flash/tx/log/fox.log

On commence par allumer le modem, on initialise la connexion série avec le programme en C puis attend 20 secondes que le modem soit identifié sur le réseau. Le temps choisi est totalement arbitraire. Cela semble fonctionner correctement avec cette période, mais idéalement il serait intéressant d’interroger le modem pour déterminer s’il est bien connecté au réseau. Ensuite on exécute un script chat que voici :

ABORT BUSY
ABORT 'NO CARRIER'
ABORT ERROR
'' AT
OK ATZ
OK 'ATE0'
OK 'AT+CMGF=1'
OK ''

Ce dernier permet de désactiver l’écho afin de ne pas recevoir mes commandes en double, et permet d’activer le mode texte pour l’envoi de SMS. Par défaut l’envoi de SMS se fait en mode PDU (sous forme hexadécimale), ce qui est bien plus compliqué à utiliser. Une fois ce script exécuté, le modem est prêt à être utilisé. On peut rajouter un log à la fin pour identifier le démarrage du modem.

La carte fox est une carte embarqué assez simple à prendre en main, les utilisations sont assez illimités. Le rêve de tout bidouilleur !
Je songe à m'en commander une très bientôt, je ne peux pas résister à tant de potentiel de bidouille.

A suivre : Comment connecter la carte fox au réseau GPRS pour pouvoir aller sur le net et envoyer des mail