Catégorie : BeagleBone Black

Les entrées analogiques de la Beaglebone Black, ARM et PRUs

L’objectif ici est de compiler et d’exécuter un programme permettant de lire une tension sur des pins analogiques. Deux programmes, en fait, l’un côté PRU (Programmable Real-time Unit) et l’autre côte CPU ARM. Finalement, j’ai opté pour les exemples fournis par Texas Instruments, qui est le constructeur du « cœur » (SoC AM3358/9) de la BBB. Au départ, je ne saisissais pas bien comment lancer les programmes fournis par TI, ni l’intérêt exact du SDK. J’ai en plus installé leur « Code Composer Studio » sur ma bécane (CCS), qui prend moultes Giga et est bien complexe. Je vais probablement le désinstaller.
Grâce au projet BeagleScope, dont je parle dans mon précédant post,  en étudiant le fichier deplay.sh, j’ai compris comment lancer un programme (dans le firmware) sur l’un des deux micro-contrôleurs (les fameux PRUs).

Le premier exemple, dans le post précédent, consistait à faire clignoter une LED à partir d’un pin numérique configuré en « output ». Maintenant, nous allons construire et exécuter un projet, nommé « PRU_ADC_onChip » qui  a pour objectif de lire des valeurs sur des pins analogiques (ADC = Analog to Digital Converter) et de les convertir en Volts en fonction d’une tension de référence. Les ADC de la BBB ont 12 bits de résolution et prennent donc des valeurs entre 0 et 4096-1 (4096 = 2 puissance 12). La tension de référence pour les convertisseurs est de 1.8 V, au lieu des 3.3 V pour pour les pins numériques. ATTENTION, ne pas mettre une tension supérieure à 1.8 V au risque d’endommager laBeagleBone! La tension de référence est fournie sur le pin P9_32 (VDD_ADC) et une terre analogique sur le pin P9_34 (GROUNDA_ADC). Vraiment, faite attention de ne pas mettre une tension supérieure à 1.8 V dans les entrées analogiques, please!!!
Les pins d’entrée analogique, sur le header P9, sont numérotées de AIN0 à AIN6 (7 entrées), pins 33 et 35 à 40, le pin 34 étant la terre et le pin 32 étant la référence à 1.8 V.  Les entrées analogiques sont surlignées en vert dans la figure ci-dessous:

Une vidéo illustrant le « projet », dans ses grandes lignes, est disponible ici : How to Use the PRU to Control a Peripheral: PRU_ADC_onChip on Sitara 335x using Beaglebone Black. C’est une bonne idée de la regarder cette vidéo, elle ne dure que 10 minutes (si l’Anglais ne vous rebute pas).

Les explications dans ce post sont certainement transposables à d’autres BeagleBones (Green, Blue), moyennant quelques adaptations.
Note: la résolution est ici de 12 bits, contre 10 bits pour l’Arduino Uno. La résolution standard d’un fichier audio est de 16 bits (signé).
Du coup, cela signifie que le pas de quantification est de 1.8 V divisé par (2 puissance 12, moins 1), soit 0.440 mV environ!

Résumé avec la vidéo TI (traduction) :

Dans certaines situations, il est plus logique de contrôler un périphérique avec un processeur déterministe dédié plutôt qu’avec un cœur ARM à usage général dans un processeur TI. Les applications vont d’un système de surveillance dédié où la charge de traitement peut être déchargée de l’ARM à un environnement en temps réel où le stimulus nécessite une réponse du processeur dans un laps de temps connu. Cette vidéo fournit un exemple d’utilisation du noyau d’unité programmable en temps réel (PRU) pour contrôler un périphérique sur n’importe quel processeur TI avec un PRU-ICSS ou PRU_ICSSG. Dans ce cas, pour contrôler le convertisseur analogique-numérique (ADC) sur le processeur Sitara AM335x à l’aide du BeagleBone Black.

Sur le projet PRU_ADC_onChip :

