Architecture d'une couche d'abstraction ?

[JuanLuis]

Bonjour à tous,

Je suis actuellement sur un projet qui vise à concevoir une couche d'abstraction matérielle.
Je m'explique. J'ai aujourd'hui un programme applicatif qui tourne sur une plateforme PIC18. Cette applicatif dans son fonctionnel comporte des communications avec un autre PIC par liaison SPI, il comporte aussi une communication en RS232. L'architecture actuelle en permet pas d'évolutivité, si par exemple on veut changer de type de communication (de SPI à I2C par exemple) on doit modifier directement la partie applicatif du code.

Mon objectif est donc de créer une nouvelle couche entre mon fonctionnel et mes drivers afin qu'en cas de changement de matériel je n'ai plus à changer mon fonctionnel. Cela doit rendre donc la fonctionnel plus générique et plus lisible.
Je veut suivre une démarche de conception plutot rigoureuse et penser a tout mon architecture avant de coder.

J'aimerai donc savoir si je m'engage dans la bonne direction avec mes choix.
Je pensais faire comme suit :

---------- Applicatif : Utilisation de fonction générique de base ------------
----------------- Init(nom_du_périphérique_utilisé) -------------
----------------- Lecture(nom_du_périphérique_utilisé, ...) ------
----------------- Ecrire(nom_du_périphérique_utilisé, ...) --------
----------------- Stop(nom_du_périphérique_utilisé) ------------

---------- Ma couche : Contient les fonctions génériques de base, celles-ci renseignent les éléments utiles, et appellent les fonctions des driver ---------------


---------- Mes drivers : Contiennent les routines d'utilisation des liaisons --------------

Le tout avec un fichier de configuration qui comportera les informations liées au projet, du style quelles sont les types de liaisons utilisées, les noms des périphériques associés, etc...

Ce que je me dis c'est que c'est trop simple
Le but serai par la suite de pouvoir externaliser cette nouvelle couche pour l'utiliser comme une bibliothèque. Elle comportera les appels pour plein de liaison différentes.

Donc voila j'aimerai avoir votre avis sur ce que j'ai marqué là , mais aussi savoir si j'ai une bonne démarche, si je ne loupe pas des étapes pour faire une conception propre ??? Et si j'ai tout faux dite moi comment je dois m'y prendre, quelles sont les étapes!?

Merci d'avance JL

[souviron34]

Bonjour

ton applicatif pourrait-il (devrait-il) gérer plusieurs drivers en parallèle ?

[JuanLuis]

Qu'entend tu par gérer plusieurs driver en parallèle??
Je pense pouvoir répondre OUI ! Le système comporte plusieurs types de communication. Par exemple il communique avec un périphérique par SPI, et avec un autre par RS232. les communications s’exécute les unes après les autres, il n'y en aura pas 2 en même temps.

J'ai revu un peu ma solution :

---------------
mon applicatif //ici on a des appel de fonction générique
---------------

---------------
ma couche // ici on a des appels de fonction spécifique
---------------

--------------- -------------- --------------- --------------

-----driver1 ------- driver2 -------- driver3 ------- driver_N

--------------- -------------- --------------- --------------

ensuite je pensais mettre un couche "transverse" à l'applicatif et a la couche d'abstraction qui sera spécifique au projet et qui permettra de regrouper les fonctions d'un même genre. Par exemple on pourra trouver dedans une fonction init_PIC() qui contiendra les appels des fonctions d'initialisation des PIC. Par exemple set_générique_PIC() qui elle sera implémenté dans la couche d'abstraction, et qui permettra de lancer la routine d'init pour le PIC spécifié en argument !

[souviron34]

moi je ferais :

applicatif

couche fonctionnelle

couche driver générique


couche driver générique :

à base de fonctions enregistrées (comme les "OnClick" pour des boutons dans une IHM)


Pour fabriquer/ajouter un driver, remplir les 4 fonctions spécifiques, avec une API standard (générique)

Dans la couche fonctionnelle :

if ( Driver_Is_Registered ( READ ) )
Call_Registered_Driver ( READ, ....)