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 :




    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 :



    /sys/devices/platform/bone_capemgr/slots




    Vous pouvez consulter l’état des configurations chargées en réalisant la commande suivante :




    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 :


    sys/devices/platform/bone_capemgr/slots




    Qui conduit à l’état suivant:




    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 :


    /sys/devices/platform/bone_capemgr/slots




    Ainsi pour retirer l’overlay BB-CAN1, nous effectuons :

    /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 :

    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 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. 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

    /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 :

    dtc -O dtb -o PBB-ADC-00A0.dtbo -b 0 -@ PBB-ADC-00A0.dts

    Dans mon cas, j’ai eu le message d’erreur

    Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property


    La commande suivante permet d’ignorer ce message:

    dtc -W no-unit_address_vs_reg -O dtb -o PBB_ADC-00A0.dtbo -b 0 -@ PBB-ADC-00A0.dts

    Une fois le fichier compilé, il reste à le copier dans le répertoire /lib/firmware :

    cp PBB_ADC-00A0.dtbo /lib/firmware/

    et d’activer l’overlay

    sudo echo "PBB_ADC" > /sys/devices/platform/bone_capemgr/slots

    Désormais, nous devrions retrouver les informations des ports analogiques dans le répertoire

    ls /sys/bus/iio/devices/iio\:device0


    buffer in_voltage0_raw in_voltage2_raw of_node scan_elements uevent
    dev in_voltage1_raw name power subsystem

    Pour consulter la valeur lue :

    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

    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



    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.
  14. Une fois la compilation effectuée, on test, en connectant la sortie du montage à l’entrée AN0 et en raccordant les masses.
  15. Et il reste à regarder le message décodé.
Rating: 2.7/5. From 3 votes.

Connectez-vous pour voter
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.