Question

Je travaille sur un projet C intégré qui dépend de certains matériels externes. Je souhaite masquer le code accédant à ces pièces afin de pouvoir simuler le système sans utiliser de matériel. Jusqu'à présent, j'ai utilisé des macros, mais cela m'oblige à modifier légèrement mon code de production, ce que j'aimerais éviter.

Exemple:

stub.h
#ifdef _STUB_HW
#define STUB_HW(name) Stub_##name
#else /*_STUB_HW*/
#define STUB_HW(name) name
#endif /*_STUB_HW*/

my_hw.c
WORD STUB_HW(clear_RX_TX)()
{ /* clear my rx/tx buffer on target HW */ }

test_my_hw.c
#ifdef _STUB_HW
WORD clear_RX_TX()
{ /* simulate clear rx/tx buffer on target HW */ }

Avec ce code, je peux activer / désactiver le stubbing avec la balise de préprocesseur _STUB_HW

Existe-t-il un moyen de réaliser cela sans avoir à changer mon code prod et à éviter beaucoup d'ifdefs. Et je ne mélangerai pas le code produit et le code test dans le même fichier si je peux l'éviter. Je me fiche de l'apparence du code de test dans la mesure où je peux éviter autant que possible le code de production.

Modifier:

Ce serait bien s'il était possible de sélectionner / renommer des fonctions sans remplacer le fichier entier. Par exemple, prenez toutes les fonctions commençant par nRF _ ## et donnant ensuite un nouveau nom, puis insérant test_nRF _ ## dans nRF _ ## si possible.

Était-ce utile?

La solution

Je viens de créer deux fichiers ActualDriver.c et StubDriver.c contenant exactement les mêmes noms de fonction. En créant deux versions liant le code de production aux différents objets, il n’ya pas de conflits de noms. De cette manière, le code de production ne contient aucun code d’essai ou conditionnel.

Autres conseils

Comme Gerhard l’a dit, utilisez un fichier d’en-tête commun, "driver.h". et séparer les fichiers d’implémentation de la couche matérielle contenant les fonctions réelle et condensée.

Dans eclipse, j’ai deux cibles et j’exclue de la construction " le fichier driver.c qui ne doit pas être utilisé et assurez-vous que le bon fichier est inclus dans la construction. Eclipse génère ensuite le fichier Make au moment de la compilation.

Un autre problème à souligner est de vous assurer que vous définissez des entiers de taille fixe pour que votre code se comporte de la même manière du point de vue des débordements. (Bien que dans votre exemple de code, je vois que vous le faites.)

Je suis d'accord avec ce qui précède. La solution standard consiste à définir un ensemble abstrait opaque d’appels de fonction constituant le "pilote". au hw, puis appelez cela dans le programme principal. Fournissez ensuite deux implémentations de pilotes différentes, une pour hw, une pour sw. La variante sw simulera l’effet IO du hw de manière appropriée.

Notez que si l'objectif est à un niveau inférieur, c'est-à-dire l'écriture de code dans lequel chaque accès matériel doit être simulé plutôt que des fonctions entières, cela risque d'être un peu plus difficile. Mais ici, différents " write_to_memory " et " read_from_memory " des fonctions (ou des macros, si la vitesse sur la cible est essentielle) pourraient être définies.

Dans les deux cas, il n'est pas nécessaire de changer le nom des fonctions, mais simplement deux fichiers batch différents, des fichiers de création ou des cibles de construction IDE (en fonction des outils utilisés).

Enfin, dans de nombreux cas, une meilleure solution technique consiste à opter pour un simulateur de système cible complet, tel que Qemu. , Simics , SystemC , CoWare , VaST ou similaire. Cela vous permet d'exécuter le même code tout le temps et de créer un modèle de matériel qui fonctionne comme le matériel réel du point de vue du logiciel. Cela nécessite un investissement initial beaucoup plus important, mais pour de nombreux projets, cela en vaut la peine. Cela élimine fondamentalement le problème épineux d'avoir différentes versions pour la cible et l'hôte, et garantit que vous utilisez toujours votre compilateur croisé avec les options de génération de déploiement. Notez que de nombreuses suites de compilateurs intégrés intègrent certaines fonctionnalités de simulation de base.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top