Salut,
spourre a écrit : ↑mar. 19 juin 2018 20:03
Je vais essayer d'y répondre mais je pense, même si le PO n'a pas encore manifesté de mauvaise humeur, que l'on s'éloigne un peu (beaucoup ?) du sujet d'origine.
Comme souvent, je ne suis pas sur qu'il soit encore parmi nous
Ceci dit, Michel si tu nous lis, je bosse sur un barrière optique pour mon poulailler, au cas où tu n'ai pas avancé de ton côté
(Faudra juste ne pas etre pressé, l'été étant aussi chargé que l'hiver
).
spourre a écrit : ↑mar. 19 juin 2018 20:03
Cela me donne à penser que la version est tellement peu allégée, qu'elle peut être invoquée en mode CLI, avec un makefile pour gagner en finesse et en automatisation dans la construction des programmes.
...
En suivant le lien vers ce fichier make, qui est hébergé sur un dépôt GIT:
https://github.com/plerup/makeEspArduino
Sur le forum Arduino, je suis aussi tombé sur
Arduino-Makefile qui est un Make Maker qui a l'aire de prendre en compte les librairies sans faire les copies dont je parle.
Quoi qu'il en soit, avec un Makefile, on devrait obtenir un .o par source : il faudra donc séparer ceux des librairies de ceux de notre programme et les charger en mémoire ... après avoir résolu le pb des liens.
Sur ce point précis, j'imagine qu'il y a le même pb lors des appels au firmware (les fameux 0x00000.bin ou 0x10000.bin), il faudrait regarder comment ils font les appels ... en espérant que ce ne soit pas par un système de trap.
spourre a écrit : ↑mar. 19 juin 2018 20:03
Je trouve déjà bluffant qu'il accueille un RTOS et puisse se programmer en C, C++.
Hé hé, je me suis fait la même réflexion
Non pas pour le C car ca se fait aussi sur des uP beaucoup moins dotés comme les PICs, mais il y a eu de gros progrès fait avec GCC et le C++ : mes premieres expériences en C++ (
y'a bien longtemps) donnaient des exécutables très gros et surtout très lourd. Ce n'est (heureusement) plus le cas.
spourre a écrit : ↑mar. 19 juin 2018 20:03
L'ESP n'est pas un nano-computeur mais reste un (puissant) microcontrôleur [...] Vouloir des DLL, avec tout ce que cela comporte de problèmes de compatibilité entre les versions, ne me semble pas raisonnable.
Le but n'est pas d'avoir des DLL, mais de pouvoir ne mettre à jour que la partie du binaire correspondant à notre code. Le postulat étant que les "librairies" restent inchangées. Si on doit les faire évoluer (nouvelles versions, changement des options de compilation), un système comme je le présente plus haut nécessite de réinstaller toutes les parties ... et sans doute de recompiler notre propre partie, les offsets changeant peut-être.
spourre a écrit : ↑mar. 19 juin 2018 20:03
Vouloir un loader avec calcul de la relocation de entrées de la DLL va se payer en termes de délais de réaction
Oui, s'il y a relocation. Mais si tu utilises un système d'offsets comme je le décris, il n'y a strictement aucune pénalité : l'étape équivalente à la relocation est faite lors de la compilation lorsque les offsets sont calculés par le compilo ... et fait parti de toutes facons des tâches qu'il doit faire.
L'adresse/Offset étant connu à ce moment là, aucune perte de temps.
spourre a écrit : ↑mar. 19 juin 2018 20:03
et en perte de performances (bye bye le temps réel), comme nous le connaissons malheureusement avec le Raspberry.
Le pb est différent sur les système Unix : du fait de son multitâche évolué (et dynamique), le réveil d'un processus particulier n'est pas suffisamment déterministe et surtout rapide lorsqu'un événement arrive ...
Comme il me semble que nous en avions discuté, il n'y a dans ce cas qu'une seule possibilité : c'est créer un module kernel qui attache la routine de traitement directement à l'interruption qui l'interesse (
à l'ancienne on pourrait dire). Du coup, il court-circuite tout le mécanisme du multitâche (avec les inconvénients que cela implique) mais on a vraiment du temps-réel. La dite routine doit être la plus courte possible et à pleins de limitations, classique de chez classique.
Sinon, pour en revenir à l'OTA en temps que tel, une autre solution serait de passer par Lua vu que seul le script serait à télécharger et non les librairies et le langage : je n'ai pas essayé car j'ai lu qu'il ne restait pas des masses de place pour le script ... et comme je n'ai le pb que sur les ESP ayant le moins de flash ...
Mais bon, faudrait que je trouve le temps de regarder de plus prêt.
A+