J'écris du micrologiciel pour un pic32mx, en utilisant Hitech Picc32. L'un des problèmes que je veux éviter est que, puisque la plupart des épingles ont plusieurs noms (par exemple, an0 = rb0 = cn2 = pged1), je ou quelqu'un d'autre pourrait utiliser accidentellement RB0 sans se rendre compte que An0 est déjà utilisé. (Cela peut effectivement être catastrophique, car la configuration incorrecte d'une broche analogique / numérique peut entraîner un puits de courant excessif et une libération de fumée essentielle.)
Ainsi que documenter de manière exhaustive chaque code PIN utilisé, je me demandais s'il y avait un moyen rapide de dépasser cette question au niveau du codage. Je veux une macro que les gens (principalement moi-même) peuvent utiliser, disons (Je ne veux pas cela à tout prix, si la seule solution possible est trop horrible ou non encore horrible, alors je l'oublierai et je vais simplement développer une réputation pour éclater en larmes ou me mettre en feu ou quelque chose. Je suis aussi a vu cette question à propos de macros productrices de macro , qui règne cela.)
Je devrais clarifier: le code est écrit dans plusieurs unités de compilation (au moins, je pense que c'est ce que signifie la phrase signifie). J'ai un fichier .h / .c pour mon code A2D, de la même manière que pour SPI, et aussi de différents périphériques qui utilisent simplement certains ports d'E / S. L'espace n'est pas vraiment un problème, mon code laisse beaucoup de place sur le pic32mx; De plus, je peux utiliser un autre drapeau __debug pour supprimer le code de vérification des broches pour une utilisation finale. revendication_pin (58) , qui émettra un avertissement ou une erreur si elle est exécutée deux fois.
3 Réponses :
OK, ici. Aucun coût d'exécution.
#define CLAIM(n) char busy##n = 1;
#define CLAIM(n) void busy##n() {} // bdonlan
Cependant, cela seulement des erreurs s'ils sont dans la même unité de traduction.
#define CLAIM_PIN(n) void claimed_pin_#nn(void) {}
Cela utilise un octet par code PIN. Si c'est un problème, l'OP pourrait souhaiter examiner les options de liaison pour mettre ces définitions dans leur propre section et les déposer de l'image finale.
Cela fait si longtemps que j'ai utilisé une architecture où une octete importait, je n'avais même pas pensé à cela.
Mais ça n'a pas d'erreur. C'est parfaitement légal C de le faire, même dans plusieurs unités de compilation.
Que diriez-vous d'utiliser une fonction au lieu d'un caractère?
Si vous pouvez vous permettre les frais généraux d'exécution ou si cela est juste pour le débogage, je créerais simplement quelque chose comme un D'autre part, La réponse mise à jour de Mark Ransom valait la peine A +1. iopinopen () fonction qui a gardé la trace des broches utilisées au lieu de traiter avec la macroques .
Pas de réponse, mais bonne question. (Je suppose que cela pourrait être plus facile si les microchips ont quitté leurs mégots et pris en charge C ++.)
Eh bien, ils n'ont pas de compilateur Linux de toute façon, il est donc hitech pour moi (je préfère quand même leurs macros).