Bonjour,

Je continue mes expériences avec le Raspberry Pi qu’on m’a prété et dont il a déjà été question dans l’article mettant en scène le netHOST.

Avec le netHOST, la communication s’établissait via une connexion TCP/IP. Dans cet article, nous allons établir une connexion avec un netRAPID via l’interface SPI disponible sur le connecteur d’extension du Raspberry Pi.

On voit sur la photo suivante à gauche le Raspberry Pi et à droite une carte d’évaluation équipée d’un netRAPID, l’espèce de timbre au centre, le tout connecté via SPI, les cinq fils noirs.

La famille de « System on Chip » netX qui équipe tous les produits de la société Hilscher s’est étoffée avec les successeurs du netX 50 que sont les netX 51 et netX 52.
Avec le netX 10, ces SoC possèdent entre autres une interface Fast SPI qui permet via un composant matériel dédié, la SPM – pour Serial Port Memory – d’accéder à la désormais fameuse Dual Port Memory via une interface sérielle plutôt que par les traditionnels bus d’adresse et bus de données.

Cela permet d’utiliser comme processeurs hôtes des puces de surface réduite, plus économiques, et conduit à des solutions plus compactes.

Les netX 51 et 52 se distinguent de leur prédécesseur le netX 50 par leur capacité mémoire interne étendue qui permet d’exécuter les piles de protocoles optimisées sans nécessiter de mémoire RAM externe. Le netX 52 dispose de la même architecture interne que le netX 51 à ceci près qu’on lui a ôté le bus mémoire externe afin de réduire son empreinte et son coût.

Ainsi le netX 51 équipe par exemple le comX 51-CA-RE qui permet d’exécuter toutes les piles de protocoles Ethernet Temps Réel en mode esclave avec une fonctionnalité complète.

Les netX 51 et 52 disposent de deux canaux de communication tandis que le netX 10 en possède un seul. Ils sont prévus pour exécuter les piles de protocoles en version esclave uniquement.

On trouve le netX 10 équipant les comX 10 pour l’exécution des piles PROFIBUS DP, CC-Link, DeviceNet et CANopen esclaves.

Les solutions modulaires comX conviennent lorsque l’on recherche une solution de connexion aux bus de terrain interchangeable. Avec leur connecteur Hôte commun à toutes les versions et leur API également commune, il est aisé de les installer en fonction du besoin d’autant qu’ils fournissent de surcroît l’interface au bus avec l’isolation galvanique et la connectique.

Il est possible également de développer des équipements intégrant les SoC netX en tant que coprocesseur de communication lorsque le volume devient important et que les objectifs de coût le nécessitent. Cela demande cependant autrement plus d’effort que pour la mise en oeuvre d’un module comX.

Afin de faciliter la tâche des électroniciens et diminuer le « Time to Market » la société Hilscher a développé le netRAPID, une solution de module à souder directement sur le PCB comme un composant CMS. Il est également possible de le souder à la main lors de la réalisation de prototypes.

Le netRAPID contient tous les éléments actifs, le chip netX lui-même, un netX 10 pour les versions bus de terrain classiques ou un netX 52 pour les versions Ethernet Temps Réel, la Flash nécessaire au stockage du firmware et éventuellement de la configuration, les composants générant les tensions pour le cœur processeur et celles pour le bus de terrain, l’isolation galvanique…

Pour l’interface avec l’hôte, le netRAPID dispose de la classique DPM accessible sur l’interface parallèle ou sur l’interface SPI, celle qui nous intéresse pour cet article.

Et voilà où je voulais en venir !

Du point de vue applicatif, que ce soit une cifX, un comX ou un netRAPID, c’est du pareil au même. L’interface applicative est identique.

Hilscher fournit les pilotes pour tous les systèmes d’exploitation du marché dont Linux. Avec ce pilote, il est possible d’accéder à tous les produits de la gamme, que ce soit au travers d’une interface ISA, PCI, PCIExpress, DPM ou SPI.

Il est également fourni des exemples d’utilisation, notamment pour SPI, dont je me suis plus que largement inspiré pour y connecter avec « Ada for Automation ».

Taaa taaan ! Voilà, c’est dit !
Il est à présent possible de connecter un netRAPID sur un Raspberry Pi via SPI et de développer une application esclave sur un bus de terrain avec « Ada for Automation ».

Sur cette vue on distingue au fond l’IDE GNAT Pro Studio, à droite le terminal d’où on a lancé l’application et la trace résultante et à gauche en bas l’interface graphique de l’application.

La vue d’état montrant l’exécution d’un firmware PROFINET IO Device sur le netRAPID.

Bon, il est aussi possible de développer en C/C++ hein…

D’un point de vue pratique, la carte d’évaluation du netRAPID dispose de broches de test sur l’interface hôte que j’ai connectées directement avec celles en regard sur le port d’extension du Raspberry Pi. En tout et pour tout cinq petits fils.

Si vous cherchez le brochage du port d’extension du Raspberry Pi ne cherchez plus. Monsieur Christophe BLAESS en fournit ce qu’il faut pour notre besoin du jour :
http://www.blaess.fr/christophe/2012/11/02/spi-sur-raspberry-pi-1/#more-3043

A cela près que mon ami Marco Buffa de Hilscher Italy m’a bien aidé en me procurant les dits fils dont un, le MISO dispose d’une résistance de 120 Ohms car sinon il y a quelques perturbations sur la ligne. Il m’a également donné une carte d’évaluation comX de sa conception que je vous présenterai sans doute prochainement.

Il vous faudra acquérir auprès de Hilscher France le pilote Linux qui est fourni sous forme de code source et le compiler sur le Raspberry Pi avec les bonnes options pour activer les fonctions de lecture et écriture de la SPM.
C’est trivial et je suis là en cas de besoin. Ce pilote n’est à acheter qu’une fois.

Après, hormis les fonctions d’initialisation / dés-initialisation du pilote qui sont différentes, le reste de l’API est identique et l’on se sert du netRAPID comme d’un comX ou d’une cifX.

Pour l’initialisation du pilote, il suffit de fournir le « device » qui va bien (i.e. « /dev/devspi0.0 » dans mon cas puisque j’ai connecté le Chip Select 0), et de spécifier la vitesse de transmission (le netX supporte jusqu’à 33 MHz en mode esclave, j’ai testé avec 16 MHz).

On aura au préalable activé la liaison SPI par exemple avec raspi-config dans les « Advanced Options ».

Et ça sert à quoi ?

On peut imaginer qu’en phase de prototypage cela permette de gagner du temps en disposant d’une cible plus ou moins proche de celle que l’on souhaite mettre en œuvre.

Ainsi, que vous projetiez de réaliser un module d’entrées / sorties, un codeur, un variateur, un appareil de mesure quelconque devant disposer d’une connectivité bus de terrain, vous pouvez commencer votre développement sur le Raspberry Pi.

Pourquoi pas une machine pilotée par un Raspberry Pi, avec une interface web et discutant avec un automate de ligne ?

Incrédules ? J’espère bien vous surprendre bientôt… 😉

Cordialement,
Stéphane