Écrire son BOOTLOADER

Bonjour à vous !
Je développe actuellement une petite console de jeux vidéo, bon déjà à terme, mais je suis buté au niveau du bootloader.
En fait j'utilise un atmega 328P et question de mémoire flash pour televerser les jeux c'est pas trop ça.
J'aimerais que le bootloader conserve d'abord ses propres fonction mais exécuté un croquis stoké dans une carte mémoire, croquis qui me permettra de naviguer dans la carte mémoire et lors de la sélection d'un jeu vidéo qu'il la charge maintenant dans la flash comme croquis à être exécuté.
Et je suis un peu perdu.?? ¿¿🤕🤕

Bonjour et bienvenue sur DVP

Ce n'est juste pas prévu chez Arduino.

Plus généralement, l'architecture AVR (dont fait partie l'ATMega) ne prévoit pas de pouvoir exécuter un code à partir d'ailleurs que de la Flash. C'est une limitation que l'on retrouve sur quasi toutes les petites architectures "microcontrôleurs". C'est le contraire des architectures "microprocesseur" qui copient le programme à exécuter dans la RAM et qui nécessitent donc un bootloader pour charger le premier programme (qui lui va pouvoir charger les différents programmes). En microcontrôleur, l'usage cible c'est le programme unique qui démarre de suite et le bootloader est optionnel.

Techniquement rien n’empêche de faire un bootloader qui va flasher le reste de la mémoire à chaque "chargement d'un jeu", mais ce n'est ni recommandé, ni prévu par la couche Arduino.
Non recommandé car le nombre d'écritures est limité (à 10'000 ou 100'000) et que en cas d'erreur on peut courir à la destruction de la puce. Cette procédure est prévue uniquement pour une mise à jour du code de la puce, pas pour un chargement à la volée. Ni prévu, car Arduino ne permet juste pas d'écrire un sketch "bootloader".

Pour cela il faut oublier la couche Arduino et apprendre à programmer en C ou C++ "AVR", c'est toujours le même langage, sauf que l'on fait beaucoup plus d'accès aux registres du microcontrôleur et que c'est sans filet. Il faut aller lire la documentation de l'ATMega328p aux chapitres (25, 26 et 27) qui parlent de cela.
C'est une programmation pour une personne expérimentée sans la surcouche Arduino, pas pour un débutant.

N'ayant jamais mis en production un de mes codes (je ne le fais que en hobby, quand j'ai besoin de faire une mise à jour c'est via la programmation ISP) je n'ai jamais attaqué cette partie des puces AVR. Il me semble que c'est le cas des membres actifs de ce forum.

Bonne suite

Delias

C'est une question qui revient de temps en temps...

Le bootloader a deux fonctions principales: le chargement d'une application dans la mémoire FLASH à partir de la ligne série et le lancement de l'application. comme il est résident, l'enjeu c'est de le conserver le plus petit possible pour laisser de la place aux applications... (Optiboot c'est 512 bytes)

Votre bootloader tel que vous le décrivez aurait besoin donc de savoir lire une carte SD pour aller écrire la mémoire flash, de savoir gérer une interface (graphique ?) et savoir comment prendre la main à tout moment (le code des jeux doit pouvoir lui redonner la main pour passer au jeu d'après ?)... l'architecture AVR a aussi des gardes fous en place (même s'il y a des contournements) qui empêche une application d'écrire dans la mémoire programme (sauf si c'est le bootloader).

Sur un MEGA avec ses capacités limitées, et les contraintes du hardware, ça n'a pas tellement de sens à mon avis et nécessiterait des développement qui feraient que le bootloader est en fait l'application....

vous pouvez regarder Optiboot/OptibootX si vous voulez avoir une idée de comment on écrit un bootloader (même s'il n'est pas dispo pour MEGA)

un ESP32 avec un mode OTA pourrait faire des choses un peu plus avancées avec le nouveau code qui viendrait du web. pas forcément super pratique...

Oui oui @Jay_M c'est nettement ce que j'aimerais faire.
Merci pour vos réponses. J'ai eu à chercher un peu mais je ne trouve vraiment rien de concret sur comment le faire et si c'est même possible.
Quand au autres solutions pouvant résoudre le problème je suis toute ouïe.

Citation:

---

Envoyé par 2gdkMare

Oui oui @Jay_M c'est nettement ce que j'aimerais faire.
Merci pour vos réponses. J'ai eu à chercher un peu mais je ne trouve vraiment rien de concret sur comment le faire et si c'est même possible.
Quand au autres solutions pouvant résoudre le problème je suis toute ouïe.

---

C'est "techniquement" possible de faire un bootloader qui sait aller lire des octets sur une carte SD en SPI pour venir les mettre en mémoire programme (au lieu d'écouter le port série). Mais comme expliqué ci dessous, il faut aussi penser à l'interface utilisateur (quel fichier aller lire sur la carte SD) et donc il y a aura sans doute encore plus de choses à mettre dans le bootloader.

Même si vous acceptez d'avoir à rebooter pour charger un nouveau code, vous allez vous retrouver avec un bootloader qui va prendre bcp de place, ce qui va limiter ce que vous pourrez faire de concret dans l'espace restant...

C'est pour cela que ça n'existe pas, le résultat ne vaut pas l'effort fourni - ces micro-contrôleurs ne sont pas fait pour cela.

Ensuite comme l'a dit @Delias, il n'y a pas de tuto pour écrire un bootloader parce que ce n'est pas ce que fait la majorité des utilisateurs... Il faut se plonger dans la doc technique et étudier optiboot par exemple pour comprendre comment ça fonctionne. Prévoyez quelques longues soirées de boulot si vous maitrisez déjà bien le C et la programmation bas niveau avec accès aux registres etc...

une "solution plus simple", vu le coût et la taille des composants, serait de faire un second petit appareil dédié qui simule le PC. Un bouton vous permet de choisir quel Arduino "est le chef". Si vous bootez sur le master, il sait lire sur une carte SD et envoyer les octets sur le port série (ou en SPI par ISP (In Site Programming)) après avoir fait une séquence de reset sur le slave pour charger un nouveau code. si vous bootez sur le slave, il exécute le dernier code chargé. (jetez un oeil sur le code de l'exemple ArduinoISP)

un montage adéquat d'un point de vue électrique est aussi à prévoir pour partager des composants (boutons, écrans) entre les 2 Arduinos. Votre boîtier de jeux aurait donc 2 Arduinos embarqués.

Waouh... Cette solution m'a l'air plus efficace car ca me garantie l'espace mémoire.
D'accord je vais fouiner dans la datasheet du micro-controleur. J'espère que c'est compréhensible à ce niveau 😅.
Merci beaucoup pour votre aide.
J'ai consulté l'optiboot qui contourne la barrière imposé par les AVR et ça m'a l'air inspirant bien que je ne comprenne pas encore grand chose.
Je regarde l'exemple que tu m'as fourni .
Merci bien !!!