Il s’agit d’un projet de référence pour l’utilisation du PRU-ICSS pour contrôler un périphérique ADC sur l’AM335x. Le but de ce projet est de fournir un modèle pour contrôler un périphérique sur puce à l’aide du PRU. Il démontre également une application de RPMsg pour la communication ARM-PRU.

Nous allons passer aux choses sérieuses, à savoir la compilation des deux codes, l’un sur la BBB pour le PRU et l’autre sur votre PC sous Linux pour le processeur ARM de la BBB.

La première étape consiste à modifier le fichier /boot/uEnv.txt, puis rebooter.
Dans ce fichier de configuration, il faut dé-commenter la ligne suivante :
disable_uboot_overlay_adc=1, afin d’empêcher le processeur ARM d’accéder à la conversion analogique numérique ADC, car ce sera la tâche du micro-contrôleur.
Re-booter :
sudo reboot now

La seconde étape: le projet fait partie du pru-software-support-package fourni par Texas Instruments (TI) et téléchargeable ici pru-software-support-package. Il est souhaitable de le télécharger sur votre PC, puis de le copier sur votre BBB :
scp pru-software-support-package-5.6.0.zip debian@beaglebone.home:/home/debian/
Sur les deux ordinateurs (PC et BBB), le décompresser :
unzip pru-software-support-package-5.6.0.zip
Le projet s’appelle PRU_ADC_onChip et se trouve dans le répertoire :  pru-software-support-package-5.6.0/examples/am335x/PRU_ADC_onChip.

La troisième étape (1/2) : installation du SDK sur le PC pour la compilation croisée.
On trouve le SDK de TI depuis PROCESSOR-SDK-AM335X, c’est un très gros fichier  « ti-processor-sdk-linux-am335x-evm-06.03.00.106-Linux-x86-Install.bin » (9.2 Go après installation, sur mon PC) . Une fois téléchargé, il faut l’exécuter pour installer le SDK :
chmod u+x ti-processor-sdk-linux-am335x-evm-06.03.00.106-Linux-x86-Install.bin
./ti-processor-sdk-linux-am335x-evm-06.03.00.106-Linux-x86-Install.bin


La troisième étape (2/2) : la compilation croisée (cross-compilation)
Il s’agit de compiler le programme depuis le PC (processeur x86) pour le processeur ARM de la BeagleBone, sur lequel il sera exécuté.
Le code source est dans le fichier pru_adc_userspace.c, qui se trouve dans le sous répertoire PRU_ADC_onChip/pru_adc_userspace
Attention, celui-ci doit être compilé sur votre PC.
Ce n’est pas indiqué explicitement dans le README.txt, mais c’est nécessaire.
Faire l’export suivant pour le dossier bin du SDK :
export ARM_CCT=/home/benaroya/ti-processor-sdk-linux-am335x-evm-06.01.00.08/linux-devkit/sysroots/x86_64-arago-linux/usr/bin
en remplaçant « /home/benaroya » par votre répertoire racine contenant le SDK
Dans le répertoire PRU_ADC_onChip/pru_adc_userspace, on compile :
make clean
make

Enfin, il ne reste plus qu’à recopier le dossier généré « gen » vers l’exemple sur la BeagleBone
scp -r gen debian@beaglebone.home:/home/debian/pru-software-support-package-5.6.0/examples/am335x/PRU_ADC_onChip/pru_adc_userspace/

La quatrième étape : compilation pour le PRU 0 sur la BBB.
dans PRU_ADC_onChip, compiler pru_adc_firmware.c dans la beaglebone :
export PRU_CGT=/usr/share/ti/cgt-pru
make clean
make
Vous pouvez insérer l’export dans ~/.bashrc, pour ne plus le faire à chaque connexion à la BBB.

La cinquième étape : démarrer le PRU.
Comme indiqué dans le post précédent, il faut mettre le code pour le PRU 0 dans le firmware et lancer le remoteproc0. Il y a une erreur dans le programme fourni par TI parce que  pru_adc_userspace.c essayez de lancer automatiquement PRU 1, alors que le programme « pru_adc_firmware.c » est compilé avec des options pour le PRU 0. ça n’a pas fonctionné en l’état chez moi.

