PIC 16F beginner .. différence de syntaxe de programme lors de l'utilisation de différents compilateurs


9

Comme je l'ai mentionné, je viens de commencer la programmation de pic16f877a. Je peux maintenant travailler avec des affichages à 7 segments. À l'heure actuelle, j'utilise le compilateur ccs. Aucun problème avec ça. Mais je préfère être un programmeur indépendant du compilateur. Je veux donc simultanément travailler dans d'autres compilateurs comme IAR ou Hitechc. Je veux savoir si la "déclaration de déclaration de programme dans les compilateurs" autre que ccs sera différente? Veuillez me guider comment aborder cette chose. J'accueillerais toutes les formes de suggestions. Merci d'avance.

Réponses:


9

C'est génial que vous vouliez être indépendant du compilateur! Malheureusement, les compilateurs hitech et CCS pour les PIC bas de gamme utilisent de nombreuses déclarations de préprocesseur spécifiques au compilateur, des routines d'accès aux broches spécifiques au compilateur et, dans le cas des routines spécifiques au compilateur CCS, pour accéder aux fonctions essentielles telles que SPI, I2C, ADC, etc.

Il n'est pas possible d'écrire votre code pour qu'il ne soit pas spécifique au compilateur sans beaucoup de préprocesseur #define, #ifdef, #ifndef et ainsi de suite pour avoir accès à des parties spécifiques de ce que chaque compilateur propose. Cela rendrait votre code illisible.

La meilleure chose que vous puissiez viser est d'être indépendant de l'IDE et d'utiliser quelque chose comme l'éclipse, donc au moins vous utilisez le même IDE. Cela entraînera la perte des assistants CCS pour la configuration des fonctions de base, mais vous donnera une plus grande flexibilité dans l'utilisation du même IDE.

Une autre chose à considérer est que hitech et CCS n'ont pas (au moins dans le passé) un véritable éditeur de liens pour le compilateur c et vous obligent à utiliser "#include myfile.c" que je méprise personnellement ... mais c'est une autre histoire.

Je n'ai pas commenté le compilateur IAR car je n'ai utilisé que CCS et hitech. Les deux ont bien fonctionné, mais je n'ai jamais été vraiment satisfait non plus après avoir migré de la plate-forme Motorola (maintenant freescale) et utilisé le compilateur metroworks qui était plus avancé à l'époque. Le compilateur IAR semble bon mais je ne l'ai jamais utilisé.


Si vous pouvez gérer rester à ou au-dessus de pic18, vous devriez jeter un œil au compilateur c18. Il a un grand soutien. IAR abandonne le support PIC, ils ne vendront plus de licences avec maintenance.
Kortuk

J'ai cru comprendre que l'architecture PIC16 / 12/10 ne correspond pas très bien au langage C. Par conséquent, les compilateurs C doivent avoir des structures inhabituelles et non standard pour compenser l'architecture PIC. Le résultat final est qu'aucun des compilateurs n'interagit.
Connor Wolf

7

Si vous utilisiez des pièces PIC18, je recommanderais le compilateur C18 de Microchip. Il se conforme beaucoup plus étroitement à ANSI C que le compilateur CCS. Je ne suis pas sûr du compilateur Hi-Tech car je ne l'ai pas utilisé. Comme cela a été dit précédemment, si vous avez vraiment besoin de rendre le code indépendant du compilateur, vous devrez utiliser de nombreuses directives de précompilateur. Je recommanderais de jeter un œil à certains des exemples de programmes Microchip qui prennent en charge plusieurs compilateurs pour avoir une idée de la façon dont cela est fait.


c18 pour pic18, c30 pour pic24 et dspic, c32 pour pic32!
Kortuk

CCS est agréable en ce sens que certaines choses sont plus simples à faire (interruptions et temporisations, par exemple - tous les exemples Microchip vous ont écrit ASM pour que les interruptions fonctionnent correctement en C18), mais il est plus proche de l'ANSI C.
J.Polfer

Vous n'avez besoin que d'une instruction d'assemblage et c'est le GOTO qui est utilisé pour configurer le vecteur d'interruption pour pointer vers la routine de service d'interruption.
mjh2007

3

Malheureusement, vous trouverez qu'il est très difficile de trouver un programme indépendant du compilateur pour un microcontrôleur. Il y a plusieurs problèmes, en voici deux:

  1. Différences de périphériques, dénomination SFR, etc. (en particulier par rapport à d'autres processeurs, mais même avec des compilateurs de la même famille), et;

  2. Fonctionnalités non standard sur certains compilateurs comme la définition de bits individuellement ou différentes structures pour invoquer le code assembleur.

La série 16F est très limitée en termes d'architecture et n'est pas vraiment conçue pour supporter un compilateur C. C'est pourquoi il n'y a pas de CCG pour cela.


3

Jetez un oeil à SDCC . Il prend en charge de nombreux périphériques PIC16 et PIC18. GCC prend en charge PIC24 et dsPIC.


j'ai posé des questions sur les différences dans les déclarations lors de l'utilisation de différents compilateurs .. de toute façon, j'ai appris l'existence d'un autre compilateur 'sdcc' .. merci beaucoup ..
VV Rao

2

Les aspects les plus susceptibles d'être dépendants du compilateur sont:

  • en utilisant des bits simples (en particulier dans les ports IO)
  • tailles des entiers, et caractère étant signé ou non signé
  • pointeurs drôles: C18 différencie les pointeurs rom et ram :(
  • fusibles de configuration
  • attente occupée

Ma façon préférée de gérer cela est d'écrire des macros pour ces aspects et de demander au compilateur de sélectionner la macro appropriée en fonction des macros prédéfinies spécifiques au compilateur. J'ai fait une bibliothèque RFM70 et des exemples d'applications de cette façon qui fonctionnent sur PIC14 (HiTechC), PIC16 (C18) et ARM (GCC).

(mise à jour) Ma bibliothèque RFM70 est maintenant terminée. Il prend en charge C sur PIC 16F (compilateur Hitech), C et C ++ sur LPC11114 (Cortex) et LPC2148 (ARM7TDMI) (compilateur GCC) et Arduino (ATMega128, compilateur GCC). Ceci est généré (y compris la documentation doxygen) à partir de la même source en effectuant un prétraitement dans un script Python. Le support Jal est en cours de développement, peut-être que ProtonBasic suivra. http://www.voti.nl/rfm70

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.