Premiers pas avec le Beagleboard Green

Premiers pas avec le Beagleboard Green

Voici le dernier tutoriel de Vincent, l’un de nos Ambassadeurs Conrad. Celui-ci a un peu tardé à arriver pour des raisons logistiques 🙂
Il vous explique tout cela dans la suite. Bonne lecture !


Me voici au Japon… ce qui ne facilite pas forcément les choses.

Entre le déménagement, les aléas techniques, l’oubli de certains ‘trucs’ en France, les voyages, un rythme de vie fort différent… J’ai dû revoir fortement mes espérances initiales de planning (initialement, je pensais pouvoir fournir quelque chose en Juin…).

Si on rajoute les difficultés techniques (ma Beagleboard a un peu souffert pendant le voyage, vu que le connecteur d’alimentation est dessoudé, mise à jour de Linux qui a échoué, occasionnant une nouvelle installation), les difficultés techniques (tension et fréquence différentes,) et les difficultés linguistiques (essayer de configurer un routeur en langue japonaise, …), j’ai bien failli baisser les bras !

Ainsi je profite du temps de répit que me donne le passage d’un typhon (rétrogradé tempête tropicale) pour remettre le pied à l’étrier.

Précédemment, nous avons vu comment mettre en place une cross compilation, etc… maintenant, nous allons utiliser cet environnement pour notre projet.

