L’arrivée du Rapsberry Pi (http://www NULL.raspberrypi NULL.org/) a fait beaucoup parlé de cette famille de PC « embarqués ». Les 10 000 premières unités produites ont été précommandées par au moins 200 000 clients ! Un point sur ce qu’ils sont réellement et leur intérêt pour les radioamateurs me paraît nécessaire.

(http://img1 NULL.lesnumeriques NULL.com/news/23/23602/rapsberry-pi-mini-pc-35 NULL.jpg)Nous commencerons par les plus anciens de la famille des BeagleBoard (http://beagleboard NULL.org/), projet totalement ouvert, plus destinés à être des « plateformes de développement » selon leurs auteurs et qui sont appuyés par Texas Instrument cherchant ici à développer l’usage de ses processeurs. L’architecture étant ouverte, un industriel peut ensuite produire une série taillée sur mesure de la plateforme correspondant exactement à ses besoins et réduisant les coûts.

Le Rapsberry Pi est plus un produit pour geeks et se veut vendu en masse. Plus fermé conceptuellement, il offre aussi moins de possibilités pour le concepteur du matériel de bidouiller.
Le dernier de la famille, dont nous ne parlerons pas c’est le Cotton Candy (http://www NULL.fxitech NULL.com/products/) : Un PC au format Clé USB plutôt puissant (il embarque un processeur Cortex A9 et 1 Go de RAM) n’offrant en fait aucune vraie entrée-sortie.

Tout d’abord les caractéristiques.

BeagleBoard originale

• 125 $
• Texas Instrument OMAP3530 à 720 MHz (ARM Cortex A8) = 1200 MIPS
• Processeur graphique PowerVR SGX530
• DSP TMS320C64x+ pour vidéo HD ou divers traitement du signal (SDR)
• 128 Mo RAM, 256 Mo Flash
• Bus I2C/SPI, GPIO, RS-232, JTAG
• Connecteur USB et USB-on-the-go, lecteur carte MMC/SD
• Entrée-sortie audio stéréo
• Sortie DVI et S-Video
• OS : Android, Ubuntu, WinCE, RISC OS, Symbian…autres Linux

BeagleBoard-xM (différences avec le BeagleBoard original) :

• 149 $
• Texas Instrument OMAP3530 à 1 GHz
• 512 Mo RAM, pas de Flash intégrée
• Ethernet 10/100
• Port caméra
• Lecteur MicroSD (jusque 4 Go)
• Sortie HDMI (plus de DVI)

PandaBoard ES

• 182$
• Texas Instrument OMAP4460 à 1,2 GHz (ARM Cortex A9 bicoeur)
• Processeur graphique PowerVR SGX540 à 384 MHz
• DSP TMS320C64x
• 1 Go de RAM, pas de Flash intégrée
• Lecteur carte SD (SDHC jusque 32 Go)
• Ethernet 10/100, Wifi et Bluetooth
• Bus I2C/SPI, GPIO, RS-232, JTAG
• Port caméra, Connecteur DSI pour écran LCD
• USB et USB-on-the-go
• Sortie DVI et HDMI
• OS : Android, Ubuntu et RISC OS

Raspberry Pi

• 35$
• Broadcom 2763 à 700 MHz (ARM1176JZF-S)
• 256 Mo RAM
• Sortie audio stéréo (pas d’entrée)
• Ethernet 10/100
• Bus I2C/SPI, GPIO
• Connecteur DSI pour écran LCD
• OS : Debian, Fedora, RISC OS
  (l’architecture ARMv6 n’est pas supportée par Ubuntu ou Android)

En faisant une petite recherche sur le web on se rend vite compte que peu de projets tournant sur ces plateformes ont trait au radioamateurisme. Ceci pour plusieurs raisons.

Tout d’abord une grande partie des applications que nous utilisons (cahier de trafic, cluster, modes numériques…) a besoin d’une interface homme-machine (un écran, un clavier en résumé) et ceci n’est pas inclus dans les produits ci-dessus. Le coût au premier abord paraît faible mais quand on y ajoute un écran on arrive vite à celui d’un PC portable premier prix.

Ensuite, pour faire de ces systèmes un contrôleur de radio type SDR, se présentent rapidement deux écueils. Le premier c’est l’absence d’entrée-sortie à grande vitesse (le plus rapide étant le bus USB) pour accéder directement aux données d’un ADC comme sur le HPSDR. Les Beagleboard embarquent bien une entrée-sortie audio stéréo (soient 2 DAC et 2 ADC) mais les circuits sont de piètre qualité, loin des besoins d’une vrai radio SDR. Le deuxième c’est la difficulté pour programmer le DSP embarqué dans ces systèmes. Contrairement à ce qui existe sur d’autres plateformes dédiées au traitement du signal (comme celles utilisées sur le SDR2Go (http://www NULL.qsl NULL.net/k5bcq/Kits/Kits NULL.html) ou le SDRCube (http://www NULL.sdr-cube NULL.com/)), ici tout est à faire ou presque, et cela rebute pas mal de développeurs (voir le portage de GNU Radio sur Beagleboard (http://www NULL.opensdr NULL.com/node/17)).

Quand on regarde bien, le vrai but de ces produits n’est pas de fournir un système polyvalent mais surtout une plateforme « multimédia » comme le sont les smartphones avec qui ils partagent la plupart des composants micro-processeur en tête. Ok ils disposent d’entrées-sorties supplémentaires pour les adeptes de la bidouille, mais celles dont nous aurions besoin !

Un peu après avoir publié cet article j’ai lu un message sur la liste Knight QRSS qui suggérait que ce type de PC embarqué pourrait être parfait pour servir de Grabber QRSS. C’est une application que je n’avais pas envisagé. Seule la PandaBoard a suffisamment de puissance pour servir de décodeur WSPR par contre. A moins de porter les algorithmes de K1JT sur le DSP, mais c’est une autre paire de manches.

Et Arduino ?

En guise de conclusion, comment ces produits se comparent-ils à un Arduino (http://www NULL.arduino NULL.cc/) ? Tour d’abord en terme de performances brutes l’Arduino est largement derrière. Le processeur de l’ArduinoMega est à 16 MHz, 8ko de SRAM, 256Ko de Flash, pas de DSP, pas de circuits vidéos… rien à voir. C’est vrai qu’un Arduino est aussi puissant qu’un ordinateur familial des années 80, et qu’il peut déjà faire pas mal de choses.

La vraie force de l’Arduino c’est d’automatiser des tâches nécessitant beaucoup d’interactions électriques ou électroniques : commandes des relais (pour une balise, un manipulateur CZ) , capturer des valeurs (fréquencemètre, Wattmètre), piloter un bus I2C. Ecrire un tel code sur un Arduino est très simple et permet de concevoir un matériel autonome, fiable, très simple, consommant peu d’énergie et peu coûteux à produire en série si besoin. L’environnement de développement (IDE) de l’Arduino permet de concevoir un tel code en quelques minutes.

Bien entendu, on peut faire la même chose avec un BeagleBoard dont les entrées-sorties GPIO et I2C sont accessibles par des commandes du shell Linux. Honnêtement, c’est un peu utiliser un marteau-pilon pour enfoncer une punaise, et si on veut faire des choses complexes on va sentir le besoin d’un vrai environnement de développement et d’un langage dédié. De plus dupliquer le circuit sera difficile et coûteux et la complexité du matériel (et du logiciel) augmente le risque de panne.