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
# Bon ... Finalement après y avoir réfléchi un peu ..
Posté par totof2000 . Évalué à 2.
.. je pense que la meilleure façon de faire est de modéliser un système complet (système de mesure de température), qui contient le matériel, le "code", décomposé en couches (firmware si présent, OS si présent et application). Au niveau code, la représentation en "conteneur" et "contenu" n'a pas de sens je pense …. Ce sont des composants distincts qui communiquent par des interfaces. Au final je pense que je me suis fait des noeuds au cerveau pour rien. Par contre je m'interroge quand même sur le matériel par rapport au code : je pense que les deux représentations peuvent être valables selon le contexte : on peut considérer que le matériel est une sous-couche du code, ou que le matériel contient le code. Mais je peux me tromper.
# But de la modélisation
Posté par gUI (Mastodon) . Évalué à 8.
Tu n'expliques pas ce que tu veux modéliser en fait. C'est pour montrer quoi à qui ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: But de la modélisation
Posté par totof2000 . Évalué à 3.
En fait tu mets le doigt sur mon problème : je n'ai pas encore les idées claires sur ce que j'ai besoin de montrer : je pense que je me suis un peu éparpillé. Mon idée initiale était de représenter les divers composants d'une VM Forth sur une carte micro:bit (je voulais utiliser un schéma de blocs sysml pour identifier les interactions entre les divers composants : inner interpreter, text interpreter, dictionnaire, etc … Pas de besoin particulier, c'est juste un exercice ou un défi que je m'impose, pour potentiellemnt écrire un article si j'arrive à quelque chose qui tient la route ), et je me suis laissé allé à réfléchir à une façon plus générique de représenter un système à base de processeur ou microcontroleur ou on a interaction entre matériel et code. L'idée était d'inclure le bloc "VM Forth" dans un autre modèle, mais sans contexte réel, ni besoin particulier et j'en suis venu à me poser plein de questions. Et la question à laquelle je n'ai pas vraiment de réponse, c'est celle du code et du matériel: peut-on considérer que le code est inclus le matériel, ou que le code est une sur-couche du matériel. Et je pense que les deux modélisations sont possibles, selon le pont de vue ou on se place.
[^] # Re: But de la modélisation
Posté par gUI (Mastodon) . Évalué à 7.
Encore une fois, ça dépend de ce que tu veux faire…
Mais pour te donner une piste, on peut parfois considérer qu'un firmware jamais mis à jour (style le BIOS par exemple) pourrait être "noyé" dans le matériel. Il est finalement aussi inamovible que le matériel et il suit pour ainsi dire le même cycle de vie. D'ailleurs de manière générale le cycle de vie (fréquence de mises à jour) est un indice que j'aime bien quand il s'agit de découper les boîtes du logiciel.
Pour illustrer : tu mets rarement à jour ton kernel et ta libc, et plus souvent ton browser. Et si tu veux représenter les couches logicielles de ton ordi sous Linux tu auras en effet envie de faire une boîte pour l'OS et une boîte pour les applis.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# pas clair
Posté par kalimba . Évalué à 3. Dernière modification le 04 novembre 2023 à 16:50.
On vois pas clairement quelle est la difficulté que tu rencontre, quel est le probleme ? En gros tu hésite entre une modélisation par couche ou une modélisation par boite, c'est ca ? Mais ces deux représentations reviennent au meme, on peut toujours convertir une représentation par boite en représentation par couche et vice-versa, du coup ta question n'a pas de sens. Prend une représentation par couche, et regarde la par le dessus, la couche du bas apparait comme une boite qui contient les couches du dessus, et ainsi de suite. On peut meme inverser et faire apparaitre le matériel comme la petite boite qui est contenu dans la boite firmware, contenu dans la grande boite logicielle. Tout ca est strictement équivalent logiquement. Bon après on peut mélanger les deux schématisations, rajouter des flèches et milles autres complications que permet le support visuel.
oui, le matériel est généralement la couche en dessous, ou la boite qui contient les autres. Mais pour les boites je vois souvent le matériel au centre aussi
materiel > firmware > os > code applicatif
Si le code applicatif utilise une lib pour acceder au materiel, tu peux remplacer l'OS par la lib.
Si tu veux mettre en avant le fait que la lib est melangée au code applicatif contrairement a un kernel qui est bien plus separé, tu peux separer les deux couches ou les deux boites par un trait pointillé horizontal (qui veut dire "c'est un peu la meme couche mais pas tant que ca").
Si tu veux mettre en avant le fait que le code applicatif accède des fois directement au matos, des fois en passant par la lib, tu peux séparer la couche par une ligne pointillé verticale avec a gauche le code applicatif et a droite la lib. Une autre facon de faire est que la couche applicative sur la gauche touche le matériel et sur la droite touche la lib. Un peu comme le "simulation oriented layer" de ce schema https://www.mdpi.com/applsci/applsci-12-06322/article_deploy/html/images/applsci-12-06322-g008.png
# Quel formalisme pour ton modèle ?
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Bon, un peu comme les autres, que veux-tu modéliser ?
Quel formalisme ? A qui veux-tu montrer ton modèle ?
En vrac, j'ai pensé à :
Au final, faire un modèle, ça peut correspondre à plein de trucs
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.