Discussion :

[JuanLuis]

Bonjour,

Je suis en train de développer une couche d'abstraction matériel sur PIC18f qui doit gérer les communications entres 2 PIC par exemple en SPI, I2C, CAN, ......

Je m'explique :
Aujourd'hui j'ai un code applicatif qui, entre autre chose, communique avec un autre PIC par liaison SPI. Le code applicatif appel directement le driver, avec des commandes spécifiques.
Mon but est d'ajouter une couche logiciel entre le driver et l'applicatif afin de pouvoir utiliser seulement des commandes génériques dans mon applicatif .
Par exemple: Ecrire(périphérique_1,Donnée_a_écrire);
Par la suite je voudrai aussi que ma couche logiciel soit réutilisable par d'autre projet pour gérer d'autre type de communication ; RS232,CAN,I2C,USB......

Mon problème est donc de trouver une solution qui me permet d'associer un nom quelconque de périphérique à un type de communication pour ensuite retrouver les bons paramètres à envoyer au driver. Tous cela en faisant en sorte que, pour ajouter un périphérique avec un type de communication différentes, le code soit simple à reprendre.

Pour assigner un type de communication à un périphérique je pensais simplement utilisé les #define : #DEFINE périph_1 N , puis avec une structure en Switch->case je peux décider quel protocole lancer.
Mais justement pour lancer le protocole il faut des arguments qui sont différents en nombre et en type suivant si c'est de l'I2C, du SPI ou autre.
Je pensais ici utiliser une structure, si je fais une structure "Périphérique" déclaré en globale, avec plein de champs différent, typiquement ; nom_périphérique,adresse-périphérique,donnée,vitesse, longueur, etc.... est ce que cela peut fonctionner??? Et-ce possible de l'envoyer en arguments au driver?

Je me dit que du coup pour rajouter un périphérique a la couche d'abstraction, il suffira de compléter la structure, lui rajouter des champs si cela est utiles, et juste rajouter un switch->case avec les assignations des champs de la structure. Cela vous semble-t-il cohérent??

Je doit faire attention a la place mémoire, je suis sur PIC donc je n'ai pas non plus énormément de ressource! Les structures ne demandent-t-elle pas bcp de place???? Est-ce que je dois allouer de la mémoire avant leur exécution? ou au contraire en libérer a la fin de chaque utilisation ???

Voila je voudrai bien avoir des avis la dessus ! Dsl pour le roman, j'espère au moins avoir été clair !!

[Guyt54]

Si je comprends bien, tu veux écrire une couche de plus haut niveau qui fait abstraction de la couche de plus bas niveau, ce qui est très bien.

Ce qui est moins clair pour moi est comment tu vas faire le lien entre la couche supérieure et la couche inférieure va se faire. À la compilation ou à l'exécution?

Si c'est à la compilation, y a moyen de faire ça assez "clean" en y allant avec de la programmation modulaire, où tu ramènes à quelques fonctions de base les fonctions accomplies par tes périphériques, genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8

void Init(param variables) ;
void Done(void) ;

void PutChar(char car) ;
bool CharIn(void) ;
char GetChar(void) ;

Ton protocole de plus haut niveau s'occupe du reste, par exemple des fonctions de plus haut niveau, genre "SendPacket" et "GetPacket", qui appelleraient les fonctions de base "PutChar", "CharIn" et "GetChar".

Pour un projet donné, tu sélectionnes le module du périphérique désiré, le module plus général et l'affaire est chocolat.

Si tu veux faire le choix du périphérique à l'exécution, là, c'est plus compliqué et c'est lourd, puisque tu vas trainer avec toi du code que tu n'utilises pas nécessairement. Ton approche "switch case" ne me semble pas optimale, non plus. J'irais plutôt avec des pointeurs de fonctions, à défaut de pouvoir utiliser une classe avec des fonctions virtuelles pures.

Chose certaine, les restrictions software qu'imposent le hardware des PIC ne facilitent pas les choses...J'ai travaillé pendant longtemps avec les PIC avec mes étudiants et ciel, quel cauchemar.

