Installation d’un serveur DX Spider sur Raspberry Pi modèle A (1/2)

Introduction

Depuis plusieurs mois, nous assistons à la mise sur le marché de cartes électroniques dites « de développement » plutôt puissantes, en général compactes et au coût tout à fait modéré pour les amateurs et les bidouilleurs en tous genres. On peut citer par exemple la famille Arduino et ses innombrables cartes d’extensions (shields) qui ont permis à bon nombre d’hobbyistes d’accéder aux monde des microcontrôleurs, et qui ont littéralement dopé leur créativité.

Pour obtenir des caractéristiques supérieures en terme de puissance, mémoire, et connectivité, le Raspberry Pi (RasPi) est tout indiqué, toujours pour un coût très modeste. Il est décliné en deux versions, dites modèle A et modèle B dont les seules différences sont indiquées ci-dessous

Les parisiens pourront trouver ces cartes en boutique chez les distributeurs habituels Selectronic, Electro-Diffusion et probablement d’autres, mais aussi chez Hackspark, spécialisé dans ce type de matériel.

Le processeur qui anime ces deux cartes s’appuie sur une architecture ARM11, et peut être cadencé de 700 à 1 GHz par un overclocking extrêmement simple à mettre en œuvre. Il faut aussi noter que l’alimentation du RasPi peut s’effectuer en 5V par l’intermédiaire d’un simple chargeur de batterie de téléphone (connecteur micro USB). La consommation moyenne est entre 1 et 4 watts selon les périphériques USB utilisés, la vitesse du processeur, et sa charge CPU.

Avec des telles caractéristiques, il peut facilement se substituer aux serveurs lourds, encombrants, chers et consommateurs d’énergie qui peuplent de nombreux shacks de radioamateurs, pour assurer des services simples, à moindre coût.

Il m’a donc semblé naturel d’envisager l’installation et l’exploitation pour l’ARP d’un serveur cluster de type DX Spider sur une telle plateforme. L’objectif était donc d’adapter au plus juste les ressources disponibles à cette utilisation Par conséquent, mon choix s’est porté sur un modèle A dont l’unique port USB sera équipé d’un dongle Wi-Fi pour assurer la connectivité avec l’internet par l’intermédiaire de mon routeur domestique. Ce qui permet de le poser à proximité de n’importe quelle prise de courant du QRA et de l’oublier. Très petit, totalement silencieux, et largement moins d’un kWh de consommation électrique sur un an : Le rêve !

Installation du système

La mobilisation de l’unique port USB pour le dongle Wi-Fi interdit de facto la connexion d’un clavier au RasPi ce qui rend les choses un peu plus délicates pour l’installation et le configuration du système Linux. Il eût été possible, bien entendu, d’adjoindre un hub USB provisoirement (mais je n’en ai pas), ou de ne connecter le dongle qu’après configuration réseau « à l’aveugle » (avec un écran relié en HDMI ou vidéo composite). J’ai choisi d’ignorer ces solutions pour utiliser la liaison série dite « console » disponible sur 2 broches du connecteur GPIO.

Avant de se lancer dans ce genre de raccordement, il convient toujours de s’assurer des tensions mises en jeu afin de ne pas détruire ni l’équipement ni le convertisseur série lors de la manipulation. Le RasPi utilise une liaison série sous 3,3v et ses entrées-sorties ne tolèrent pas le 5v. Méfiance, donc !

De toutes façons, ne disposant pas non plus de convertisseur USB – série, couramment vendu pour cette utilisation, il va falloir un peu ruser ! Je possède un Arduino Nano, qui incorpore un convertisseur USB – série FT232RL pour programmer le microcontrôleur ATmega328. En consultant le schéma, il apparait que je peux récupérer sur les broches J1/1 et J1/2 du Nano les signaux série TxD et RxD issus du convertisseur, par l’intermédiaire d’une résistance de protection intégrée d’un kΩ. Par contre, ces signaux sont en logique 5v, et il faut donc les adapter au 3,3v.

Il existe pléthore possibilités pour cette adaptation (cf cette excellente note d’appli de Microchip sur le sujet). Comme nous sommes en présence de signaux unidirectionnels (a contrario par exemple de signaux I2C), la tâche est grandement simplifiée. Dans le sens Nano -> RasPi (signal TxD du Nano) un simple pont diviseur de tension 10kΩ / 20kΩ suffit à adapter ce signal, et dans le sens RasPi -> Nano (signal TxD du RasPi), une connexion directe devrait faire l’affaire puisque le 3v3 est supérieur aux 60% de l’alimentation du convertisseur équipant le Nano (soit 3v).

Il ne reste plus qu’à câbler tout cela sur une plaquette d’expérimentation. Je fais un premier essai sans le RasPi, en bouclant les signaux TxD après le pont diviseur et RxD, issus du Nano. Les caractères entrés dans PuTTY, correctement paramétré pour gérer la liaison série (115200 bauds, 8 bits de données, 1 bit de stop), reviennent bien en écho. Il ne reste plus qu’à se connecter sur les broches de la liaison série du RasPi (TxD, RxD et masse), mettre l’image de la distribution Raspbian sur une carte SD (ici 8 Go), et connecter l’alimentation du RasPi. Après quelques instants, et après l’envoi d’un retour chariot dans PuTTY, la console apparait !

Grâce à cette liaison provisoire, il ne me reste plus qu’à paramétrer le RasPi et le fichier de configuration du réseau Wi-Fi sur le RasPi (etc/network/interfaces) et l’essayer, avant de déconnecter définitivement la console.

auto lo
iface lo inet loopback

allow-hotplug wlan0
auto wlan0
iface wlan0 inet static
    wpa-ssid "XXXXX"          # SSID Wi-Fi reseau local
    wpa-psk "YYYYY"           # MdP Wi-Fi reseau local
    address 192.168.0.164     # IP fixe du Raspi
    netmask 255.255.255.0     # Masque de sous-reseau du LAN
    network 192.168.0.0       # IP Lan
    broadcast 192.168.0.255   # IP broadcast LAN
    gateway 192.168.0.254     # IP passerelle

iface default inet dhcp

Le RasPi est alors accessible en SSH, via son interface Wi-Fi, pour la suite de l’installation qui fera l’objet d’un second article.