[

Accueil > Actions du réseau > Groupes de Travail / Projets > Systèmes Embarqués > ARM9 > Raspberry Pic Club

Raspberry Pic Club

mercredi 13 mars 2013, par PALLUT René

Le titre de cet article fait bien entendu référence à RASPBERRY-PI, que nous appellerons Raspy par commodité.

En quoi l’apparition de cette carte change-t-elle la donne ?

Essentiellement parce que son prix la positionne très près des produits à base de Processeurs 8 bits et permet de la considérer comme un Macro-composant, plutôt que comme l’élément central d’un système.

En effet il est tout à fait possible de combiner cette carte avec d’autres Contrôleurs, voire avec des cartes de développement, sans pour autant atteindre le prix d’une carte "Linux embarqué" classique.

Bien sûr les limitations existent, et Raspy est loin d’avoir la puissance et les fonctionnalités d’une carte telle que ARMADEUS par exemple (nombreux bus industriels, FPGA, ...), et c’est bien pour cela qu’il ne faut "pas trop lui en demander"...

Avec ARMADEUS, nous avions envisagé de créer un interface unifié exploitant le FPGA pour créer un plan mémoire qui aurait constitué le média unique d’échange entre la CPU et les périphériques "recherche" (I/O, convertisseurs,etc...). Malheureusement, il n’est déjà pas simple de maitriser Linux dans ses fonctionnalités "intimes", et si l’on ajoute à cela l’apprentissage des FPGA celà devient "mission impossible" pour beaucoup d’entre nous.

Avec Raspy, nous aurons forcément une "bande passante" réduite par rapport à un plan mémoire FPGA , mais nous pouvons quand même exploiter les bus disponibles (RS232, SPI, I2C) pour définir une norme d’interface avec nos applications Hardware, qui devrait satisfaire, d’après les enquêtes réalisées, 80% des utilisateurs.

pourquoi s’encombrer d’une carte supplémentaire alors ??

Tout simplement pour réaliser toutes les tâches qui nous ont conduit à essayer d’utiliser LINUX embarqué : Stockage de masse, IHM graphique, communications USB et internet. Ces tâches sont réalisables sur un Processeur 8 bits, mais occupent une grande partie des ressources et restent complexes à faire cohabiter avec des applications hardware dont le timing est un peu sensible.

Inversement, Faire fonctionner une application Hardware directement à partir de LINUX nécessite généralement de "Patcher" Xenomaï (Linux pseudo temps réel) et de "rentrer" très sérieusement dans le fonctionnement et la structure de Linux... ce que relativement peu d’électroniciens sont parvenus à faire à ce jour, malgré une excellente formation LINUX embarqué, car nous ne sommes pas des Linuxiens de métier, et ne pouvons pas tous consacrer énormément de temps à nous former sur ce sujet. C’est une des raisons qui explique la relativement faible production du groupe ARM/Linux en 3 ans.

L’idée qui motive la création de ce Club est donc de "Paxer" une Raspy et un PIC...

Union "contre nature" me direz vous ??

Perte de temps et d’énergie inutile ??

Je pense que c’est tout le contraire, pour les raisons suivantes :

- Dès l’origine, avec le PIC16C54, la philosophie de Microchip a été de proposer des produit "stand alone" (autonomes) parfaitement adaptés aux fonctions périphériques.

- Il existe aujourd’hui une gamme très étendue tant en nombre de broches (de 6 à 100) qu’en fonctionnalités diverses, ainsi qu’une quantité phénoménale d’applications disponibles sur le web.

- Un groupe PIC, animé par notre ami Arnauld Biganzoli, et présent sur ce site, est tout à fait prêt à collaborer à ce projet.

- beaucoup d’entre nous ont déjà des applications à base de PICs et savent très bien se débrouiller avec les produits Microchip ; Il leur suffira d’ajouter à ces applications le mode d’interface unifié évoqué plus haut pour y ajouter des fonctionnalités de plus en plus demandées par nos utilisateurs : vérifier l’état du système, modifier des paramètres ou importer les données via Internet, mettre à disposition ces données pour plusieurs utilisateurs, afficher du graphique, faire du prétraitement, alimenter une base de données...

- Coté Raspy, l’intérêt de ce couplage est de se limiter à une connaissance relativement "standard" et superficielle de Linux. Cela permet bien sûr de démarrer plus facilement et plus rapidement, d’autant plus qu’il est facile de faire appel à un informaticien (même débordé) pour des tâches qui restent très basiques pour lui.

- Cela permettra aussi de s’acclimater, et de pratiquer Linux, donc de pouvoir devenir à terme un "expert", et de pouvoir, à ce moment là envisager une utilisation plus pointue du système.

- Enfin, je pense que Raspy est un produit extrêmement pérenne dans le sens où son prix, son succès, et l’esprit dans lequel elle a été créée la rendent incontournable, et que nous verrons à l’avenir, des évolutions, et probablement des clones de Raspberry-PI, tout comme il y avait des clones d’IBM PC il y a 25 ans : Toujours compatibles avec l’original, mais de plus en plus puissants et de moins en moins chers.

En conclusion, on voit donc que, loin d’être une perte de temps, ce partage des tâches entre une Raspy et un pic est une opportunité pour tous ceux qui s’intéressent aux micro-contrôleurs de produire rapidement, et à peu de frais des applications spectaculaires sans avoir à se torturer les méninges.

C’est aussi l’occasion de créer une vraie dynamique de partage et de mutualisation sur un système modulaire dans lequel chacun peut poser sa brique en fonction de ses compétences et de ses affinités, que ce soit dans le domaine du Hardware, des PICs, de Raspy, ou de Linux, PHP, et des IHM en général, en local ou sur le web.

Si l’on parvient à créer un interface unifié, chacun pourra créer un périphérique spécifique répondant à un besoin plus ou moins particulier, mais intégrable, avec d’autres périphériques, pour constituer un système complexe.
Nous avons beaucoup à gagner dans cette démarche (temps, argent, et surtout relationnel... )

William et moi-même avons investit quelques jours de notre temps pour poser une première pierre sous la forme d’un tutoriel qui se veut accessible à un vrai débutant en Linux, pour démarrer et configurer votre RASPY ; nous espérons pouvoir en écrire quelques autres...

Beaucoup d’entre vous se plaignent de "ne pas avoir le temps" , et nous pensons que ce tutoriel vous en fera gagner pas mal... n’hésitez pas à nous faire part de vos remarques (positives ou négatives) afin de l’améliorer si nécessaire ; n’hésitez pas non plus à le compléter ou à proposer vos propres articles à condition de rester dans l’esprit "Linux pour les Nuls" : détaillez chaque action, chaque ordre Linux (pourquoi, comment...) n’oubliez pas de parler des bibliothèques nécessaires n’utilisez surtout pas de liens qui renvoient sur des pages ou l’on est perdu (même si ça vous parait évident ...)

Certaines sociétés Américaines exigent 3 lignes de commentaire par ligne de code... même si c’est un peu caricatural, ce n’est pas si ridicule qu’il y parait...

Il reste à définir l’interface Raspy/PIC ; I2C me semble être intéressant dans le sens où il ne nécessite pas de Chip-Select mais sa mise en œuvre en I2C-slave sur le Pic ne s’avère pas "triviale" (n’hésitez pas à me contredire sur ce point...) .
Certains semblent penser que SPI serait plus robuste, mais il nécessite de gérer les GPIOs de Raspy... le débat reste ouvert...

Vous pouvez me contacter pour rejoindre le club (qui compte à ce jour une vingtaine de membres), et/ou visiter le Wiki dont l’adresse est jointe.

Pour vous abonner à la liste de diffusion : cliquez-ici

Pour vous désabonner de la liste de diffusion : cliquez-ici_(request)
ou cliquez-ici_(unsuscribe)

René Pallut

Voir en ligne : Tutoriel de démarrage RASPBERRY-PI