Gestion rationnelle des fichiers du testeur de batterie
publication: 9 avril 2024 / mis à jour 12 avril 2024
Appel à collaboration
Vous développez des montages, simples ou complexes avec ESP32 et ESP32forth.
Partagez-les ici sur ce site.
ESP32forth ne pourra se développer qu'avec la collaboration active de toutes les bonnes volontés.
Vos montages peuvent aider d'autres développeurs.
Les montages des autres développeurs peuvent vous aider.
Pour proposer un article ou un montage, cliquez ici
Retrouvez l'ensemble des fichiers du projet Testeur de batterie ici:
ESP32forth/__my projects/sensors/B25 Voltage Module
Le nombre et le contenu de ces fichiers est susceptible d'évoluer sans avertissement.
Organisation des fichiers du projet
Reprenons les fichiers du projet tel que décrit dans le précédent article:
📁 ESP32developments
📁 __sandbox
📁 B25 VCC Module
🖹 b25.fs
Il y a quatre fichiers essentiels à rajouter dans le répertoire B25 VCC Module:
📁 ESP32developments
📁 __sandbox
📁 B25 VCC Module
🖹 autoexec.fs
🖹 config.fs
🖹 main.fs
🖹 tests.fs
🖹 b25.fs
On reprendra quasi systématiquement ces quatre fichiers dans le répertoire de chaque projet.
La méthode d'organisation décrite ici est donnée à titre de conseil. Ce n'est en aucun cas une norme. Cette méthode s'inspire des modèles MVC (en PHP par exemple), de méthode Agile pour la souplesse méthodologique, la modularité du code en langage C...
Vous êtes libre de suivre ces recommandations ou de les adapter et les améliorer pour permettre une programmation plus efficace, avec des codes sources réutilisables pour tous vos autres projets.
Voyons en détail comment remplir chaque fichier. Vous allez rapidement comprendre l'intérêt de cette organisation.
Le fichier autoexec.fs
Vous pouvez reprendre le contenu du fichier autoexec.fs disponible ici.
Si vous n'avez jamais utilisé RECORDFILE, la première opération à effectuer est de copier le code depuis
create crlf 13 C, 10 C, jusqu'à la fin de la définition de RECORDFILE. Collez ce code
dans le terminal relié à la carte ESP32. Ceci doit compiler le mot RECORDFILE.
Vérifiez la disponibilité de RECORDFILE en tapant words dans la fenêtre de terminal:
--> words MAIN RECORDFILE crlf FORTH oled timers interrupts telnetd registers webui login web-interface httpd ok LED OUTPUT INPUT HIGH LOW tone freq duty adc pin default-key? default-key default-type visual set-title...
Si le mot RECORDFILE s'affiche en début du dictionnaire, l'opération suivante consiste à copier,
depuis le PC, le contenu du fichier autoexec.fs et le coller à nouveau dans la fenêtre du terminal.
Cette fois-ci, toute la partie de code située entre RECORDFILE et <EOF> sera enregistrée dans le
fichier autoexec.fs du système de fichiers SPIFFS de la carte ESP32.
Vérifions le contenu du fichier autoexec.fs entregistré sur la carte ESP32:
--> cat /spiffs/autoexec.fs
create crlf 13 C, 10 C,
: RECORDFILE ( "filename" "filecontents" "<EOF>" -- )
bl parse
W/O CREATE-FILE throw >R
BEGIN
.....[removed code].....
internals 120 to line-width
forth
ok
Redémarrez la carte ESP32. ESP32forth est programmé pour charger automatiquement le contenu du fichier
autoexec.fs
au démarrage. Tapezwords pour vérifier la présence des mots
MAIN RECORDFILE crlf.
On va maintenant s'intéresser à la définition du mot MAIN définit en fin de fichier autoexec.fs:
: MAIN
s" /spiffs/main.fs" included
;
Si on exécute le mot MAIN, il va tenter de charger le contenu du fichier main.fs.
Le fichier main.fs
Ce fichier est le squelette du projet. En l'état des fichiers décrits précédemment, voici son contenu:
RECORDFILE /spiffs/main.fs DEFINED? --b25 [if] forget --b25 [then] create --b25 s" /spiffs/b25.fs" included s" /spiffs/config.fs" included s" /spiffs/tests.fs" included <EOF>
Copiez ce contenu, depuis RECORDFILE jusqu'à <EOF> inclus. Collez ce contenu dans le terminal.
Cette action va enregistrer un fichier main.fs dans le système de fichiers SPIFFS de la carte ESP32.
Vérifions la bonne présence de ces fichiers en exécutant ls:
--> ls /spiffs/ autoexec.fs main.fs ok
Vous pouvez remarquer que le fichier config.fs est chargé après b25.fs. C'est contre-intuitif, mais la configuration globale de certains paramètres sera exécutée après chargement de tous les autres fichiers applicatifs.
Le fichier main.fs ne doit contenir que des appels aux fichiers applicatifs, puis de configuration et enfin de tests.
Le fichier config.fs
Revenons sur le code écrit dans b25.fs:
02 value B25_NUM_1
03 value B25_NUM_2
\ init GPIOs used by B25 modules
: B25.init ( -- )
B25_NUM_1 INPUT pinmode
B25_NUM_2 INPUT pinmode
;
Ici, en rouge, on a prédéfini les deux ports GPIO utilisés par nos modules B25. On va réécrire ce code comme ceci:
\ set GPIOs used by B25 modules, values set in config.fs 0 value B25_NUM_1 0 value B25_NUM_2 \ init GPIOs used by B25 modules : B25.init ( -- ) B25_NUM_1 INPUT pinmode B25_NUM_2 INPUT pinmode ;
Puis on définit le paramétrage des valeurs B25_NUM1 et B25_NUM2 dans
le fichier config.fs ainsi:
\ *** set parameters for B25 modules *** file b25.fs ****************** \ set GPIOs used by B25 modules DEFINED? B25_NUM_1 [IF] 4 to B25_NUM_1 \ GPIO 4 to first B25 module [THEN] DEFINED? B25_NUM_2 [IF] 3 to B25_NUM_2 \ GPIO 3 to second B25 module [THEN]
Cette manière de procéder peut sembler lourde. Mais l'intérêt est de permettre une adaptation rapide du code FORTH sans avoir à modifier le code des fichiers applicatifs.
J'ai écrit mon code pour la carte ESP32-C3-Zero-M. Sur une autre carte ESP32, l'utilisation de ces ports peut ne pas vous convenir. Si vous cablez les modules sur les ports GPIO 17 et 18 par exemple, vous n'aurez que deux lignes de code à modifier dans config.fs.
En l'état, l'alourdissement de notre code FORTH n'est pas nécessaire. Mais ça devient intéressant quand on commence à avoir beaucoup de fichiers applicatifs, ce qui va rapidement arriver à notre projet si on veut gérer un affichage texte sur écran OLED, déclencher un buzzer...
Le fichier tests.fs
C'est le dernier fichier chargé par main.fs.
Il ne doit contenir que des des tests unitaires, des essais de portion de code.
Pour ma part, j'ai rajouté un ingrédient, un fichierassert.fs, qui ne sera chargé que par tests.fs.
Le fichier assert.fs contient les définitions permettant d'effectuer des tests unitaires.
RECORDFILE /spiffs/tests.fs \ *** UNIT TESTS ********************* s" /spiffs/assert.fs" included \ test B25 GPIOs correctly initialized assert( B25_NUM_1 4 = ) assert( B25_NUM_2 3 = ) <EOF>
Si le test est réussi, assert( n'émet aucun message. Dans le cas contraire, il génère une erreur. Exemple:
assert( 3 4 = ) \ send error message assert( 2 10 < ) \ send no error
L'intérêt des tests unitaire permet de contrôler le comportement de définitions sensibles. Si vous êtes amené
à améliorer une définition, assert( détectera toute altération des résultats.
Notre fichier tests.fs permet aussi de tester l'application. Prenons un peu d'avance sur les prochains articles, voici comment j'exécute le test du projet depuis tests.fs:
buzzer.init B25.init wire.init Oled128x32Init
Evidemment, à un certain stade de développement, l'appel de ces mots sera intégré à l'application définitive. Quand on en sera à cette étape, on pourra débrancher l'appel à tests.fs.
Legal: site web personnel sans commerce / personal site without seling