Bonjour,
Je souhaiterai savoir si quelqu'un connaitrait une manière de programmer des PIC12F en langage C s'il vous plait. J'ai un petit programme très basic en C que je dois mettre sur un petit micro, j'ai choisi pour se faire un PIC12F675. J'ai fait mon programme sur un PIC18F1320 pour voir si ca correspondait aux critère de mon patron, mais je n'ai pas de compilateur C pour 12F, j'ai le compilateur mcc18 et MPLAB.
Si quelqu'un peut m'aider je l'en remercie d'avance.
Bonsoir
Va à cette adresse et tu trouvera un compilateur gratuit. Tu peux l'utiliser pour quelques numéros de PIC dnt des pic 12fxxx
http://www.htsoft.com/downloads/demos.php
Espérant combler ton besoin
si c'est vraiment "très basique", fait le en assembleur... L'assembleur des pics est vraiment très simple à apprendre et a utiliser. Il y a très peu d'instructions. Personnellement je programme en C sur différentes machines, mais avec les PIC, je fais tout en assembleur, même pour les programmes pas très "basiques"...Envoyé par calibraflo
Bonjour,
Je rejoins l'avis de mat64 en te conseillant de plutôt développer en assembleur, si ton programme est très basique.
En effet, tu prendras plus de temps pour :
- Trouver un compilateur adéquat
- Apprendre les spécificités de ton compilateur (ils ne se valent pas tous, loin de là)
- Assimiler tout de même le datasheet de ton PIC, et faire la correspondance avec les librairies de ton compilateur (ex : PORTA,0 <=> PORTAbits.RA0)
Enfin, pour répondre à ta question, je peux te conseiller le compilateur libre et gratuit SDCC pour de très simples programmes sur PIC12/16 !
(il convient d'avantage aux PIC18)
A+
calibraflo,
Un très bon compilateur ANSI C (payant) pour les 12F675 est celui de Hitech dont le lien a déjà été donnée dans un post précédant.
Si la compatibilité ANSI n'est pas primordiale, tu peux utiliser le compilateur C de CCS beaucoup moins cher (mais non compatible ANSI C) :
http://www.ccsinfo.com/
a+
+1 pour SDCC !
-1 pour l'ASM !
<< Le C, c'est bon mangez-en >>
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Je reste sur ma position. Attention, ça dépends de la complexité du prog, mais pour une appli simple l'assembleur du PIC est vraiment agréable. Je ne suis pas du tout anti-C, puisque je l'utilise quand l'appli le justifie.
Bon, tant qu'a faire je vote pour l'open source : vive SDCC.
Et pourquoi donc ne pas l'utiliser tout le temps ?
PS: je suis pas du tout anti-asm ... mais j'en ai mangé plus que de raison étant jeune ( jusqu'a ce que les compilos ne deviennent ce qu'il sont aujourd'hui : de meilleur codeurs que nous ... )
Par contre 100% ok pour dire que l'on devrait toujours faire un minimum d'ASM dans sa vie, ne serait-ce pour savoir comment ça se passe en dessous ...
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
C'est vrai qu'il y a longtemps que je n'ai pas ré-évalué les compilos... La dernière fois que je l'ai fait, j'avais un taux d'expansion de 50 % !! Alors pour un prog simple écrit en 1 heure en assembleur, sur un proc aux ressources pas vraiment "bling-bling", je voyais pas l'intérêt... Mais si tu me dis que maintenant les compilos font mieux que nous (), je vais me pencher sur la question !
D'ailleurs quand tu dis ça, c'est une impression, ou t'as fait des tests ?
C'est depuis que j'ai codé des compillos et que j'ai vu comment ils fonctionnent ...
Sur une routine bien donnée, l'ASM PUR sera quasiment toujours plus rapide, parfois de pas grand choses, parfois beaucoup ( mais il faut comparer avec un bon code C aussi ... qui donc génèrera du code quasiment identique ... ) ... hors perso, j'ai jamais été limité par la puissance de mon uCPU, par contre, le temps manque toujours lui ...
http://fr.wikipedia.org/wiki/Assembl...age_Assembleur
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
la, je m'incline...j'ai affaire à du gros calibreC'est depuis que j'ai codé des compillos et que j'ai vu comment ils fonctionnent ...
on est bien d'accord.
+1 . Quand je vois comment codent certains... (ceux qui n'ont jamais codé en assembleur peut-être ?
Ah bon, c'est écrire le code qui te prends le plus de temps à toi ? Moi c'est écrire le cahier des charges, la doc, traquer le bug qui se manifeste 1 fois sur 1000 (et encore seulement les jours de pleine lune) ... Alors passer 3 jours à coder au lieu de 2 j. avec du C ... Si ça me permet de gagner un peu sur les perf du système...perso, j'ai jamais été limité par la puissance de mon uCPU, par contre, le temps manque toujours lui ...
Mais enfin, ne polémiquons pas : j'ai l'impression qu'on est d'accord sur le fond, même si tu as tendance à dégainer le C un peu vite à mon goût !
Au fait : toutes mes excuses à calibraflo pour avoir pris son post comme salle de bavardages.
Enfin, pour être un peu plus complet sur le sujet, il faut dire que la bonne solution est souvent le mix C/asm quand on fait de l'embarqué. Le programme principal et toute sa cuisine en C, et les routines sensibles en assembleur. C'était bien souvent l'option gagnante il y quelques années quand je programmais des DSP (ces proc ont des particularités, avec pas mal d'optimisations à faire dues à leur architecture)
Je pense aussi qu'on est d'accord ... et que comme tu le dis, la suite est une question de gout ...
+1
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Merci à tous pour vos réponses. Je ne sais pas manier l'assembleur comme il faut, il est basique quand je le fais en C mais je ne vois pas ce que ca peut donner en assembleur. J'ai trouvé un compilateur C pour le 12F675, il y en avait d'autres de la même série, du coup je suis allé voir le moins cher et j'ai pu compiler mon programme en C. Il me reste plus qu'à le programmer, le seul truc c'est que j'ai un kit PICDEM2+ et je ne peux pas les programmer ces petites bêtes. Il faut que je trouve un autre support sur internet. En parlant de cette carte, quelqu'un serait comment faire pour faire fonctionner un 18F1320 à 40MHz sur cette carte? J'ai mis un quartz de 10MHz avec deux condensateurs de 15pF et j'ai activé la PLL par 4, comme j'ai pu le trouver sur internet, cependant après avoir fait ca, mon PIC ne répond pas. Je ne peux même pas activé une ligne d'un port. Si quelqu'un peut m'aider?
Manipuler un compilateur C ne dispense malheureusement pas de connaitre l'architecture de la cible sur le bout des doigts...
Je pense surtout aux fusibles de configuration, que je suspecte de ne pas être correctement configurés, voire pas du tout.
De ce côté, la syntaxe change d'un compilateur à un autre, voire d'une version à une autre du même compilo...
Ensuite, il faut veiller à bien régler tes registres associés à la gestion de l'horloge de ton PIC, là encore, cela dépend de ton compilateur.
Donc je te conseille d'éplucher la doc de ton PIC et de ton compilateur pour venir à bout de ce genre de soucis !
c'est bien ce que je disais, c'est nul le C !
je plaisante bien sur
Merci pour les réponses mais je me suis affolé un peu trop vite, j'avais mis mon sous programme d'initialisation en commentaire, je ne sais plus pourquoi mais bon. Je suis retombé sur mes pieds. Ce qui me pose problème maintenant, ce sont mes variables qui change de valeur et qui ne correspondent à rien, je ne sais pas d'ou cela peut venir, je continu à chercher. Je pensais a des parasites, une histoire de CEM, mais meme en faisant une petite cage de faraday, le système réagit pareil. Pour ce qui est de la configuration, il n'y a pas de problème j'ai configurer tous mes registres.
d'après ma propre expérience (qui n'est pas forcement une référence), quand tu as des valeurs erronées dans les registres :
- 99,8 % du temps c'est une grosse c****** dans le programme
- 0.19 % du temps c'est la CEM ou ce genre de phénomène para normaux
- 0.01 % du temps c'est un bug du compilo ou de la release du proc.
Donc vérifie, revérifie, débogue, émule, ça vient surement de ton prog
Salut,
Pour ceux que les compilateurs intéressent, je viens de trouver cette annonce de HiTech qui semble avoir amélioré fortement son compilateur pour les petits PICs. Ca semble très prometteur...et très accrocheur...(ils tapent sur la competition en passant...;=)
============================== =========================
We are very pleased to announce the Public release of our new ANSI C Compiler, with Omniscient Code GenerationTM supporting the PIC10/12/16 MCU family.
Denser Code, Better Performance
This ANSI C compiler achieves nearly 2X the code density and 38% better RAM usage than IAR’s compiler for PIC16/17, and 30% better code density with 80% better RAM utilization than CCS’ PCM C without using any C-extensions or assembly code. By optimizing interrupt-related contexts, the OCG technology in this new compiler reduces interrupt latency by 40% to 60%.
HI-TECH C PRO for the PIC10/12/16 MCU Family with OCG:
· Automatically handles memory banking without requiring special qualifiers;
· Optimizes the size of each pointer variable in your code based on its usage;
· Eliminates the need for many non-standard C qualifiers and compiler options;
· Produces more optimal interrupt context switching code;
· Customizes the functionality of the included printf library function;
· Automatically analyzes user assembly and object code files;
· Integrates into the MPLAB® IDE, MPLAB ICD2 and most 3rd-party development tools;
· Integrates HI-TECH Software's IDE, HI-TIDE™ 3;
· Includes Library source - for standard libraries and sample code for I/O drivers;
· Includes macro assembler, linker, preprocessor, and one-step driver; and
· Runs on multiple platforms including Windows (up to Vista64), Linux and Mac OS X.
============================== =======================
a+
mazette... c'est pas rien comme améliorations... si ils disent vrai, c'est que j'avais raison : les compilos C sont (étaient ?) vraiment mauvais
J'adore ta répartition
... Mais tu as oublié une statistique :
Bien 90% du temps
Je travaille en ce moment même sur un projet de plus de 14000 lignes en assembleur PIC18, et je peux t'assurer que pour de nombreuses raisons, j'aurais apprécié un compilo, même mauvais...mazette... c'est pas rien comme améliorations... si ils disent vrai, c'est que j'avais raison : les compilos C sont (étaient ?) vraiment mauvais
bien sur, c'était juste pour faire un peu de comique de répétition, suite à la discussion avec seb26 un peu plus haut dans ce fil. D'ailleurs c'est justement ma position : suivant la complexité et la nature du programme, on fait soit de l'assembleur, soit du C, soit un mix C/asm.Je travaille en ce moment même sur un projet de plus de 14000 lignes en assembleur PIC18, et je peux t'assurer que pour de nombreuses raisons, j'aurais apprécié un compilo, même mauvais...
au fait, pour ton projet de 14000 lignes, qu'est-ce qui te retiens pour 'utiliser le C ?
Je l'avais bien compris ainsi
Mais cela m'a juste rappelé la dure réalité qui m'attend au boulot
... Le patron
Au début, malgré nos conseils répétés, il ne voyait pas l'intérêt d'investir dans des licences pour des compilos (on est 2 sur le projet...), et maintenant que le programme a grossi, et bien on ne peut plus passer au C !
D'ailleurs c'est une chose que j'aimerais bien savoir : je pense que le fait de développer des modules en assembleur, en code relogeable, ne suffit pas à permettre de cohabiter avec un programme en C.
Il faudrait, peut-être, pour cela prendre aussi en compte les spécificités du compilo, comme par exemple SDCC qui utilise les registres PRODH et PRODL pour stocker les valeurs de retour de fonction...
J'aimerais beaucoup avoir des retours d'expérience sur de la cohabitation assembleur/C ?!
Je pense en particulier pour des raisons autres que de ponctuelles optimisations (sous forme de petites sections d'assembleur in line), mais dans le cadre de vastes projets dont la proportion des deux langages est importante !...
Salut Lolomatic,
Ecrire 14000 lignes en assembleur aujourd'hui ca relève du délire !!!!
Ton patron a pas du toucher une ligne de programme depuis des lustres...
Quelques petits chiffres basés sur des études pour des programmes conséquents (plusieurs milliers de lignes) :
temps de développement ASM = 5 x temps de développement en C (voila le vrai coût du développement qui monte à la surface...)
Lisibilité pour une tierce personne = 30% versus 70%
Ton patron a peut-être économisé sur les licenses mais en 2 jours il aurait déjà remboursé les licenses....
Concernant tes questions concernant le mix C + ASM:
1/ Le fait de travailler en relogeable est indispensable
2/ La meilleure méthode n'est PAS l'assembleur en ligne mais des fichiers assembleurs séparés. La raison est simple :
l'assembleur en ligne a une syntaxes très restrictive, certaines instructions sont parfois interdites (goto ou jump), et c'est totalement illisible si on veut faire des macros...quand c'est possible.
3/ concernant le passage des informations entre le C et l'assembleur, il est fortement recommandé de comprendre quels registres / zone mémoires le C utilise de façon à utiliser autant que possible les registres inutilisés pour éviter des sauvegardes / restaurations.
Donc si tu as déjà écris un programme en assembleur, il est toujours possible de le réutiliser avec un programme en C mais il ne sera probablement pas optimisé comme il l'aurait été si du début la décision était faite d'utiliser les 2.
Si on prend le cas concret du C18, il suffit je crois pour utiliser une variable en ASM de faire précéder son nom d'un _ :
en C --> TOTO devient _TOTO en ASM
De cette manière on passe du C à l'ASM très facilement.
La ou cela se complique c'est bien sûr pour les tableaux, mais tu peux travailler avec des pointeurs ;=)
Dans certains cas comme le controle moteur, on écrit 90% en C et la boucle critique de régulation parfois en ASM pour autoriser des rotations plus élevées.
a+
Dernière modification par RISC ; 06/04/2008 à 19h28. Motif: addition
Salut
Je viens de regarder (je sais, FSG c'est pas bien pendant le boulot
A l'heure actuelle : 17214 lignes "utiles" qui forment le binaire sur lequel je travaille.
(valeur lue lors de la compilation)
Il s'agit d'une application utilisant des modules optionnels qui représentent bien autant de lignes mais qui ne sont pas systématiquement compilés. Il s'agit de modules compilés sur conditions mais jamais utilisés en même temps (le travail de codage a été néanmoins quand même réalisé).
Un comptage de l'ensemble des lignes des fichiers ASM du répertoire du projet donne le résultat ahurissant de...
34669 lignes !!!
A noter que ce dernier score est obtenu en comptant également les lignes de commentaires et les autres lignes "non utiles" (#define, EQU, et autres mots clés).
Pour les licences, on dira que la direction a ses raisons que la raison ignore...
La preuve de l'économie a effectivement été donnée dès la réalisation de la librairie I2C en une semaine! Librairie qui est déjà implémentée dans la plupart des compilos (se trouve en assembleur aussi mais c'est pour l'exemple...)
C'est bien ce que je pensais.
Coder en C n'interdit pas l'utilisation de l'assembleur, et permet d'être bénéfique sur de nombreux plans, à condition de comprendre et maîtriser l'outil efficacement.
Et c'est pour cela que je code avec le datasheet du pic et la doc du compilo à disposition.
D'ailleurs au final, je me dis qu'un seul code assembleur sera généré pour obtenir le .HEX, quels que soient les langages utilisés pour le générer !...
A+
Fallait lui proposer un compilo gratuit
+1 pour RISC
une cht'ite remarque quand même :
surement vrai en moyenne, indiscutablement vrai pour les gros programmes, mais souvent le micro a une petite fonction bien précise et la le plus long c'est de comprendre comment paramétrer le périphérique lambda.
Par example, il faut savoir comment le compilo code les appels de fonction. ça peut être : paramètre 1 dans le registre toto, param 2 dans tata, les autres sur la pile, et le retour dans titi. Quand tu sais ça c'est facile d'écrire la fonction un peu critique en assembleur et de l'appeler depuis le C.
Tout à fait, même si mon point de vu est différent : pourquoi "s'embêter" à faire de l'ASM sur un petit projet ? ...
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Je l'utilise depuis 6 mois sur un projet de complexité moyenne/basse et pour le moment RAS, il répond très bien à mon besoin ... J'ai pas comparé avec les autres car je voulais vraiment du gratuit (projet mi-pro/perso )Fallait lui proposer un compilo gratuit
NB: cible = PIC16F88 ( 368B de RAM ! )
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
des fois ça sert à rien, des fois ça fait gagner du temps d'exécution, de la place en mémoire... Et autant certains assembleurs sont des vrais cauchemars à écrire, autant d'autres sont agréables.Tout à fait, même si mon point de vu est différent : pourquoi "s'embêter" à faire de l'ASM sur un petit projet ? ...
Si c'est un pb de MHz ou de Bytes, c'est qu'on s'est planté au moment du choix du hard ... ou au moins qu'on a vu "trop limite", et que donc le produit ne pourra pas évoluer dans le futur ... donc c'est pas cool AMA ...
Mais tout ceci n'est que philosophie et habitude de travail ...
( hein lolomatic que c'est cool l'ASM ?)
<< L'histoire nous apprend que l'on apprend rien de l'histoire. >>
Arf, m'en parle pas, on a été à la limite des images subliminales pour faire passer SDCC, mais à l'époque du début du projet (il y a 2 ans), SDCC n'était pas aussi abouti qu'aujourd'hui...Fallait lui proposer un compilo gratuit
...Et puis pour revenir sur les raisons que la raison ignore... Ou si tu préfères : les voix de la direction sont impénétrables...
SDCC sur du 16F ?! T'es un courageux toi
J'aurais pas osé mais il faudra bien un jour pour améliorer le port pic14....
movlw 'O'( hein lolomatic que c'est cool l'ASM ?
movwf TXREG
movlw 'U'
movwf TXREG
movlw 'A'
movwf TXREG
movlw 'I'
movwf TXREG
movlw 'I'
movwf TXREG
movlw 'I'
movwf TXREG
movlw 'S'
movwf TXREG
movlw '!'
movwf TXREG
(craquage du lundi après une journée d'assembleur où plus rien ne marche pour des raisons qui ont, en fin de journée basculées dans le domaine du métaphysique...)