Dans pru_adc_firmware.c :
/*
* The PRU-ICSS system events used for RPMsg are defined in the Linux devicetree
* PRU0 uses system event 16 (To ARM) and 17 (From ARM)
* PRU1 uses system event 18 (To ARM) and 19 (From ARM)
*/
#define TO_ARM_HOST 16
#define FROM_ARM_HOST 17

Dans pru_adc_userspace.c :
char firmware[] = "/sys/class/remoteproc/remoteproc1/firmware";
char pruState[] = "/sys/class/remoteproc/remoteproc1/state";
Remplacer remoteproc1 par remoteproc0 ne suffit pas bizarrement.

On revient à nos moutons: renommer et copier le code compilé dans le firmware,
cp PRU_ADC_onChip.out PRU_ADC_onChip-fw
sudo cp PRU_ADC_onChip-fw /lib/firmware/

et démarrer le programme sur le PRU 0
echo 'stop' > /sys/class/remoteproc/remoteproc0/state 2>/dev/null
echo "PRU_ADC_onChip-fw" > /sys/class/remoteproc/remoteproc0/firmware
echo 'start' > /sys/class/remoteproc/remoteproc0/state

Dernière étape : tester
./gen/pru_adc_userspace -c 5
Reading voltage at ADC Channel: 5
Voltage on ADC Channel 5 is 1.7960V
./gen/pru_adc_userspace -c 6
Reading voltage at ADC Channel: 6
Voltage on ADC Channel 6 is 0.9270V
./gen/pru_adc_userspace -c 7
Reading voltage at ADC Channel: 7
Voltage on ADC Channel 7 is 0.0501V

C’est magnifique, car physiquement, le pin AIN4 (canal 5) est rélié à l’analog VDD (1.8 V), le pin AIN5 (canal 6) est « au milieu » (pont résistif de 2k Ohms) et le pin AIN6 (canal 7) est à la masse. Cependant, c’est un peu fluctuant au cours du temps. Apparemment, il y a moyen de moyenner la mesure:
/*
* set the ADC_TSC STEPCONFIG1 register for channel 5
* Mode = 0; SW enabled, one-shot
* Averaging = 0x3; 8 sample average
* SEL_INP_SWC_3_0 = 0x4 = Channel 5
* SEL_INM_SWC_3_0 = 1xxx = VREFN (reduces noise in single ended mode)
* use FIFO0
*/
ADC_TSC.STEPCONFIG1_bit.MODE = 0;
ADC_TSC.STEPCONFIG1_bit.AVERAGING = 3;
ADC_TSC.STEPCONFIG1_bit.SEL_INP_SWC_3_0 = 4;
ADC_TSC.STEPCONFIG1_bit.SEL_INM_SWC_3_0 = 8;
ADC_TSC.STEPCONFIG1_bit.FIFO_SELECT = 0;

Discussion générale :
Nous avons compilé et testé ce projet pour la lecture d’une entrée analogique. Il est composé de deux codes, l’un pour le PRU 0 qui va lire une valeur sur un pin analogique. Cette partie du code est assez lisible. Ensuite, cette valeur (échantillonnée sur 12 bits) est envoyée au micro-processeur ARM. La communication entre PRU et ARM est assurée par le framework RPMsg (Remote Processor Messaging, voir peut-être ici). Ne connaissant pas ce framework, je vais me rencarder sur ce Graal.
Enfin, le second code, compilé sur mon PC , est exécuté sur la BBB par l’ARM. Celui-ci envoie une requête avec le numéro du canal et reçoit en retour la valeur mesurée. Enfin, celle-ci est convertie en Volts et affichée.

Conclusion :
Nous avons abordé, entre autres, le téléchargement du « pru-software-support-package » de Texas Instruments, l’installation du SDK sur le PC, la compilation des deux codes, l’activation du PRU et enfin nous avons fourni de bons résultats de l’exécution du programme sur ARM.
A noter que le PRU lit une seule valeur sur l’ADC  (one-shot). Il serait intéressant de lire des valeurs à intervalles réguliers et de les renvoyer à l’ARM. Aussi comprendre la communication entre PRU et ARM avec le RPMsg.