[JuanLuis]

Merci pour la réponse mais j'ai pas tout saisi quand tu parles de programmation modulaire !!

Pour réexpliquer rapidement, je voudrai dans mon applicatif (le plus haut niveau) que 2 instructions génériques, typiquement :
Ecrire ou Lire(nom_périphérique,data)

Ensuite la 2ième couche ferai le lien entre le "nom_périphérique" et le réel type de communication à utiliser, soit SPI, soit I2C, etc .... et s’occuperait de mettre a jour une structure qui contiendrai pleins de champ utile pour la liaison. Pour ensuite passer cette structure en arguments à un driver qui, lui, devra prendre dans la structure les éléments dont il a besoin (adresse_périphérique, longueur, vitesse, data), bien sur en passant un pointeurs et non pas la structure.

Et oui voila pour un projet donné, quand j'aurai réussi à rassembler plein de type de communication, il n'y aura plus qu'a utilisé un fichier de config en mettant ou non les #DEFINE qui vont bien, pour compiler les bonne parties du code!!

Je suis en C je ne peux pas utiliser les classes!?!?

Donc voila sur le papier ca me parrait pas mal, mais je ne suis pas sur de mon coup! Donc je recherche pour l'instant tous les renseignements possible qui pourront m'aider!

[Bktero]

Je partage l'avis de Guyt54 sur la programmation modulaire. C'est probablement la meilleure solution pour limiter l'empreint mémoire en ne sélectionnant pour un projet donner que les parties de code correspondant aux protocoles utilisées.

En gros, pour reprendre ton exemple de structures globales pour gérer les protocoles :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#ifdef UTILISER_UART
struct
{
    int baudrate;
    int parity;
} UART;
#endif

#ifdef UTILISER_CAN
struct
{
    int nb;
    int jenesaisquoiencore;
} CAN;
#endif

Le fichier source contenant ce code est inclus dans tous les projets. Si dans un nouveau projet, tu as besoin de l'UART mais pas du CAN, tu feras #define UTILISER_UART quelque part ou tu passeras comme option à ton compilation -DUTILISER_UART. Ainsi, à la compilation, la structure UART sera disponible pas la structure CAN. D''ailleurs, tu l'as dit toi même :

Et oui voila pour un projet donné, quand j'aurai réussi à rassembler plein de type de communication, il n'y aura plus qu'a utilisé un fichier de config en mettant ou non les #DEFINE qui vont bien, pour compiler les bonne parties du code!!

Ensuite la 2ième couche ferai le lien entre le "nom_périphérique" et le réel type de communication à utiliser, soit SPI, soit I2C, etc

Sur un coup comme ça, je pense que tu seras obligé de passer par des #define pour configurer chaque projet et associer ainsi un périphérique à un type de protocole et aussi les pattes utilisées (ex : un µC avec plusieurs UART).

Je suis en C je ne peux pas utiliser les classes!?!?

Non. Il te faudrait faire du C++, je ne sais pas si ça existe pour les PICs (ça existe pour d'autres marques, on m'en a parlé). Ca serait bien pratique dans ton cas je pense.

[JuanLuis]

Okay je vois que je pense à peu près logiquement.

Oui je vais devoir faire un "config.h" pour définir chaque lien entre les noms et les protocoles!
Pour l'utilisation du C je n'ai pas le choix, en fait je m'appuie sur un projet existant d'une balise de détresse, je ne peux pas modifier le fonctionnel de ce projet. Cela entraine le fait aussi que mon code doit être robuste!

Je viens de voir un autre problème là!
Par exemple pour l'utilisation de la liaison SPI, en ecriture par exemple, j'envoi d'abord mon adresse de périph, puis ensuite je recommence l'opération mais en envoyant une ma donnée. Or mes deux longueurs peuvent être différentes, entre l'adresse et la donnée. Et l'utilisation de la SPI requiert de savoir la longueur du mot a transmettre. est ce que une fonction du type STRLEN peut me donner la taille de n'importe quel type de donnée???