La communication par lien SPI (Serial Peripheral Interface) est un élément important pour les systèmes embarqués. Ceci concerne les micro-contrôleurs (systèmes industriels par exemple), mais également les cartes à micro-processeurs que l’on emploie de plus en plus pour les piloter. Le system-on-chip qui équipe le Raspberry Pi ne fait pas exception, nous pouvons le vérifier.
Archives de la catégorie ‘Microprocesseur’
Un Raspberry Pi de 512 Mo ?
Depuis quelques jours les Raspberry Pi sont produits et livrés avec 512 Mo de mémoire plutôt que 256 Mo auparavant. Ceux que j’ai reçus ce matin (pour préparer une session de formation) semblent bien disposer de cette extension.
Voyons un peu…
En complément de l’article sur la préparation d’une toolchain avec Buildroot pour Raspberry Pi, et comme Thomas Petazzoni (dont je vous recommande le blog) l’a suggéré en commentaire, on peut préférer construire la chaîne de compilation avec crosstool-NG. Celle-ci offre plusieurs avantages : la toolchain sera relogeable (déplaçable où l’on souhaite dans l’arborescence sans imposer d’emplacement absolu) et elle pourra s’appuyer sur la bibliothèque GlibC ou la eGlibC plutôt que la bibliothèque uClibC. J’ai choisi ici de sélectionner la bibliothèque eGlibC, plus adaptée à un environnement embarqué.
La norme RS-485 (EIA-485 de son nom officiel) définit des communications séries rappelant celles de la norme RS-232 bien connue mais disposant de beaucoup moins de signaux de contrôle. Son utilisation sous Linux est un peu plus compliquée que ce que je pensais initialement.
J’ai remarqué, au cours de plusieurs sessions de formations, que de nombreux développeurs pensent que certains opérateurs du C (ou de ses descendants) sont naturellement atomiques vis-à-vis de l’ordonnancement. Pour vérifier ou réfuter ceci, j’ai fait récemment quelques essais avec les participants d’un de mes cours.
J’ai poursuivi les tests entamés dans l’article précédent de cette série, en laissant tourner pendant de longues durées un programme qui vérifie les fluctuations d’un timer logiciel à 100 micro-secondes. Voici quelques résultats obtenus sur la Pandaboard avec un noyau Linux 3.4.1 en version « vanilla » pour commencer, puis avec l’application d’un patch Linux-rt par la suite.
Je conseille souvent à mes clients de faire des tests de longues durées pour leurs systèmes temps réel avec des charges extrémement élevées, tant en interruptions qu’en processus, afin de valider la bonne tenue de l’architecture choisie. Il s’agit d’aller sensiblement au-delà de la charge prévue lors de la conception, et de laisser le système en fonctionnement le plus longtemps possible (plusieurs jours au minimum) afin de pouvoir observer les cas rares où les latences maximales sont atteintes.
Nous allons réaliser ce genre de torture test pour la Pandaboard.
Suite à un petit commentaire de Yoann Sculo concernant l’avant dernier article, j’ai eu envie de détailler un peu le fonctionnement du multiplexage des GPIO sur un processeur OMAP (comme celui de la Pandaboard), et les paramètres auxquels nous pouvons avoir accès par l’intermédiaire du système de fichiers debugfs.
Nous avons vu dans les articles précédents comment écrire sur une broche de sortie du connecteur d’extension de la Pandaboard depuis l’espace utilisateur, puis depuis le kernel. Nous avons également réussi à lire l’état de broches GPIO d’entrée. Cette fois, nous allons améliorer cette lecture en gérant l’occurence d’événements par l’intermédiaire d’interruptions.
Dans les articles précédents, nous avons vu comment accéder aux sorties GPIO de la Pandaboard depuis l’espace utilisateur (premier article) et depuis l’espace noyau (second article) Linux et Xenomai. Nous allons maintenant nous intéresser à la lecture de l’état des entrées GPIO.