Et Voilà !!!

Programmer les « Programmable Real-time Units » de la BeagleBone Black (PRUs)

Dans ce post, on va apprendre à faire clignoter une LED avec le microcontrôleur PRU 0 (il y en a deux). L’objectif est d’apprendre à lancer un programme en C dans le micro-contrôleur. Après on peut modifier le programme pour faire un tas d’autres choses. C’est une base.
PRU signifie « Programmable Real-time Unit ».

J’ai perso eu du mal à démarrer avec les PRUs dans ma BeagleBone Black . Beaucoup de documents sur le net. Mais beaucoup utilisent les « tree obverlays » et les slots qui eux n’existent plus dans les versions récentes de la BBB. J’ai fini par faire clignoter ma LED après trois soirées de boulot. C’est frustrant, mais maintenant j’ai à peu près compris la logique. C’est ce que j’expose ici, en espèrant que ça vous sera utile!

Mon approche est basée sur Remoteproc, qui signifie « remote processor », c-a-d processeur distant. C’est une approche, récente, pour programmer les PRUs. Il y en a trois: remoteproc0, remoteproc1, remoteproc2. Comme on le voit ci-dessous, remoteproc2 est occupé. Les deux autres sont utilisables et correspondent aux PRU 0 et 1.

Pour bien commencer, lancer une connexion ssh dans un terminal
ssh debian@beaglebone.home

Dans le log au démarrage:
dmesg | tail -100
[ 11.957862] remoteproc remoteproc0: 4a334000.pru is available
[ 11.958057] pru-rproc 4a334000.pru: PRU rproc node pru@4a334000 probed successfully
[ 11.973707] remoteproc remoteproc1: 4a338000.pru is available
[ 11.973893] pru-rproc 4a338000.pru: PRU rproc node pru@4a338000 probed successfully

[ 61.264026] remoteproc remoteproc2: wkup_m3 is available
[ 61.271194] remoteproc remoteproc2: powering up wkup_m3
[ 61.271222] remoteproc remoteproc2: Booting fw image am335x-pm-firmware.elf, size 217168
[ 61.275721] remoteproc remoteproc2: remote processor wkup_m3 is now up

Editer et Modifier/boot/uEnv.txt pour désactiver la fonction HDMI.
###Disable auto loading of virtual capes (emmc/video/wireless/adc).
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
Puis re-démarrer: sudo reboot now
Attention, c’est utile (uniquement) si on doit utiliser les pins du header P8 qui sont partagés avec l’HDMI. Voir les liens vers des tableaux « PinMux modes » en fin de post.

Information sur ma configuration :
ma disto
cat /etc/dogtag
BeagleBoard.org Debian Buster IoT Image 2020-04-06
cat /etc/debian_version
10.3
uname -a
Linux beaglebone 4.19.94-ti-r42 #1buster SMP PREEMPT Tue Mar 31 19:38:29 UTC 2020 armv7l GNU/Linux

Commençons les choses sérieuses

Télécharger BeagleScope (licence GPL v2), qui nous fourni les includes et libs pour pouvoir compiler et faire l’édition de lien, avec le Makefile.
git clone https://github.com/ZeekHuge/BeagleScope.git
si besoin, installer git : sudo apt-get install git
cd BeagleScope/
cd examples/firmware_exmples/pru_blinky/
Il y a des erreurs dans deploy.sh, on va faire le boulot en ligne de commande.
cd PRU_gpioToggle

Remplacer le fichier PRU_gpioToggle.c par celui sur ma page perso (avec wget, ci-dessous). Le code active le pin 27 du P9 (pin P9_27).
mv PRU_gpioToggle.c PRU_gpioToggle.c.old
wget elaurent.benaroya.free.fr/wordpress/BBB/PRU_gpioToggle.c
Vous pouvez (devez) éditer ce code. Ce qui est à retenir :