Pour ce faire, je continue le projet, où nous allons acquérir des signaux audio (du code morse), les traiter et afficher la transcription. Cela sera une très bonne occasion pour parler des fichiers Overlay et de la configuration du Beagleboard (qui dans le principe peut être applicable à un Raspberry-Pi également).

  1. Mise à jour de la Beagleboard Cela fait plusieurs mois que ma carte est hors service. Une petite mise à jour lui serait donc profitable (d’autant plus que ma carte n’est plus visible sur mon réseau…). D’autant plus que Debian propose désormais la version 9 « Stretch ». Donc, rendez-vous sur http://beagleboard.org/latest-images pour télécharger la dernière version. J’ai choisi celle avec le support Gui en vue d’autres projets, mais la version loT (Non GUI) pourrait tout aussi bien convenir pour ce projet. La mise en place de l’image sur la carte SD ne pose pas de souci spécifique. Il suffit d’utiliser l’outil Etcher (https://etcher.io), comme l’indique la page http://beagleboard.org/getting-started#update. (PS : cela a été une simple formalité sous Windows, mais je n’ai pas testé la manip sous Linux) Ensuite, il suffit d’insérer la carte SD dans le port du BB et de remettre la carte sous tension. Si tout fonctionne bien, l’adresse beaglebone.local devrait être accessible. Si cela ne fonctionne pas, il vous faudra identifier l’adresse IP du BB en vous connectant à votre routeur. Une fois ceci fait, on confirme que l’on a bien la nouvelle image, en se connectant en SSH à la BB. (Vous pouvez utiliser Putty – https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html – si vous êtes sous Windows). Le login est « debian » et le password « temppwd ». Exécutez alors la commande : ---> CODE A AJOUTER CODE A AJOUTER <--- Linux beaglebone 4.9.45-ti-r57 #1 SMP PREEMPT Fri Aug 25 22:58:38 UTC 2017 armv7l GNU/Linux Voilà, Linux est à jour, on peut commencer (et je peux désormais revoir ma BB sur mon réseau). Voilà, Linux est à jour, on peut commencer (et je peux désormais revoir ma BB sur mon réseau).
  2. L’acquisition des signaux audios : Alors, je vais devoir faire simple car je n’ai qu’une partie de mon matériel avec moi. Je m’interfacerai directement avec la sortie audio d’un PC. Cependant, il faudra adapter la tension des signaux. Le convertisseur Numérique Analogique du BB ne permet d’acquérir des signaux ayant un maximum de 1.8V. Cette adaptation sera très basique, car elle se compose de quelques résistances et d’un transistor.
  3. Grâce à ce petit montage, nous avons désormais une : Charge de 33ohms, qui permet d’activer la sortie audio de certaines cartes sons, Une tension de sortie centrée autour de 0.7V compatible avec les entrées du Beagleboard.“ Pour ma part, tout a été assemblé sur une petit platine d’essais :
  4. Configuration des entrées Généralité sur les GPIO et E/S : En vous rendant sur la web de votre BB, vous trouverez l’allocation / description des GPIO (General Purpose Input/Output).
  5. Pour utiliser convenablement nos GPIOs (ainsi que les diverses entrées sorties), il va falloir configurer proprement celles-ci (est-ce une entrée, une sortie, utilisation des pull-up, ….). Il est à noter que la notion de GPIOs et de pin sont deux choses différentes (par exemple, GPIO 32 ne correspond pas à la pin 32 du processeur). D’autres part, il nous faut aussi identifier et configurer adéquatement les registres de configuration. Pour pouvoir retrouver les diverses informations, il va falloir être capable de convertir le numéro de GPIO, à un numéro d’adresse mémoire et à un numéro de pin. Cela va impliquer de naviguer entre différents documents. Le processeur du BB possède 128 pins organisées en 4 banques de 32 bits (de 0 à 3). Ainsi, les pins de 0 à 31 sont dans la banque 0, de 32 à 63 dans la banque 1,… Le GPIO 60, sera ainsi le 28 bits de la banque 1 (1*32+28), le GPIO 12, le 12ème de la banque 0… Avec ces informations, on peut retrouver l’offset à partir de divers documents : la documentation du processeur (sur le site de Texas Instruments – http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf, chapitre 25 pour plus d’explications sur les GPIO, et chapitre 9.3 pour avoir les informations sur les registres de configuration), ou pour se simplifier la vie, utiliser les documents proposés sur Github : https://github.com/derekmolloy/boneDeviceTree/tree/master/docs Ou celles disponibles dans le System Reference Manual (disponible sur le wiki http://elinux.org/Beagleboard:BeagleBoneBlack) Ou un générateur de fichier en ligne : http://www.kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator Ou enfin utiliser le site web de Texas instruments : https://dev.ti.com/pinmux/app.html#/default
  6. Gestion de la configuration des interfaces La configuration s’effectue au travers de fichiers spécifiques qui permettent de faire le lien entre la description physique du processeur et les besoins logiciels (device tree). Celle-ci est spécifiée dans des fichiers dts (device tree source). Ces fichiers doivent être compilés avec dtc (device tree compiler) afin de les rendre compréhensibles pour le noyau linux. Ces fichiers ont une extension dtb (device tree blob) ou dtbo.
  7. Chargement d’une configuration : Pour cela, on se connecte en SSH, puis on bascule en utilisateur root, via la commande « sudo su ». (Note : vous pouvez en profiter pour saisir un mot de passe root, en utilisant la commande « passwd », c’est recommandé notamment si votre BB est connecté continuellement au réseau). Cette configuration peut être chargée de différentes manières : Soit directement par le noyau lors du chargement. On parle alors de driver. Chaque modification entraine la nécessité de redémarrer le BB. Soit par l’utilisateur. On parle alors d’overlay. On peut, en principe, s’affranchir d’un redémarrage pour appliquer des modifications. Pour ce dernier cas, le fichier « /boot/uEnv.txt » permet de définir les configurations que l’on souhaite charger ou inhiber lors du démarrage. Mais vous pouvez tout autant charger une configuration « à la volée » en utilisant la commande suivante : ---> CODE A AJOUTER /sys/devices/platform/bone_capemgr/slots Vous pouvez consulter l’état des configurations chargées en réalisant la commande suivante : ---> CODE A AJOUTER <--- sudo cat /sys/devices/platform/bone_capemgr/slots Note 1 : slots permet d’afficher les informations relatives aux Cape (carte d’extension des BB). Ajouter des overlays sans Capes réelles, revient à créer des Capes « virtuelles ». Note 2 : par la suite, je considère que vous êtes en utilisateur root. Je n’indiquerai donc plus le mot clé sudo.
  8. Dans mon cas (après un BB réinitialisé) retourne les informations suivantes : ---> CODE A AJOUTER CODE A AJOUTER sys/devices/platform/bone_capemgr/slots Qui conduit à l’état suivant: ---> CODE A AJOUTER CODE A AJOUTER CODE A AJOUTER CODE A AJOUTER <--- group: pinmux_dcan1_pins pin 97 (PIN97) pin 96 (PIN96)
  9. Déchargement d’une configuration : Tout comme on peut installer des overlays, on peut également les retirer à chaud avec la commande suivante : ---> CODE A AJOUTER /sys/devices/platform/bone_capemgr/slots -------------------------------------------------------- Ainsi pour retirer l’overlay BB-CAN1, nous effectuons : ---> CODE A AJOUTER /sys/devices/platform/bone_capemgr/slots -------------------------------------------------------- Note : si vous êtes lassé d’écrire continuellement le chemin de slots, vous pouvez créer une variable d’environnement dans le fichier ~/.profile et ajouter les lignes suivantes : ---> CODE A AJOUTER CODE A AJOUTER <--- export PINS=/sys/kernel/debug/pinctrl/44e10800.pinmux/pins -------------------------------------------------------- Ainsi au lieu d’indiquer intégralement le chemin, vous n’aurez plus qu’à utiliser $SLOTS ou $PINS
  10. Le cas des entrées analogiques Les entrées analogiques ont un traitement à part car elles ne relèvent pas des GPIOs. L’activation repose sur les mêmes principes que ceux des GPIOs. Dans notre cas, la commande echo BB-ADC > /sys/devices/platform/bone_capemgr/slots On vérifie avec la commande lsmod que le module est bien chargé : lsmod | grep adc qui retourne (sous le format Module, Size, Used by) ti_am335x_adc 8160 0 kfifo_buf 4052 1 ti_am335x_adc industrialio 65843 2 ti_am335x_adc,kfifo_buf On lit les données en consultant le fichier (ne pas oublier que sous linux, tout est fichier) : cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw qui retournera une valeur entre 0 et 4095 (12 bits). Il faut savoir que l’accès par fichier reste lent. Il sera donc difficile (lire, impossible), d’échantillonner à une fréquence supérieure à 5 KHz. Pour obtenir une meilleur fréquence, il faudra accéder directement en mémoire. Enfin, il ne faut pas oublier, que les entrées analogiques sont multiplexées. On ne pourra jamais lire toutes les entrées simultanément à une très haute fréquence.
  11. Le cas des entrées analogiques Les entrées analogiques ont un traitement à part car elles ne relèvent pas des GPIOs. L’activation repose sur les mêmes principes que ceux des GPIOs. Dans notre cas, la commande echo BB-ADC > /sys/devices/platform/bone_capemgr/slots On vérifie avec la commande lsmod que le module est bien chargé : lsmod | grep adc qui retourne (sous le format Module, Size, Used by) ti_am335x_adc 8160 0 kfifo_buf 4052 1 ti_am335x_adc industrialio 65843 2 ti_am335x_adc,kfifo_buf On lit les données en consultant le fichier (ne pas oublier que sous linux, tout est fichier) : cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw qui retournera une valeur entre 0 et 4095 (12 bits). Il faut savoir que l’accès par fichier reste lent. Il sera donc difficile (lire, impossible), d’échantillonner à une fréquence supérieure à 5 KHz. Pour obtenir une meilleur fréquence, il faudra accéder directement en mémoire. Enfin, il ne faut pas oublier, que les entrées analogiques sont multiplexées. On ne pourra jamais lire toutes les entrées simultanément à une très haute fréquence. Le fichier Overlay La commande echo BB-ADC > /sys/devices/platform/bone_capemgr/slots active toutes les entrées analogiques. Toutefois, dans le cadre du projet, l’activation de toutes les entrées analogiques n’est pas une nécessité. De ce fait, on va étudier plus spécifique un fichier overlay afin d’activer uniquement les entrées nécessaires. La structure d’un fichier Overlay se compose de ces informations de base /dts-v1/; /plugin/; / { compatible = "ti,beaglebone", "ti,beaglebone-black"; /* identification */ part-number = "EBB-ADC"; version = "00A0"; exclusive-use = xxxxxxxx fragment@0 { target = ; __overlay__ { status = "okay"; …… }; }; fragment@n...... }; De manière basique, un fichier overlay se compose : D’entêtes génériques; Du champ “compatible” De paramètres d’identification (part-number et version) D’une liste de pins et d’hardware, D’une liste de fragments Le champ Compatible indique le matériel cible, dans notre cas, on cible le Beaglebone et le Beaglebone-black (qui est au niveau hardware quasiment identique au Beaglebone-green). Les paramètres part-number et version peuvent être fixée librement. La version initiale est généralement la version 00A0. En ce qui concerne le part-number, j’ai coutume de faire commencer les overlay crées personnellement par un ‘P’, afin d’indiquer leur origine. Le champ exclusive-use est utilisé dans le cadre des Capes. Il permet de réserver des pins du Beagleboard. Il est possible d’avoir jusqu’à 4 Capes sur un BB. De ce fait, il est possible que certains pins soient allouées simultanément à des fonctions différentes (par exemple un bus spi pour une Cape, alors que la même pin pourrait être allouée à un bus I2C d’une autre Cape.). Le champ exclusive-use va permettre de s’assurer que deux capes différentes n’accèdent pas à des pins identiques pour des fonctions différentes. Il est également possible d’indiquer des bus ou des fonctions spécifiques (telles que I2C, SPI,…). Pour identifier les valeurs possibles (nommées phandle), le mieux est de lire le fichier /opt/source/dtb-4.9-ti/src/arm/am33xx.dtsi, car celui-ci contient la définition physique de la carte. Les valeurs généralement utilisées sont : uart1, uart2, uart4 et uart5, i2c1, i2c2 spi0 et spi1 tscadc (pour les adc)… On retrouve également ces informations sur la première partie du nom des headers (voir http://elinux.org/Beagleboard:Cape_Expansion_Headers) Les fragments détails les informations de manières plus spécifiques, en définissant notamment les options de multiplexage (cas des GPIOs notamment) ou en ciblant des ports particuliers. Le champs target reprend les valeurs qui ont été réservées précédemment, à savoir uart1, uart2,spi0,… tscadc ainsi que am33xx_pinmux (cas des GPIOs). Cette valeur est inscrite entre . ( par exemple target = ; ) La partie __overlay__ est celle qui nous intéresse le plus, car c’est ici que sera réellement appliquées la configuration. La valeur status = “okay” ou « ok »; est générique, mais il peut être mis à « disabled » pour inactiver la configuration (une valeur « fail » est également possible). Du fait qu’il peut être un peu délicat de mettre en place le fichier Overlay, le mieux est d’utiliser un générateur (comme celui disponible sur http://www.kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator). Ces générateurs facilite énormément la configuration, et il serait dommage de s’en priver.
  12. Le cas des entrées analogiques Les entrées analogiques ont un traitement à part car elles ne relèvent pas des GPIOs. L’activation repose sur les mêmes principes que ceux des GPIOs. Dans notre cas, la commande ---> CODE A AJOUTER /sys/devices/platform/bone_capemgr/slots On vérifie avec la commande lsmod que le module est bien chargé : ---> CODE A AJOUTER CODE A AJOUTER CODE A AJOUTER /sys/devices/platform/bone_capemgr/slots active toutes les entrées analogiques. Toutefois, dans le cadre du projet, l’activation de toutes les entrées analogiques n’est pas une nécessité. De ce fait, on va étudier plus spécifique un fichier overlay afin d’activer uniquement les entrées nécessaires. La structure d’un fichier Overlay se compose de ces informations de base ---> CODE A AJOUTER <--- /dts-v1/; /plugin/; / { compatible = "ti,beaglebone", "ti,beaglebone-black"; /* identification */ part-number = "EBB-ADC"; version = "00A0"; exclusive-use = xxxxxxxx fragment@0 { target = ; __overlay__ { status = "okay"; …… }; }; fragment@n...... }; ------------- De manière basique, un fichier overlay se compose : D’entêtes génériques; Du champ “compatible” De paramètres d’identification (part-number et version) D’une liste de pins et d’hardware, D’une liste de fragments Le champ Compatible indique le matériel cible, dans notre cas, on cible le Beaglebone et le Beaglebone-black (qui est au niveau hardware quasiment identique au Beaglebone-green). Les paramètres part-number et version peuvent être fixée librement. La version initiale est généralement la version 00A0. En ce qui concerne le part-number, j’ai coutume de faire commencer les overlay crées personnellement par un ‘P’, afin d’indiquer leur origine. Le champ exclusive-use est utilisé dans le cadre des Capes. Il permet de réserver des pins du Beagleboard. Il est possible d’avoir jusqu’à 4 Capes sur un BB. De ce fait, il est possible que certains pins soient allouées simultanément à des fonctions différentes (par exemple un bus spi pour une Cape, alors que la même pin pourrait être allouée à un bus I2C d’une autre Cape.). Le champ exclusive-use va permettre de s’assurer que deux capes différentes n’accèdent pas à des pins identiques pour des fonctions différentes. Il est également possible d’indiquer des bus ou des fonctions spécifiques (telles que I2C, SPI,…). Pour identifier les valeurs possibles (nommées phandle), le mieux est de lire le fichier /opt/source/dtb-4.9-ti/src/arm/am33xx.dtsi, car celui-ci contient la définition physique de la carte. Les valeurs généralement utilisées sont : uart1, uart2, uart4 et uart5, i2c1, i2c2 spi0 et spi1 tscadc (pour les adc)… On retrouve également ces informations sur la première partie du nom des headers (voir http://elinux.org/Beagleboard:Cape_Expansion_Headers) Les fragments détails les informations de manières plus spécifiques, en définissant notamment les options de multiplexage (cas des GPIOs notamment) ou en ciblant des ports particuliers. Le champs target reprend les valeurs qui ont été réservées précédemment, à savoir uart1, uart2,spi0,… tscadc ainsi que am33xx_pinmux (cas des GPIOs). Cette valeur est inscrite entre . ( par exemple target = ; ) La partie __overlay__ est celle qui nous intéresse le plus, car c’est ici que sera réellement appliquées la configuration. La valeur status = “okay” ou « ok »; est générique, mais il peut être mis à « disabled » pour inactiver la configuration (une valeur « fail » est également possible). Du fait qu’il peut être un peu délicat de mettre en place le fichier Overlay, le mieux est d’utiliser un générateur (comme celui disponible sur http://www.kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator). Ces générateurs facilite énormément la configuration, et il serait dommage de s’en priver. L’activation des entrées analogiques dans le fichier overlay Dans le cadre du projet, le fichier overlay sera simple car nous n’allons utiliser uniquement des entrées analogiques. Il faut savoir que celles-ci sont associées aux fonctions de contrôles de touchscreeen (tsc). Pour nous aider dans cette démarche, le mieux est de consulter la documentation du kernel : https://www.kernel.org/doc/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt, ou plus spécifiquement pour le beaglebone : https://github.com/beagleboard/linux/blob/master/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.tx ---> CODE A AJOUTER <--- /dts-v1/; /plugin/; / { compatible = "ti,beaglebone", "ti,beaglebone-black"; /* identification */ part-number = "PBB-ADC"; version = "00A0"; // resources this cape uses exclusive-use = "P9.39", // AIN0 "P9.40", // AIN1 "P9.37", // AIN2 "tscadc"; // hardware ip used, pas obligatoire sauf si on veut se réserver intégralement l’usage fragment@0 { target = ; __overlay__ { #address-cells = ; #size-cells = ; status = "okay"; adc { ti,adc-channels = ; //Les capacités de filtrages, sampling etc ne sont pas utilisées dans //le cadre du projet. //Voir documentation sur https://github.com/beagleboard/linux/blob/master/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt //ti,chan-step-avg = ; //ti,chan-step-opendelay = ; //ti,chan-step-sampledelay = ; }; }; }; }; Il reste à sauver le fichier avec l’extension .dts (pour ma part, je nomme le fichier part-number–version.dts, soit ici PBB-ADC-00A0.dts, mais un autre format est acceptable). Il nous reste à compiler le fichier avec la commande : ---> CODE A AJOUTER CODE A AJOUTER CODE A AJOUTER CODE A AJOUTER /sys/devices/platform/bone_capemgr/slots Désormais, nous devrions retrouver les informations des ports analogiques dans le répertoire ---> CODE A AJOUTER CODE A AJOUTER <---cat /sys/bus/iio/devices/iio\:device0\in_voltage0_raw
  13. Développement Nous accédons désormais aux ports analogiques et nous pouvons les utiliser simplement dans un programme C. Pour cela, nous utiliserons la commande ---> CODE A AJOUTER <--- open("/sys/bus/iio/devices/iio:device0/in_voltage0_raw",O_RDONLY); Pour des fréquences faibles (environ 1kHz), le temps d’accès aux ports analogiques ne posera pas de soucis particulier. L’ambition du projet est de décoder des signaux morses. Pour cela j’ai pris comme référence les signaux d’identification des balises de navigation aéronautique (VOR, NDB,…). Les signaux morses sont codées avec une fréquence à 1020Hz +/-50Hz. Note : L’ensemble des spécifications des signaux de navigations sont disponibles dans un document (Annexe 10) de l’OACI (Organisation Aviation Civile Internationale). Le document disponible sur http://www.simphonics.com/supp/downloads/docs/techNotes/Navigational%20Aids%20Audio%20Characteristics.pdf permet cependant d’avoir une bonne vision de l’ensemble. Afin d’effectuer la détection de « . », des « – » et des silences, j’utiliserai l’algorithme de Goertzel qui simplifiera le codage et réduira l’utilisation processeur (nul besoin d’avoir une analyse de Fourrier). Plus d’informations sur cet algorithme sont disponibles sur https://www.embedded.com/design/configurable-systems/4024443/The-Goertzel-Algorithm
  14. La compilation du code sera effectué en cross compilation (faire lien vers précédent tuto), mais une compilation en utilisation les ressources du BB est également possible. Le code se compose d’un fichier c (bot.c), d’un fichier h (bot.h). Pourquoi bot ? peuvent se demander certains. Il s’agit simplement d’une référence à la balise BOT qui a servi au développement. Dans le fichier bot.c : Calculs des coefficients initiaux de l’algorithme de Goertzel. Boucle principale (infinie) : Lecture du port analogique Application d’un filtre passe bas Application de l’algorithme de Goertzel pour détecter les emissions Traitement des silences, beep,… Affichage du message décodé Le fichier bot.h contient la définition des codes morses.
  15. Une fois la compilation effectuée, on test, en connectant la sortie du montage à l’entrée AN0 et en raccordant les masses :
  16. Et il reste à regarder le message décodé
Rating: 4.5. From 1 vote.
Please wait...
Réalisé par
Posté le
Univers
Programmation
Temps de fabrication
1h
Niveau de difficulté
Avancé

Aucun commentaire. Soyez le premier à en écrire un !

Vous devez être connecté pour laisser un commentaire.