Bon, comme on l'a dit, on développe un pilote pour un produit dès lors que ce produit réalise à sa manière une tâche qui est déjà connue et identifiée dans ses grandes lignes par l'utilisateur et/ou le système d'exploitation. Par exemple, si l'une de tes cartes était une imprimante, ça vaudrait le coup de l'associer à l'existant pour pouvoir automatiquement profiter des facilités de composition et de mise en page.
Accessoirement, toutes les fonctionnalités sont dans un seul binaire, très difficile à maintenir, raison pour laquelle je me suis dit que déplacer le code lié au hard dans des pilotes serait une piste intéressante, pour débloater un peu le bouzin (qui n'est, bien sûr, absolument pas documenté).
Ça reste une bonne idée en soi. C'est juste que ces modules ne seraient pas forcément des pilotes.
Tu peux déjà faire un distingo entre le côté matériel, de bas niveau, et le haut de la pile, c'est-à-dire son exploitation par l'utilisateur. Comment fonctionne globalement cette application à l'écran ? Est-ce qu'il y a juste un menu du style « 1. ... 2. ... 3. ... 4. ... 5. ... » qui se contente de basculer vers une application distincte à chaque fois, ou est-ce que l'on a, par exemple, un tableau de bord qui serait toujours présent ?
Tu peux aussi t'inspirer d'OBD2 (le protocole de la prise diagnostic des voitures) qui, d'un côté, spécifie le protocole lui-même et, de l'autre, une quantité impressionnante de codes produits et des réponses qu'ils peuvent envoyer, sachant que chaque véhicule n'implémente qu'un petit sous-ensemble de cette liste (correspondant aux équipements réellement embarqués dans le véhicule). Et ensuite, tu regardes si, à chaque fois, tu peux inscrire une carte donnée dans ce cadre.
M'enfin cela ne reste que des pistes de réflexion. Il n'y a rien de pire qu'un standard écrit à l'arrache au départ et qu'il faut ensuite maintenir par compatibilité pendant des décennies (sans exagérer).
[^] # Re: Pour quelles applications ?
Posté par Obsidian . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 3.
Effectivement.
Bon, comme on l'a dit, on développe un pilote pour un produit dès lors que ce produit réalise à sa manière une tâche qui est déjà connue et identifiée dans ses grandes lignes par l'utilisateur et/ou le système d'exploitation. Par exemple, si l'une de tes cartes était une imprimante, ça vaudrait le coup de l'associer à l'existant pour pouvoir automatiquement profiter des facilités de composition et de mise en page.
Ça reste une bonne idée en soi. C'est juste que ces modules ne seraient pas forcément des pilotes.
Tu peux déjà faire un distingo entre le côté matériel, de bas niveau, et le haut de la pile, c'est-à-dire son exploitation par l'utilisateur. Comment fonctionne globalement cette application à l'écran ? Est-ce qu'il y a juste un menu du style « 1. ... 2. ... 3. ... 4. ... 5. ... » qui se contente de basculer vers une application distincte à chaque fois, ou est-ce que l'on a, par exemple, un tableau de bord qui serait toujours présent ?
Tu peux aussi t'inspirer d'OBD2 (le protocole de la prise diagnostic des voitures) qui, d'un côté, spécifie le protocole lui-même et, de l'autre, une quantité impressionnante de codes produits et des réponses qu'ils peuvent envoyer, sachant que chaque véhicule n'implémente qu'un petit sous-ensemble de cette liste (correspondant aux équipements réellement embarqués dans le véhicule). Et ensuite, tu regardes si, à chaque fois, tu peux inscrire une carte donnée dans ce cadre.
M'enfin cela ne reste que des pistes de réflexion. Il n'y a rien de pire qu'un standard écrit à l'arrache au départ et qu'il faut ensuite maintenir par compatibilité pendant des décennies (sans exagérer).