Le registre R30 est utilisé pour mettre à l’état haut ou l’état bas un pin configuré en sortie (pruout).
C’est un registre 32 bits.
On met alternativement le bit numéro 5 à 1 (état haut) et à 0 (état bas).
Le bit 5 du registre R30 correspond physiquement à P9_27.
Après avoir changé la valeur du bit 5 dans R30, on attend avec la fonction __delay_cycles pendant 100 millions de cycles, soit 1/2 secondes car le micro-controlleur fonctionne à 200 MHz.
Enfin, on boucle 60*5 fois, c’est dire pendant 5 minutes.
Ensuite, la commande __halt(); arrête le processus.

Attention, l’inclusion du fichier resource_table_empty.h est importante bien que celui-ci ne fasse pas grand chose.
Note importante : le code que je fournis est adapté de celui : beaglebone-pru-c

Compilation

1) d’abord définir la variable d’environnement PRU_CGT:
Créer les liens symboliques, à ne faire qu’une seule fois!
sudo ln -s /usr/bin/clpru /usr/share/ti/cgt-pru/bin/clpru
sudo ln -s /usr/bin/lnkpru /usr/share/ti/cgt-pru/bin/lnkpr
Puis :
export PRU_CGT=/usr/share/ti/cgt-pru
L’export peut être placé dans votre ~/.bashrc pour ne pas avoir à s’en occuper à chaque connexion au BBB.

2) Compiler
make clean
make

3) Copier le binaire dans le firmware
cd gen
cp PRU_gpioToggle.out gpiotoggle-fw
sudo cp gpiotoggle-fw /lib/firmware
Note importante : dans les versions « anciennes » du système d’exploitation, le nom du programme chargé dans le firmware est fixé : « am335x-pru0-fw » pour le PRU0 et « am335x-pru1-fw » pour le PRU1. Il faut donc remplacer la commande ci-dessous par :
cd gen
cp PRU_gpioToggle.out am335x-pru0-fw
sudo cp am335x-pru0-fw /lib/firmware

Le schéma électronique consiste à placer une LED et une résistance de 500 ohms environ, en série, entre P9_27 et P9_1 (DGND, digital ground).
Utiliser une LED jaune, rouge ou orange du fait de la chute de tension (entre 2 et 2.8 V contre 3.2 V au moins pour une bleue), sachant que la tension de sortie des gpio est de 3.3V!

Avec un résistance de 500 ohms, on obtient environ un courant de (3.3-2.3)/500 = 2 mA. C’est acceptable. Attention, le courant maximum délivré par chaque pin du gpio est de l’ordre de 4 mA à 8 mA, selon le pin : voir discussion dans GPIO current capacity?. C’est beaucoup moins qu’un Arduino, attention!!!

Configurer le pin P9_27 en sortie digitale (pruout)
config-pin

GPIO Pin Configurator
Usage:
   config-pin -c <filename>
   config-pin -l <pin>
   config-pin -q <pin>
   config-pin <pin> <mode>

config-pin -l P9.27
Available modes for P9_27 are: default gpio gpio_pu gpio_pd gpio_input qep pruout pruin
config-pin -q P9.27
Current mode for P9_27 is: default
config-pin P9.27 pruout
Current mode for P9_27 is: pruout

Lancer le programme sur le PRU0 (remoteproc0)
echo 'stop' > /sys/class/remoteproc/remoteproc0/state 2>/dev/null
echo "gpiotoggle-fw" > /sys/class/remoteproc/remoteproc0/firmware
echo 'start' > /sys/class/remoteproc/remoteproc0/state
La LED devrait se mettre à clignoter pendant 5 minutes.
Pour vérifier que les trois commandes ci-dessus se sont bien passées, on peut faire un dmesg. Si erreurs, problème!
dmesg | tail
[ 3105.812064] remoteproc remoteproc0: powering up 4a334000.pru
[ 3105.812358] remoteproc remoteproc0: Booting fw image gpiotoggle-fw, size 33556
[ 3105.812391] remoteproc remoteproc0: remote processor 4a334000.pru is now up
Note : comme indiqué ci-dessus, dans les versions plus anciennes de l’OS, le nom du programme dans le firmware est fixé,  la commande convenable est donc :
echo "am335x-pru0-fw" > /sys/class/remoteproc/remoteproc0/firmware

