Que dois-je savoir lorsque je crée une bibliothèque pour l'Arduino?

8

Il me vient à l'esprit que, au-delà de mon problème actuel, je dois demander: "Que dois-je savoir lorsque je crée une bibliothèque pour l'Arduino?"

Tout d'abord, ce que je fais:

J'utilise Eclipse comme éditeur et j'écris du code en C ++. J'ai écrit une simple application Arduino qui inclut mon fichier d'en-tête et je travaille sur les erreurs.

Premier problème: comment faire un «build clean»? Je vois des erreurs que je pense avoir corrigées, presque comme si le fichier d'en-tête était mis en cache. (Oui, je fais probablement quelque chose de stupide [ edit : J'étais], mais j'aimerais quand même savoir comment nettoyer la bibliothèque, et je ne sais pas où sont les fichiers objets).

Deuxièmement: quelles conventions dois-je connaître? Je n'ai pas utilisé l'Arduino autant que je le souhaiterais, et cela fait du bien de programmer en C ++, mais je sais que l'intention des bibliothèques est de garder les choses agréables et simples pour les utilisateurs. Existe-t-il des conventions pour les noms de fonction? Créer des constantes (il semble que l'espace de noms global soit pollué par #defines)? Etc.

Enfin, y a-t-il autre chose que je devrais savoir?

Je dois mentionner que j'ai regardé le didacticiel de la bibliothèque Arduino , ce qui est bien, mais ne va pas très loin. J'ai également jeté un œil à certaines des bibliothèques installées sur mon système.

Clinton Blackmore
la source
1
Avez-vous essayé l'IDE Arduino et y avez renoncé? Je sais qu'étant donné l'ensemble général de fonctionnalités de productivité du programmeur d'Eclipse-as-IDE, Arduino-IDE ne fait plus rien. Cependant, dans cette situation, si vous n'avez pas essayé Arduino-IDE, vous aimerez peut-être le faire. Bien que je trouve cela lent, mais les recompilations explicites fonctionnent, tout comme elles le devraient.
icarus74

Réponses:

3

Je vais essayer. Je n'ai pas écrit de code pour Arduino, mais j'ai fait beaucoup de programmation en C et C ++. Il serait utile que je voie vos erreurs, mais néanmoins.

La principale chose dont vous devez toujours vous souvenir lorsque vous utilisez C ++ avec du code C est que votre code C ++ a besoin de fonctions déclarées avec "extern" C "" si vous voulez que le code C puisse se lier au code C ++. Le "extern" C "" indique au compilateur C ++ que je crée du code pouvant être lié pour des fichiers C ou que j'utilise du code à partir de fichiers C. Donc, toutes vos fonctions dans l'en-tête de l'API de la bibliothèque doivent être en corrélation avec une fonction du fichier source défini comme "extern" C "void dosomething ()". Si vous essayez d'utiliser des classes en C ++, n'oubliez pas que le code C ne peut pas l'appeler, vous devrez créer des fonctions (extern "C") pour accéder à l'objet. Maintenant, si votre code C est compilé avec un compilateur C ++, alors ne vous inquiétez pas pour "extern" C "".

Si vous souhaitez appeler du code C dans votre code C ++, vous devez envelopper l'en-tête C avec une construction comme celle-ci:

#ifdef ___cplusplus
extern "C" {
#endif

///all my C function declarations... yada yada

#ifdef __cplusplus
}  //end extern "C"
#endif

Si vous travaillez en C ++, n'utilisez pas beaucoup de #defines, sauf si vous créez des indicateurs de compilation comme "DEBUG" ou "VERSION2" pour créer des ensembles spéciaux de code. Sinon, utilisez "const int / char / float" pour les définitions de nombre pour une vérification de type sûre. Les compilateurs sont généralement assez intelligents pour les optimiser, ils se retrouvent donc dans l'espace ROM / code (cela dépend cependant). Aussi, ne créez pas de MACROS, utilisez des fonctions en ligne. En outre, ne suivez pas toujours les conventions lors de la programmation si c'est stupide, comme l'utilisation de nombreuses macros et définitions de nombres en C ++. La même chose s'applique à la version C99 de C, il a ajouté des choses comme les fonctions en ligne et les consts de C ++. L'industrie se rend compte de la quantité de code bogué et difficile à maintenir provenant de la surutilisation du langage du préprocesseur.

Eclipse stocke généralement les fichiers obj dans un répertoire sous votre projet. Si vous faites une build "Debug", elle se trouve sous le dossier "Debug" sous votre dossier de projet. Si vous faites une version "Release", regardez sous "Release", etc. Normalement, une version propre fonctionne pour moi dans Eclipse, donc je ne sais pas ce qui ne va pas avec votre configuration. Je suppose que assurez-vous que vous ne créez pas d'en-têtes précompilés.

Jay Atkinson
la source