Vous savez sans nul doute que le RaspberryPi n’est pas équipé d’une horloge temps réel pour des raisons de coût. La distribution Raspian a fait le choix de récupérer l’heure sur Internet quand la carte est connecté sinon elle repart avec la dernière heure connu (fake_hwclock). Bien sur ce n’est pas satisfaisant…aussi vous trouverez sur le grand “n’Internet” nombre de site qui décrive comment rajouter une RTC (principalement en I2C). J’ai même fait quelques lignes la-dessus à la fin de l’article sur l’I2C sur Raspberry. Cependant je voudrais faire “encore mieux”, en particulier que la partie “user space” (espace utilisateur) ne gère pas cette RTC mais que le noyau s’en charge de A à Z. Cette article décrit cette mise en oeuvre.
Lire la suite…
Dans la suite de l’article je présente l’activation puis l’utilisation du bus I2C sur la carte RaspberryPI (ou tout autre carte qui supporte un bus I2C : Olimex A13 ou iMX233, Beagle/PandaBoard de TI, TQ6410, etc…). L’interrogation des esclaves connectés au bus I2C peut se faire sans aucune programmation ! Cela permet de valider rapidement l’écriture ou la lecture des registres d’un esclave I2C. On peut alors passer à la programmation en C/C++ avec des valeurs validées. Lire la suite…
De plus en plus de cartes électroniques à bas coût sont disponibles sur le marché de l’embarqué. Dans quasiment tous les cas elles sont équipées d’un coeur ARM. Par exemple, le RaspberryPi (ARM11 : architecture armv6) ou les cartes Olinuxino (ARM9 (armv5) pour la iMX233 et Cortex A8 (armv7) pour la carte A13) utilisent des processeurs ayant un coeur ARM. Suivant le processeur utilisé, celui-ci peut posséder une unité de calcul en virgule flottante. Nous aurons donc à installer une chaîne de cross-compilation qui supporte ou pas l’unité de calcul en virgule flottante. Sur Debian, le projet emdebian propose des cross-compilateurs pour les architectures précédemment cités.
Imprimer cet article
Lire la suite…
Pour un projet industriel, nous devons gérer 8 entrées/sorties tout ou rien (TOR). Le noyau Linux, s’il est correctement configuré et compilé permet de gérer ces E/S au travers d’une interface de type fichier. Les notes qui suivent permettent de gérer ces E/S.
Lire la suite…
La saga TQ6410 continue…Dernièrement la nappe de fils (4 fils) qui relie la dalle tactile à son contrôleur au dos de l’écran s’est coupée nette ! J’ai bien essayé de la réparer en grattant le plastique mais rien n’y fait et j’abime la nappe plus qu’autre chose. Donc direction e-bay pour l’achat d’une nouvelle dalle tactile (à environ 15€). La carte devait être utilisé pour présenter le travail d’un étudiant sur la commande de régulateur de température sur ModBUS, il faut donc trouver une autre solution pour interagir avec les programmes en Qt. La carte dispose d’un port USB1.1, nous allons donc utiliser ce port pour connecter un hub usb, une souris et un clavier.
Lire la suite…
Pour un projet industriel, les étudiants doivent utiliser QT4 et dialoguer avec différents appareils par le port série. QT4 ne délivrant pas nativement de classe gérant le port série, il faut se tourner vers des développements extérieurs. Pour l’instant j’en connais deux:
Mon environnement de développement sera une debian Squeeze. QTCreator est installé depuis les paquets standards (en version 1.3.1 basé sur les librairies QT 4.6.3). Lire la suite…
Cette carte a été acheté dans le but de développer une application graphique de commande d’un processus industriel. Le choix du kit graphique est pour l’instant Qt. Pour construire cette application, nous allons la développer sur notre machine de bureau puis la “cross-compiler” pour ensuite la faire fonctionner sur le système embarqué. Il existe sur internet de nombreux sites qui présente cette méthode. Je me base sur les sites suivants : http://cor-net.org/2009/03/qt-45-on-mini2440/ , sur le bill’s blog et sur le site de Pobot (article1 et article2).
Lire la suite…
Maintenant que la plateforme de test générique est fonctionnelle, nous allons faire quelques tests pour optimiser l’ensemble. Nous allons nous consacrer à réduire le temps de chargement du noyau jusqu’au passage au système de fichiers racine. Puis dans un second temps nous choisirons le système de fichiers du rootfs. Une grande partie des optimisations mises en place viennent de remarque de ce site : eLinux.
Lire la suite…
Après la découverte de cette carte, nous allons passer à l’étape de personnalisation. Nous souhaitons faire de cette carte une plateforme de développement générique pour développer des applications en C/C++ et QT. Dans un proche avenir cela peut être complètement autre chose (Python et GTK+ par exemple). Aussi pour avoir une base solide et facilement maintenable, nous allons installer la version embarqué de la distribution Debian : emDebian. Par la même occasion, nous allons recompiler le noyau pour l’adapter à nos besoins (pas de multimédia par exemple). Ces différentes étapes sont décrites dans la suite de l’article… Lire la suite…
J’ai récemment fait l’acquisition d’une carte TQ6410 (SoC Samsung s3c6410 ARM11, Flash NOR: 1Mo, Flash NAND: 256Mo, RAM: 128Mo) avec un écran tactile de 7 pouces dans le but de développer une application industrielle avec des élèves de seconde année BTS IRIS. Cette carte ressemble à une autre carte bien connu : la FriendlyARM 6410. Cette carte provient d’un vendeur sur e-bay (esky-sh) au prix de 175 € (frais de port compris, frais de douanes en sus). Dans l’article qui suit je détaille la prise en main de cette carte : déballage, quelques tests mais surtout l’installation d’une emDebian pour faciliter la gestion des paquets et en faire une base générique de développement. Le but final est d’implanter une application fonctionnant avec le kit graphique Qt de Nokia… Lire la suite…