Approfondissement et liens externes

Pour le plaisir de mettre une image des headers P8 et P9 (c’est vendeur) :

Beaglebone Black Headers PinMux Modes

Les tableaux PinMux modes pour les headers P8 et P9
Celui-ci est très bien BeagleboneBlackPinMuxModes et les versions imprimables en pdf: P8 : P8 headers pdf et P9 : P9 headers pdf.
Dans la table du header P9, on a

P9 pin Offset mode 5 mode 6
P9_27 0x9A4 pr1_pru0_pru_r30_5 pr1_pru0_pru_r31_5

Dans cet extrait de la table, le pin 27 du header P9 correspond à pr1_pru0_pru_r30_5, qui indique le PRU 0, le registre 30 (output) sur le bit no 5.
Le mode 6, c’est la même chose mais en input, sur le registre R31. J’écris le bit no 5 parce que la numérotation des bits dans un nombre, en binaire, commence à 0. Donc le pin no 5 à 1 correspond à 0b0010_0000 en écriture binaire (sur 8 bits). En langage C, ce nombre peut s’écire 1 << 5 .

Voici un autre tableau équivalent, avec stabilotage : P9 headers.

Les pins GPIO pour la BeagleBone Black physiquement : The BeagleBone Black GPIO Pins ou gpio très complet (les figures en bas de la page).

Programmation des PRUs en C

Technique et bas niveau, mais vraiment intéressant, codage en C pour les PRUs : Beaglebone PRU Code in C

Sur les Remoteproc Remoteproc wiki

Super projet, proche de ce que je veux faire et qui a pour but d’acquérir de l’audio par le PRU, en temps réel, et de le transmettre au CPU qui le traite ou le joue : Using the Beaglebone Green Programmable Real-Time Unit with the RemoteProc and Remote Messaging Framework to Capture and Play Data from an ADC, lien parent du repo github.

Note sur le temps-réel

Il est important de comprendre que les PRUs permettent des traitements temps réel, car ce sont des micro-controlleurs dont on maîtrise totalement le fonctionnement en particulier celui des interruptions. Les versions « standards » de Linux ne permettent pas le temps réel parce qu’il peut se passer plein de trucs externes pendant l’exécution d’un programme. Il ne faut pas confondre temps réel et faible latence. Temps réel signifie qu’on peut prédire le temps d’excution d’un programme – de manière déterministe – indépendemment de la latence.

L’incontournable zeekhuge

Ce lien suivant est assez proche ce que j’ai exposé : l’application « blinky » : ptp_blinky. C’est assez complémentaire en fait.
Concernant les PRUs en général : working_with_prus_beagleboneblack_introduction_to_prus.

Conclusion

Dans ce post, j’ai exposé en détail comment compiler et exécuter un programme sur une « Programmable Real-time Unit » (PRU) de la BeagleBone Black. Le programme fait simplement clignoter une LED. J’espère que cette introduction à la programmation des PRUs vous sera utile et surtout vous donnera envie de réaliser des applications plus complexes, utilisant le SPI ou l’ADC par exemple, ou encore les timers.

ET Voilà!!!

Bien démarrer avec la BeagleBone Black Wireless (BBBw)

Voici quelques tips pour bien démarrer avec la BeagleBone Black Wireless. J’ai acheté ce petit bijou de technologie il y a peu et je partage avec vous mes premiers pas.
La BBB Wireless suppose des manips légèrement différentes pour la prise en main, par rapport à la BeagleBone Black. Il y a beaucoup en commun cela dit. Voici un guide pas à pas des étapes pour démarrer avec votre BeagleBone Black Wireless et la configurer. Après c’est à vous de jouer!

Les premiers pas, décrits dans la page getting-started de BeagleBoard.org sont les suivants:

