Friedt Jean-Michel

La diffusion à large échelle de la communication radiofréquence dans les appareils grand public induit la disponibilité de composants aux performances compatibles avec ces modes de communication (fonctionnement de 50 à 2500 MHz ou plus, bandes passantes de l’ordre de la dizaine de MHz) et pour des prix ridiculement faibles grâce à la production de masse. Nous allons profiter de cette mode en présentant l’utilisation d’un récepteur de télévision numérique - DVB basé sur le composant Elonics E4000 - dont l’étage de réception s’avère tellement simple qu’il est compatible avec de nombreux modes de transmission analogique et numérique de données par liaison radiofréquence. Le flux de données brut issu du récepteur radio est traité par des blocs implémentant les fonctionnalités les plus classiques dans le logiciel gnuradio et son interface graphique gnuradio-companion. Nous verrons comment, au delà de la simple utilisation des blocs de traitement disponibles, implémenter nos propres algorithmes de décodage sur le flux d’informations reçu du récepteur radiofréquence. Nous nous intéresserons en particulier au packet, au protocole ACARS, et aux radiomodems encodant l’information en FSK et AFSK.

Le PostScript [1] est remarquable, parmi les modes de rendu de graphiques, par le fait qu’il constitue un vrai langage de programmation fournissant la majorité des fonctionnalités attendues par un tel outil de développement. Contrairement au PCL (Printer Command Language – commandes pour certaines imprimantes Hewlett Packard et autres), HPGL (déplacement du stylo d’un plotter1) ou PDF qui ne proposent que des ordres d’affichage [2], le PostScript offre une grammaire complète incluant conditions, boucles, variables, gestion de pile voire même accès aux fichiers, qui en font un réel langage associé à une interface graphique [3].

La décomposition en série de Fourier, et plus généralement la transformée de Fourier [1], est un outil incontournable du traitement du signal visant à décrire des propriétés fréquentielles (spectrales) d’un signal. Au-delà de la maîtrise de l’outil mathématique qui fera l’objet de la première partie de cette présentation, son utilisation sur un système embarqué peut paraître complexe, voire rédhibitoire. Nous analyserons, dans la seconde partie, une note d’application qui démontre l’utilisation en virgule fixe de tables pré-calculées pour effectuer rapidement un calcul apparemment complexe, et ce pour un résultat compatible avec tout microcontrôleur proposant quelques kilo-octets de mémoire. Enfin, nous appliquerons cette méthode de calcul à quelques exemples plus ou moins triviaux. Nous mettrons en œuvre ces concepts, et l’échantillonnage périodique de signaux pour fournir les informations à traiter, sur architecture ARM Cortex-M3 telle qu’implémentée par ST sur le STM32, traitant les signaux issus d’un RADAR à onde continue.

Au sein de la gamme des cœurs de processeurs proposés par ARM, le Cortex-M3, opérant sur des registres de 32 bits, fournit un compromis entre une puissance de calcul appréciable et une consommation réduite qui, sans atteindre les performances du MSP430 (16 bits), propose néanmoins des modes de veille en vue de réduire la consommation moyenne d’une application. Bien que les nombreux périphériques disponibles ainsi que l’énorme quantité de mémoire associée à ce processeur puissent justifier l’utilisation de bibliothèques dont une implémentation libre est disponible sous le nom de libopencm3, nous verrons qu’il est possible d’appréhender un certain nombre de ces périphériques pour en faire un usage optimal en accédant directement aux registres qui en contrôlent l’accès. Le cœur M3 est décliné par de nombreux fondeurs : nous nous focaliserons ici sur l’implémentation de ST Microelectronics sous le nom de STM32F1 (dans la suite, le microcontrôleur sera nommé simplement STM32 car la plupart des applications sont portables sur les autres modèles).

La disponibilité d’une masse croissante de données via Internet permet à chacun d’appréhender des problèmes qui restaient confinés jusque récemment à un cercle restreint d’utilisateurs suffisamment chanceux pour accéder à ces données. Ainsi, seule la compétence de traitement limite aujourd’hui la capacité de toute personne à extraire un maximum d’informations de ces données.

Toute conception de circuit électronique analogique qui ne soit pas complètement triviale passe par une phase de simulation, ne serait-ce que pour identifier l’influence des divers blocs de référence entre eux, ou l’effet de l’incertitude de la valeur des composants sur la fonction de transfert du montage.

Les iPod Touch et iPhone sont probablement les systèmes embarqués les plus largement disponibles auprès du grand public. Bien que le qualificatif « embarqué » ne soit associé qu'à leur autonomie, faible encombrement et absence de ports de communication, la puissance de calcul est compatible avec celle nécessaire pour exécuter un environnement Un*x dans lequel un développeur sous GNU/Linux ou *BSD sera familier. Nous proposons dans cette présentation, après avoir libéré son iPod Touch de l'emprise de Cupertino, d'exploiter une chaîne de compilation croisée libre exploitant les bibliothèques propriétaires mais gratuites d’Apple, pour développer nos propres applications. Nous nous intéresserons en particulier à l'accès aux périphériques matériels, qu'il s'agisse d'une liaison Bluetooth pour communiquer par une liaison sans fil avec des périphériques tels que la brique LEGO NXT, ou des accéléromètres. Ces développements passent nécessairement par la maîtrise de l'Objective-C 2.0, dont nous démontrerons la fonctionnalité comme langage de développement sous GNU/Linux lors de l'exploitation du compilateur LLVM.

Nous proposons d'aborder le developpement sur microcontrôleur selon un aspect « environnement exécutif » fourni par TinyOS. La plate-forme minimaliste – le microcontrôleur MSP430F149 avec 2 KB de RAM – est exploitée au mieux grâce à cet environnement de développement. Nous démontrons la mise en oeuvre de cette plate-forme, munie d'une carte SD, pour le stockage de masse non volatil de données acquises périodiquement sur support formaté accessible depuis la majorité des ordinateurs personnels (FAT).

Le monde des instruments de mesure est suffisamment restreint pour qu'un petit nombre de protocoles aient émergé et que ces interfaces soient disponibles sur la majorité des équipements. Historiquement, le contrôle d'instruments s'est longtemps fait par une norme peu connue dans les milieux autres que l'instrumentation scientifique – GPIB, norme IEEE 488.2 – qui tend aujourd'hui a être remplacée par un protocole sur bus ethernet, VXI11.