LinuxFr.org : les journaux  -  Modélisation - question de point de vue ?

 -  4 novembre - 

Bonjour.

J'avais initialement l'intention de poser une question simple dans un forum, mais au final, au fur et à mesure que je rédigeais ma question, je me suis dit que celle-ci méritait peut-être un journal. Si ce n'est pas le cas, veuillez m'en excuser.

J'essaie de modéliser un système à base de carte style arduino, Raspberry Pi ou Micro:bit, et je me pose une question un peu basique mais qui n'est pas si évidente que ça : comment représenter la hiérarchisation de la carte, du firmware si elle en possède et du logiciel développé, qui sera exécuté par la carte.

Habituellement on décompose ces éléments en couches : on a le hardware, puis par dessus, le firmware (s'il y en a), puis par dessus le système d'exploitation (s'il y en a un) puis par dessus l'applicatif. Le firmware et le système d'exploitation ne sont pas obligatoire : on peut directement développer une application bare-metal, ou se baser sur des SDK qui ne sont ni des OS, ni des firmwares, mais des libs de code qui permettent d'acccéder au matériel.

Cela dit je suis en train d'essayer de décomposer ceci d'un point de vue de blocs style 'poupées russes" ou boites qui contiennent d'autres boites, et je me demande comment modéliser le matériel par rapport aux couches "codées (firmware/OS/application).

Doit-on considérer que le matériel inclut le logiciel ? comment ensuite organiser le firmware, le système d'exploitation et le code applicatif ? En y réfléchissant je ne suis pas sûr que cette approche soit la bonne, sans être mauvaise non plus ( ça doit dépendre je pense de ce que l'on veut mettre en évidence dans le modèle) Du coup, je demande à ceux qui ont l'habitude de faire ce genre d'analyse de me donner leur point de vue. Comment faites-vous ?
Si ça peut aider j'ai quelques exemples en tête. On va prendre pour base un système de mesure de température (basé sur un capteur de température - I2C ou analogique importe peu ), un afficheur LCD (idem - i2C, SPI, ou à base de contrôleur 7 segments LED), et possibilité d''envoyer les données de température sur un bus série type UART. Comment modéliser ce système dans les cas suivants :

• carte basée sur un microcontrôleur AVR ATTiny, sans système d'exploitation, développé en C avec avr-gcc
• carte arduino (je considère la couche arduino comme un firmware - mais peut-être à tort ) - avec utilisation de tous les outils arduino
• utilisation d'un raspberry pi zero, programmation C bare-metal ( un firmware, le système de boot du raspberry, pas d'OS, mais éventuellement des libs permettant de configurer les ressources du RPi)
• raspberry pi zero avec un OS (au moins noyau + libC voire libs) - programme écrit en C.
• raspberry pi nano et le logiciel écrit en python (micropython)
• application qui se base sur un système Forth qui s'exécute sur une carte Micro:bit (je pense que ça doit ressembler au cas précédent).
• utilisation d'une carte basée sur X86 + bios (le firmware), en C (ou en assembleur), sans utiliser d'OS, mais en utilisant les interruptions du BIOS pour accéder au matériel. L'affichage dans ce cas se fera sur la sortie vidéo, et non sur un écran LCD
• utilisation d'une carte basée sur X86 + bios (le firmware) + Système d'exploitation. en C - ou tout autre langage de plus haut niveau - L'affichage dans ce cas se fera sur la sortie vidéo, et non sur un écran LCD

Commentaires : voir le flux Atom ouvrir dans le navigateur

par totof2000