Télécharger la dernière version de la distribution Debian de Linux sur la page latest-images.
– avec interface graphique (LXQT) https://debian.beagleboard.org/images/bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img.xz, version Debian 9 « Stretch » mars 2020,
– sans interface graphique (IoT = Internet of Things, si vous travaillez uniquement en ligne de commande) https://debian.beagleboard.org/images/bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz, version Debian 10 « buster » avril 2020.

Ensuite,  graver l’image sur une carte micro SD; elle sera ensuite insérée dans le BeagleBone Black (BBB).

Pour cela, il faut installer BalenaEtcher, logiciel pour graver l’image de la distribution Debian de Linux sur la carte micro-SD.
Sous Linux/Debian (OS de votre ordinateur), c’est possible avec apt-get:
sudo apt-get install balena-etcher-electron
Il est également possible de télécharger un installeur:  balenaEtcher.

BalenaEtcher permet de graver l’image du système d’exploitation sur la carte SD.  Il y a un petit trick sous Linux. Dans un terminal, on exécute directement:
balena-etcher-electron
On peut avoir le message d’erreur suivant:
/usr/bin/balena-etcher-electron: ligne 3: /usr/bin/balena-etcher-electron.bin: Aucun fichier ou dossier de ce type
La solution consister à exécuter:
/opt/balenaEtcher/balena-etcher-electron
voir la note dans https://github.com/balena-io/etcher/issues/3074

Ensuite, dans  balena-etcher, on sélectionne l’image Linux téléchargée et le disque contenant la carte mirco-SD, enfin on « flash »! Cela peut prendre un certain temps (4 Go).

Personnellement, j’utilise un adaptateur de carte SD vers USB, pour brancher la carte micro-SD sur l’ordinateur, ce qui est bien pratique.

Étape suivante: insèrer la carte mirco-SD dans le BBB (uSD dans l’image ci-dessous). Puis brancher la BBB sur un port USB de votre ordinateur (avec un câble micro USB inséré dans « USB client » sur la BBB)  . Attention, avant et pendant l’allumage, il faudra appuyer pendant quelques secondes sur le bouton « boot button » pour démarrer sur la carte SD (l’image ci-dessous est une BBB standard, mais la connectique est similaire):

Noter que le démarrage (boot) de la BBB peut prendre quelques minutes.

Étape: se connecter au réseau Wifi local

Cette étape est spécifique à la BeagleBone Black Wireless, dans laquelle le port Ethernet est remplacé par la Wifi.

Normalement, après avoir allumé la BBB, un nouveau réseau Wifi devrait être activé sur votre ordi. La BBB Wireless fonctionne en mode serveur Wifi.

Si votre Beagle comprend le WiFi, un point d’accès appelé « BeagleBone-XXXX » où « XXXX » varie selon les cartes. Le mot de passe du point d’accès est par défaut « BeagleBone ». Votre Beagle doit exécuter un serveur DHCP qui fournira à votre ordinateur une adresse IP dans la plage 192.168.8.x et se réservera 192.168.8.1.

Il faut donc activer, sur votre ordinateur, la connexion Wifi « BeagleBone-XXXX », pour se connecter à la BBB Wireless. Ensuite, ouvrir un terminal (sous Linux ou Mac OS, sous Windows utiliser Putty) et se connecter au BBB avec la commande:
ssh debian@192.168.8.1
login: debian!!!
mot de passe: temppwd (normalement c’est indiqué)

Étape suivante: se connecter au réseau local Wifi

Cette étape est aussi spécifique à la BeagleBone Black Wireless.
C’est très bien décrit ici, (en Anglais), pas à pas. Je ne traduis pas là.
L’objectif est de connecter la BBB à la Wifi de votre box (Livebox, Freebox ou autre). Vous aurez à identifier votre box dans le tuto et à entrer le mot de passe. Après, vous pourrez vous connecter directement à la BBB Wireless avec la Wifi « normale ».
Pour trouver l’adresse ip de votre BBB sur le réseau Wifi, taper
ifconfig
Vous obtenez quelque chose comme ça:

