Une solution soft ne sera jamais aussi efficace qu’une solution radicale comme la votre.
J’imagine que la votre impose l’extinction dès la mise sous tension.
La solution logicielle à laquelle je pensais consiste à imposer l’extinction en amont du programme automate, c’est à dire lors du chargement de l’os Linux (donc inutile de recompiler le soft).
Il subsistera encore quelques secondes (9 s après essais) où les led seront dans un état indéterminé car entre la mise sous tension et le chargement de Linux il y a des opérations réalisées par le bootloader de l’opz qui prennent encore quelques secondes. Intervenir sur ce bootloader pour gagner encore quelques secondes est un peu risqué, c’est un peu plus compliqué qu’intervenir sur le BIOS d’un PC. La carte sd peut ne plus démarrer du tout.
Filezilla est un client ftp qui permet simplement le transfert de fichiers vers l’opz. Vous ne pourrez pas lancer des commandes ssh de recompilation du code par exemple. Pour lancer des commandes Linux sur l’OPZ, il suffit d’ouvrir une console MS-DOS sous Windows (command tool) et se connecter par une commande ssh si elle est installée (ssh orangepi@192.168.1.28 par exemple) vous pourrez ensuite lancer des commandes Linux dans ce terminal.
Dites moi lorsque vous êtes parvenu à vous connecter de la sorte, il y aura deux commandes Linux à lancer. Je prépare les fichiers à placer sur l’opz pendant ce temps.
Effectivement cette solution hardware impose l’extinction des LED pendant la phase de boot. Ceci étant, j’aurais du préciser qu’une modification hardware plus simple conduit au même résultat, cf. ci-après :
Dans le montage précédent c’est la résistance R77 qui fixe un potentiel stable, qui sera en suite utilisé pour commander le transistor. On peut cependant par rapport au montage d’origine se contenter de rajouter seulement R77. Cette résitance draine un courant additionnel qui impose lors de l’état indéterminé, un potentiel qui plafonne autour de 1 V (impédance interne OPZ élevée) sur les pins 16 et 18. Le seuil d’allumage n’est plus atteint et la (les) LED restent éteintes. Lorque le vrai niveau logique 1 est atteint, les LED s’allument normalement. Si j’ai ajouté un transistor c’était simplement pour disposer d’un courant plus élevé pour le pilotage des LED, mais il n’y a pas d’obligation.
Stockfish, j’ai pris la main en mode SSH via le terminal, aucun problème.
Maintenant si les modifications logicielles versus hardware paraissent disproportionnées, ce ne sera peut-être pas nécessaire d’aller plus loin. Je reste cependant toujours prêt à tester toute solution logicielle, j’apprendrai toujours sur un plan pédagogique, moi qui ne bricole que sur des petits Arduino !
Bonjour Jean-Roger,
Je ne pense pas qu’il y ait mieux que cette solution, il s’agit d’une résistance de pull-down placée sur port gpio. Il y a longtemps, j’avais testé cette solution sans succés, j’avais utilisé une résistance de 10 k et ça ne fonctionnait pas.
Merci pour cette amélioration notable.
Si vous vous intéressez à cette phase de boot, vous trouverez ci dessous le chronogramme logiciel du boot. Par rapport à celui d’origine, j’avais placé un service gpio_init d’extinction des leds. On le trouve dans le tableau : gpio-init.service (601ms) après le montage du système de fichiers.
Vous constaterez que le boot total prend environ 30 s. Le noyau prend les 4 premières, il aurait été difficile de descendre sous ces 4 s sans toucher au bootloader. Conclusion : votre solution est celle qu’il faut.
Edit : pour zoomer, click droit et ouvrir l’image dans un onglet.
Pour info, maintenant que vous êtes en ssh vous pouvez générer ce graphe par la commande : systemd-analyze plot > services.svg
Vous récuperez le fichier .svg par filezilla.
bonne journée
Merci Stockfish, on va donc s’en tenir à cette résistance de pull-down à 1 k. Avec une valeur à 10 k le courant drainé n’est pas suffisant compte-tenu de l’impédance interne de l’OPZ en état indéterminé. A l’état haut le courant additionnel total est d’environ 6 mA (2x3 mA), rien de méchant pour l’OPZ !
Bien noté pour toutes les explications concernant le chronogramme logiciel. Je réaliserai la manip de mon côté via SSH.
J’ai une question supplémentaire concernant l’OPZ. Elle m’a été posée par une de mes connaissances qui souhaite se lancer dans la réalisation d’un exemplaire de ModulAM (très bonne idée !) Il m’a rapporté que l’offre sur Aliexpress concernant l’OPZ dans sa version 2 était finalement assez restreinte. Pris de curiosité , je n’ai trouvé de mon côté que deux propositions chez Aliexpress. Cela signifie-t’il que cette cette carte soit sur le déclin ? On trouve en revanche plein d’autres propositions : un modèle Zéro Plus 2 doté d’un H3, un Zéro 2 W doté d’un H618, un Zéro 3 doté d’un H618 …
Je suppose qu’aucun de ces modules n’est directement compatible pour des questions à minima de GPIO, de processeur, d’adresses, sans nécessiter de réécrire / adapter le logiciel existant ?
Bonne journée, je ne reviendrai que demain sur le forum.
Je n’ai pas testé avec les cartes citées mais en effet tôt ou tard on ne trouvera plus la premiere.
Les procédures d’installation (premiere installation ou mises à jour en un clic) recompilent le code. Ca favorise la portabilité et il est possible que pour certaines cartes cela fonctionne dans le cas où les affectations broches<->gpio sont identiques sinon il faudra modifier le câblage et, dans le pire des cas le code, mais pas forcément.
J’ai pu le faire il y a quelque temps avec un Raspberry Pi 2b que j’avais en stock.
Je viens de me procurer un Raspberry pi 5 et je compte adapter le programme à cet engin d’ici quelques semaines. Bon evidemment il coûte beaucoup plus cher qu’un opz mais je m’en sers pour d’autres choses. Le boitier pourra avoir d’autres fonctions.
Je pense que votre idée permet de mettre en oeuvre la solution la plus optimisée pour faire disparaître définitivement cette demi activation des deux leds pendant la phase d’initialisation du ModulAM.
C’est d’autant plus intéressant qu’aucune modification matérielle n’est à prévoir sur le module principal ni sur le module OPZ.
Il est en effet possible d’ajouter cette résistance directement au niveau de chaque led au même titre que celle de 220 ohms.
Je vais porter cette modification sur l’exemplaire de test du ModulAM et une fois validé la méthode, nous pourrons éditer une nouvelle version de la documentation « ModulAM_Boitier_accueil_Partie_2 », avec une mise à jour au niveau des textes et des illustrations, concernant cette amélioration.
Merci de votre implication !
Une communication sera effectuée ici lorsque tout sera prêt et publié sur le site du ModulAM.
On peut en principe remapper les broches du GPIO en modifiant le fichier HAL. Ceci devrait permettre d’utiliser une autre carte, mais il faut du savoir-faire.
Bonjour,
Faisant suite aux divers messages et à votre contribution, nous avons pu valider la solution des 2 résistances pull-down pour résoudre le demi-éclairement des leds L2 et L3 lors de la phase d’initialisation de l’OPZ.
Le fonctionnement est parfait et le comportement des leds, conforme à l’exploitation.
La notice « ModulAM_Boitier_accueil_Partie 2 » a donc été mise à jour en v1.3, avec cette modification et est téléchargeable directement ici ou sur le site du ModulAM.
Les pages concernées :
Page 7 : plan général de câblage
Pages 12 & 13 : câblage des résistances sur les deux voyants led.
Merci Jean-Roger pour avoir identifié une solution très simple à mettre en œuvre améliorant le confort d’exploitation du ModulAM au travers d’une visualisation rationnelle des états du fonctionnement.
Doctsf (Modèles & Marques)
Annonces
