Conseil pour un compilateur PIC.

[inviteb9f49292]

Bonjour à tous.

Je suis informaticien, je connais plutôt bien le langage C, et j'ai déjà pas mal d'experience avec le compilateur GCC, sous UNIX ou en plus bas niveau avec eCos sur ARM7 par ex.
J'ai dû me mettre au PIC (série 18f) récemment, et j'avoue que j'ai été plus que dérouté par l'utilisation du compilateur C18 de MPLAB, quelques exemples:
-impossibilité d'utiliser la valeur de retour d'une fonction directement comme argument d'une autre fonction,
-difficulté a appeler une fonction depuis un gestionnaire d'interruption (pourtant basique),
-impossibilité d'utiliser des "const char*" en argument de "printf", il faut passer par des "#define",
...etc...
Je me demandais donc si je ferais face au même genre de problème en investissant dans un compilateur du type IAR ou Hi-Tech, c'est pour un usage professionnel, donc un investissement de 500/1k € est envisageable si nécessaire. Faut-il que j'oublie mon passé de développeur "haut-niveau"?
Ou bien (comme j'ai pu le lire dans certains forums), qu'effectivement MPLAB pour la série 18f n'est pas franchement au point.

Quels sont vos avis sur la question?

D'avance merci
-----

[RISC]

Salut,

Ton expérience semble être plutôt avec des "gros" processeurs (32bits) probablement avec mémoire externe. Le compilateur C18 est très stable et utilisé par beaucoup car il est gratuit (en version non optimisée).
Pour les microcontroleurs, comme les PIC18, la mémoire FLASH et surtout RAM est beaucoup plus limitée. Il faut donc "manipuler" avec soin les données.

Pour répondre (partiellement) à tes remarques :
-impossibilité d'utiliser la valeur de retour d'une fonction directement comme argument d'une autre fonction,
=> je ne vois pas de raison à cela. Il faudrait voir un exemple précis

-difficulté a appeler une fonction depuis un gestionnaire d'interruption (pourtant basique),
=> Je le fais très couramment et cela fonctionne très bien...à condition de savoir sauver le contexte adéquat...en fonction des fonctions que tu appelles

-impossibilité d'utiliser des "const char*" en argument de "printf", il faut passer par des "#define",
=> j'utilise rarement les printf sur les petits micros car beaucoup trop gourmands...La "technique" des Printf n'est généralement pas adaptée au débogage pour les 8 bits car elle "coute" beaucoup de taille FLASH.

Il existe un webseminar très bien fait sur les interruptions dans le C18.
Une formation dédiée au compilateur C18 pourrait aussi t'aider à bien comprendre les techniques de Debug et les sauvegardes/restorations de contextes dans les interruptions.
Tu peux aussi te faire aider sur le forum dédié au C18.

a+

[inviteb9f49292]

Merci de ta réponse.

Pour expliciter un peu mieux mon problème existentiel, il faut que je précise que ce n'est pas moi qui développe sur le PIC, nous avons embauché quelqu'un pour ça, mais comme il débutte en C, j'ai essayé de lui inculquer les méthodes de travail que j'utilise (désolidariser tuyau de communication et protocole, faire des modules logiciels indépendants etc...). Et nous avons perdu un temps fou à trouver des "magouilles" pour que le code fonctionne... Comme nous sommes sur le point de commencer un nouveau projet faisant appel au 18F, je voudrais éviter de retomber dans les même travers. Malheureusement, je ne peux être très précis sur mon ressenti car:
-il date de quelques mois maintenant,
-je n'intervenais que de manière sporadique lorsque mon collègue bloquait.

Voici néamoins un semblant de précisions sur mes vagues souvenirs:

-impossibilité d'utiliser la valeur de retour d'une fonction directement comme argument d'une autre fonction,
=> je ne vois pas de raison à cela. Il faudrait voir un exemple précis

Je vais essayer d'expliciter par un pseudo-exemple:

int foo (int n) {
   return n + 1;
}

int bar (int n) {
   return n + 2;
}

void main (void) {
   int n = bar (foo (2));
}

si avec la surveillance de variable du debugger je surveille la variable "n" du "main" j'ai n'importe quoi... Et ce n'est pas le debugger qui est perdu car le programme fait effectivement n'importe quoi avec ce type de code.

-difficulté a appeler une fonction depuis un gestionnaire d'interruption (pourtant basique),
=> Je le fais très couramment et cela fonctionne très bien...à condition de savoir sauver le contexte adéquat...en fonction des fonctions que tu appelles

J'avais compris l'histoire du contexte différent a utiliser pour sauvegarder, mais malgré cela, si je bombarde le PIC avec 2 interruptions différentes, il arrivait que ce dernier se plante lamentablement, voir redémarre...

-impossibilité d'utiliser des "const char*" en argument de "printf", il faut passer par des "#define",
=> j'utilise rarement les printf sur les petits micros car beaucoup trop gourmands...La "technique" des Printf n'est généralement pas adaptée au débogage pour les 8 bits car elle "coute" beaucoup de taille FLASH.

Même (et surtout) en utiliseant la bibliothèque de communication série fournie avec C18, j'avais des drôles de problèmes, il fallait utiliser des #define ou des "const char[]"...

J'ai bien conscience qu'un 18F n'est pas un ARM7, mais des choses comme l'arithmétique de pointeurs etc... me semblent plus être en rapport avec des problèmes éventuels du compilateur qu'un manque de puissance.

Bref, j'ai ton avis qui semble positif sur C18, je doit donc être trop formaté informaticien... Que veux-tu personne n'est parfait....

Merci pour ton avis, si quelqu'un d'autre a quelque chose à dire, je suis prenneur
A+.

[carcan]

Salut !

je travaille avec le compilateur CCS PCWH, j'en suis très content, bcp de fonctions bien pratiques pour les PIC, fourni avec un gros manuel reprenant toutes les fonctions.

Par contre, je ne sais pas si on trouve une version démo ...

A+
Laurent

[A voir en vidéo sur Futura]

[inviteb9f49292]

CCS PCWH

J'ai lu à plusieurs endroits que ce compilateur était très loin d'une conformité au C ANSI, ce qui le rends assez peu intérressant à mes yeux... Mais merci de ta suggestion.

[carcan]

Salut !

je programme bcp en C et en Labwindows CVI et je n'ai aucune difficulté pour passer de l'un à l'autre.
il y a des petites différences ... par exemple quand tu déclares un "int" c'est un entier 8 bits, pour l'avoir en 16 bits tu dois déclarer un int16, ... mais on se fait très vite à ce genre de petites différences.

le gros avantage c'est les routines toutes faites ... par exemple envoyer le signal d'un capteur sur un port série : printf ("Signal : %f Vdd\n",Tension);
La syntaxe est la même qu'en C ! Le même vers un port USB qui émule un port série : printf (usb_cdc,"Signal : %f Vdd\n",Tension); facile !!!!!!!

Je n'en changerais en aucune manière ... en plus tu peux l'intégrer dans MPLAB et utiliser directement un programmateur comme le PicKit3.

A+
Laurent