Entouré en rouge, dans wlan0, après inet vous avez l’adresse ip locale de la BBB, 192.168.1.25 dans mon cas. Cette adresse commence par 192.168 (en général 192.168.0.xxx ou 192.168.1.xxx selon la box).
Vous pouvez  vous déconnecter de la BeagleBone:
exit
Sur votre ordinateur, se déconnecter du Wifi de la BeagleBone et se reconnecter à la box si utilisation de la Wifi (je suis connecté en Ethernet).
Pour vous reconnecter à la BBBw:
ssh debian@192.168.1.25
J’ai eu besoin de taper, comme indiqué,
ssh-keygen -f "/home/benaroya/.ssh/known_hosts" -R "192.168.1.25"
(je ne détaille pas la raison) puis retaper ssh debian@192.168.1.25
Noter que la commande suivante fonctionne également:
ssh debian@beaglebone.home
Du coup, on n’utilisera plus la BBB Wireless en serveur Wifi, mais la connexion est simplifiée.

Étape suivante: démarrer directement sur la carte SD (sans appuyer sur le boot button!)
C’est décrit, en Anglais, ici BeagleBone Black Wireless: Boot from SD card by default.
Vous trouverez une explication similaire, in French, dans le fichier bootingonsdcard. C’est un peu différent parce que nous avons « booté » sur la carte SD.

Élargir la carte SD de plus 4 Go

Pour une carte micro-SD de plus de 4 Go, il faut faire la manipulation suivante. Par défaut, il y a une limitation à 4 Go sur la BBB, ce qui est dommage quand on a une carte SD de 32 Go, comme moi.
La solution:
Le script « grow_partition.sh » permet de faire ça.
sudo /opt/scripts/tools/grow_partition.sh
sync
Si problème, le script est accessible dans le repo github https://github.com/RobertCNelson/boot-scripts/blob/master/tools/grow_partition.sh Je remets le script à disposition là
Ensuite, il faudra redémarrer la BBB. Note: pour redémarrer un Linux en ligne de commande:

sudo reboot now

2 TIPS

Vérifier la date avec la commande « date » (une date mal réglée peut causer des problèmes d’update parfois):
date
Changer de fuseau horaire
timedatectl set-timezone Europe/Paris
ou pour nos amis Canadiens
timedatectl set-timezone America/Toronto
Nettoyer le système,
sudo apt-get clean
sudo apt-get autoremove
sudo apt-get update

Discussion :

La BeagleBone Black est intéressante pour les systèmes embarqués. Elle contient un micro-processeur Cortex-A8 à 1 Ghz (jeu d’instructions ARMv7) et deux microcontrôleurs PRU 32-bits (Programmable Real-time Unit) à 200 Mhz.
Par rapport à la Raspberry Pi, elle possède un autre avantage, la possibilité d’installer différentes distributions de Linux (Debian, Ubuntu) ou un Androïd (entre autres). L’OS standard de la Raspberry Pi (RPI), Raspbian, est une version adaptée de Debian.
L’avantage de la RPI est indéniablement la RAM (1 Go à 4 Go pour la RPI 4 contre 512 Mo pour la BBB) et ça peut faire une vraie différence pour des programmes gourmands en mémoire. Par ailleurs, la connectique USB est beaucoup plus intéressante. En mode ordinateur mono-carte, avec un écran, un clavier et une souris, utiliser une Raspberry Pi fait sens.
Concernant la BeagleBone Black Wireless, par rapport à la BBB standard, la Wifi est intéressante, pour installer des programmes facilement (apt-get install). Après est-ce que la différence de prix (de l’ordre de 20 €) se justifie? Vous me direz qu’on peut toujours ajouter un dongle USB sur la BBB. Mais il n’y a qu’un seul connecteur USB, donc le hub USB devient obligatoire, pas vraiment pratique.
J’utilise la BBBw branchée sur mon PC via le client USB (comme pour un Arduino), voulant explorer les possibilités de traitements temps-réel sur du son. Pour le moment, je suis content de mon achat. J’ai galéré quelque peu pour l’installation et la mise en place. J’espère que ce post permettra de vous aider et vous guider dans la prise en main.

ET VOILA!!!!