Bonjour,
Je souhaiterais bien assimiler et comprendre la logique de fonctionnement des PIC.
Par conséquent, je recherche des exercices de programmation (en C).
Je précise que je n'ai pas de PIC encore et je veux juste m'entraîner pour le moment.
Auriez vous un bon site internet avec des exemples/exercices corrigés ?
Merci
Salut,
Sans hésiter, le très bon cours de Bigonoff : http://www.abcelectronique.com/bigon...=loadpart1.php
La robotique, c'est fantastique !
Bonjour Yoruk,
D'accord, je vais voir ça !
Merci à vous
Salut,
Pour anticiper ta réponse qui pourrait bien ressembler a "mais c'est pas du C, c'est de l'assembleur !"
Dis toi que le C n'est qu'un moyen de programmer plus facilement. Mais derrière tout est traduit en assembleur donc il faut comprendre comment ça marche avant de passer au C. Sinon on fait n'importe quoi et on se retrouve avec des réactions bizarres du pic.
Il faut apprendre le vélo avant de passer a la moto
C'est surtout la philosophie des cours de Bigo qui est intéressante. La démarche est la même que ce soit en asm, Basic, C ou autre.
De plus, pour nous francophone, c'est tout "bénef".
Salut,
Le passage par l'assembleur n'est pas obligatoire.
Il existe des tutoriels bien faits et à jour sur MPLAB X. Bigonoff utilises une version de MPLAB vieille de 8 ans...
Regarde en particulier le site Gooligum : http://www.gooligum.com.au/tutorials.html
a+
Vaut mieux un MPLAB qui fonctionne qu'une daube comme MPLABX.
Tu nous soules avec ta retape incessante sur ces logiciels vérolés , je te l'ai déjà dit et je te le redirai à chaque fois que tu interviendras.
Tu devrais savoir depuis le temps que la pub pour ta boite est interdite par la charte que tu as signé en t'inscrivant.
Qu'on le veuille ou non, arrêtez moi si je dis une connerie, un PIC utilise l'assembleur pour fonctionner. Le compilateur C ne fait jamais que traduire en assembleur. Lui même transcrit direct en binaire (on parle plus de traduction la vu que c'est une correspondance direct des "mots" assembleur vers leur code binaire.
Bref, je ne suis pas expert de la question mais apprendre le fonctionnement des PIC sans jamais lire ne serait ce qu'une info sur l'assembleur qui tourne derrière c'est une connerie...
Tiens faudrait que je regarde d'ailleurs si la traduction C vers asm prend en compte une ou 2 subtilités a ne pas oublier quand on change 2 bits du même port a la suite... De mémoire il ne le fait pas mais bon... A vérifier.
Un µC utilise le binaire, c'est sa langue à lui, il ne comprend donc que des 1 et des 0.
Un compilateur C est un langage de plus haut niveau que l'assembleur, plus lisible et surtout portable, ce qui en fait tout son charme.
On peut se passer de l'assembleur mais il n'est pas de bons programmes qui s'en passe totalement si on veut optimiser certaines ressources matérielles, ou alors il faudrait un compilateur parfait ce qui est loin d'être le cas.
Par exemple quand on fait un bootloader l'assembleur est plus pertinent, la zone de boot étant de faible taille surtout sur les petits µC.
OK mais ce que je veux dire c'est que pour passer de l'assembleur au binaire c'est juste une traduction directe. Un mot asm a un équivalent binaire. Il suffit donc de prendre le mot et de chercher sa correspondance et on a le binaire. Tandis que passer du C au binaire est un poil plus complexe et passe de toute façon par l'assembleur...
Non, pas directe, que ce soit du C comme pour l'assembleur, les 2 étant des langages dont il faut en faire une traduction préalable pour en vérifier la syntaxe, donc le compiler pour en obtenir un premier fichier binaire (*.o du C ou *.lst de assembleur) puis le passer dans l'éditeur de liens ou linker (pour l'allocation des adresses, assemblage des modules) pour obtenir un binaire exécutable (hex).
Ah? Faudrat que je revois cette partie...
Bonjour à tous,
Je vois régulièrement passer des messages sur des personnes voulant s'initier aux µC. En général on trouve dans les premières réponses les cours de Bigonoff, en assembleur. Je ne remettrai pas en cause ces cours, surement très complets, mais je voulais juste donner mon avis. Pour le coup, je pense que beaucoup de monde cherche juste à réaliser quelques petits montages, assez simples, mais nécessitant une logique programmée. Pour ce genre de projet, je ne vois pas vraiment l’intérêt de se plonger dans l'assembleur... On fait des logiciels très performants pour la programmation en C et à moins de vouloir quelque chose de très précis (notamment l'idée de contrôler un montage précisément en temps), le C conviendra parfaitement !! Pour aller encore plus loin, je connais bien les problèmes posés par Flowcode, mais il ne faut pas nier quelque chose: ça marche !
A mon avis, il ne faut pas renier tout le reste et ne miser que sur l'assembleur, quand on commence à s'intéresser aux µC, on a bien d'autres problèmes que d'apprendre l'assembleur, et le C conviens très bien, quitte à, plus tard, s'intéresser à l'assembleur pour des projets plus pointus.
Voilà, c’était mon avis, je comprends que certains d'entre vous ne le partageront pas, mais en attendant, je le redis, le C, ça marche ! Et même plutôt bien !
Flowcode n'est pas du C, ne mélange pas tout.
Apprendre les µC avec flowcode est une pure gageure, j'en vois tous les jours les effets néfastes sur ce forum, les questions montrent que les gens qui utilisent ce truc ne comprennent pas ce qu'ils font et surtout comment le processeur travaille .
Dire que ça marche est très réducteur, si c'est pour allumer une led et faire une tempo, j'appelle ça de la fainéantise intellectuelle, nul besoin de flowcode pour cela ni du C d'ailleurs...
Le C s'inscrit dans une démarche d'analyse cohérente d'un projet, destiné à des applications plus complexes, pouvant être transposées sur d'autres µC, facilement modifiables.
Je ne mélange pas du tout Flowcode et le C !
Honnêtement, je trouve que cracher comme ça sur des langages plus simples est vraiment dommage... Certes, l'asm est surement plus proche du µC. Certes, on contrôle vraiment ce qu'il se passe. Certes.
Mais franchement, mettez vous à la place de quelqu'un qui commence quoi... "Bonjour, je voudrai faire ça avec un pic" -"Va apprendre l'asm et on en reparle".
C'est vraiment pas motivant (même si pour le coup l’assembleur peut faire plus peur par son nom qu'il n'est vraiment). Il y a quand même un nombre impressionnant de choses possibles avec du C non ? Des fois j'ai l'impression que vous avez tendance à nier catégoriquement le C parce que "Dire que ça marche est très réducteur". Pour quelqu'un qui n'est pas à fond là dedans, un montage qui marche est un montage qui marche ! Et c'est une satisfaction énorme quand même ! Alors pourquoi autant le nier ?
Il serait bien à mon goût de laisser voir différentes possibilités à ceux qui veulent s'y mettre, et ne pas rester fermé sur un point !
Flowcode n'est pas plus simple, c'est juste une illusion de simplicité.
Quand tu en sortiras tu verras que tu n'as rien appris avec ça, contrairement à l'assembleur ou au C (ou tout autre langage comme Pascal, Basic).
Quitte à apprendre quelque chose et investir du temps autant que ça serve vraiment non ?
Notre rôle d'expert est de donner les bons conseils, maintenant libre à vous de les suivre ou pas, ça ne me pose aucun problème.
Le soucis est de vouloir faire sans en tirer le moindre enseignement, c'est un choix, mais je ne le partage pas.
Je tiens quand même à préciser que ne cautionne pas Flowcode... J'ai appris à l'utiliser au lycée, (Option Si en terminale), et donc j'ai eu à l'utiliser un peu. Il permet disons de faire le lien entre le grafcet qu'on voit assez tôt, et son application plus concrète !
Je ne l'utilise plus du tout, et en effet, il ne me manque pas du tout ! Par contre, j'ai beaucoup fait de C, et pour le moment, je n'ai jamais eu de problèmes avec, d’où mon point de vue ! Après je ne cherche pas non plus à créer une polémique hein ! Mais je voulais juste dire qu'il serait peut être plus judicieux d'essayer de juger des besoins de l'utilisateur, et de ses motivations, avant de proposer l'assembleur (qui reste surement l'idéal). Disons qu'il vaut mieux avoir quelqu'un qui s'amuse et fais ses petits montages en C, plutôt que quelqu’un qui désespère sur l'asm et qui arrêtera vite...
Il n'y a pas de polémique puisque dans l'industrie on utilise le C et l'assembleur.
Pas Flowcode, donc il n'y a rien à discuter de ce coté là.
L'assembleur n'est pas l'idéal en terme de développement, c'est juste un complément indispensable à certains stades du développement.
Aujourd'hui nos soucis de responsables R&D sont davantage liés aux coûts qu'autrefois, l'assembleur n'est plus en vogue car trop couteux en heures/hommes, le C est de loin le meilleur rapport d'efficacité.
D'où mon intervention, quand j'embauche un jeune il ne regrette pas d'avoir investi son temps dans l'apprentissage d'un langage tel que C.
Ceux qui sont restés à Flowcode ne trouveront pas de taf, c'est aussi simple que ça.
L'assembleur est simple, ce qui complique son apprentissage est surtout de devoir se plonger dans la doc, ça rebute beaucoup de candidats.
Je partage l'avis de Quentin . j'ai longtemps hésité sur comment et sur quoi démarré pour faire de petit montage avec des µC .
J'ai commencé avec picaxe sur les conseils d'un internaute, qui se reconnaitra surement ; Depuis j'ai fais mon petit bout de chemin avec, et je prends énormément de plaisir car très simple d'utilisation . Sans passé par bigonof ( que je suis en train de lire) on fait des choses déjà très bien et largement suffisante dans beaucoup de cas . J'ai quand fais un chenillard évolué pour paint ball , une voiture télécommandé , diverses télécommandes ;
Si je lis bigonof c'est plus par curiosité car je n'exclue pas de migrer la dessus un jour( pour les performances plus élévé de l'asm) . Mais pour certains petit montage le flowcode peut suffire et donné envie par la suite d'allé plus loin par la suite .
C'est en faisant des erreurs; que l'on apprend le mieux !!
Si tu es hobbyste, libre à toi de te faire plaisir comme tu l'entends.
Si tu veux en faire ton métier, je t'aurai prévenu.
Je ne remets pas du tout en cause ton avis ! J'essaie juste de dire qu'il peut y avoir une autre approche, peut être plus évolutive, où on peut commencer à s'intéresser à ce domaine, sans s'y mettre tout de suite à fond ! Evidemment, ce n'est surment pas une démarche pour quelqu'un qui voudrait en faire son métier, mais après tout, pour moi, l'électronique, et la programmation devraient avant tout être une détente, une passion !
Le tout est que ce soit bien clair pour tout le monde, car ici passent aussi des jeunes qui veulent en faire leur métier et il vaut mieux qu'il n'y ait pas de confusion dans les objectifs à atteindre dans une réalité plus professionnelle.
Le forum est là pour conseiller et couper court aux idées reçues qui circulent sur certains forums.
Je te souhaite une bonne fin de dimanche.
Merci, à toi aussi !
Bon j'arrive un peu après la bataille,
mais je voulais juste montrer ce petit bout de code:
bon il est évident qu'écrire ce genre de code ne rime à rien.Code:while(1) { GP1=1; GP0=0; __delay_ms(1000); GPIO = 0; __delay_ms(1000); }
seulement, si je vous dis que même en branchant 2 leds sur GP1 et GP0, rien ne s'allumera?
alors qu'en inversant les lignes GP1 = 1; et GP0 = 0; , comme ça
et bien ça marchera, la led de GP1 clignotera avec une fréquence de 0.5Hz.Code:while(1) { GP0=0; GP1=1; __delay_ms(1000); GPIO = 0; __delay_ms(1000); }
pourquoi? le cours de bigonoff répond à la question, et même si ce n'est pas spécifique au C ou à l'asm, le fait d'avoir été voire un peu comment ça marchait "à la cave" permet de savoir pourquoi ces 2 codes ne font pas du tout le même résultat.
si le cours de Bigonoff avait été écrit en C, il aurait surement répondu aussi à la question, mais c'est même pas sûr car utiliser le C n'oblige pas à aller voir comment ça se passe en bas niveau. et dans la mesure où on utilise des PIC, le bas niveau me semble assez intéressant au moins à connaître.
donc apprendre par coeur Bigonoff? bof si vous avez le temps... Mais le lire au moins en travers une fois, pour voir de quoi il s'agit, avant de partir sur du C, ça me semble vraiment être un plus.
bien sûr que le C est plus pratique que l'ASM, c'est d'ailleurs ce que j'utilise... et j'en suis pas encore au niveau d'avoir besoin d'utiliser de l'ASM dans mon C. mais le cours de Bigonoff a été une aide précieuse...
maintenant chacun fait son choix
Tu pose un problème , tu donne la réponse sans explication ?
Moi ça m'intéresse ? je trouve ca débile qu'en inversant deux lignes aussi basic quelle soit puisse ne pas faire fonctionné le code . Ce sont les choses dans ce genre qui font peur au novice comme moi ..... .
A force de dialogué j'ai perdu le fil Bigonof c'est du C mais l'assembleur c'est quoi ? je croyais que c'etait in logiciel qui permettait de transformer le C en language machine ?
C'est en faisant des erreurs; que l'on apprend le mieux !!
non Bigonoff donne un cours sur le fonctionnement des PIC en donnant des exemples en assembleur
pour ce qui est de la réponse, je ne l'ai pas donné parce que le but est d'inciter à lire son cours... mais si tu y tiens:
c'est la manière de fonctionner du PIC qui fait qu'en gros, si mes souvenirs sont bons, il va "lire" le port GPIO, puis sauvegarder sa valeur dans un registre de travail, modifier le bit et enfin recopier le registre de travail sur GPIO.
donc sur le premier code que j'ai écrit, il fait cette opération 2 fois, une première fois pour modifier GP1 et une seconde fois pour modifier GP0.
or il va un peu trop vite... et au moment de lire le port GPIO pour se préparer à modifier GP0, il n'a pas encore modifié la valeur de GP1. du coup il sauvegarde la valeur de GPIO sans avoir modifié GP1.
puis il restaure la valeur de GPIO qu'il avait sauvegardé la première fois avec GP1 mis à 1. puis ensuite il restaure la valeur de GPIO qu'il avait sauvegardé la 2nd fois (avant de mettre GP1 à 1) avec GP0 mis à 0.
bilan? le passage de GP1 à 1 a été effacé. oublié.
dans le second code, en fait j'ai inversé les lignes, mais j'aurais aussi pu écrire GP1=0;GP0=1;
en fait, quelque soit l'ordre des lignes, la première est ignorée du coup... bon là comme GPIO valait 0 de toute façon, que la ligne GP1=0 soit ignorée ou pas, ça change rien.
mais si j'ai pas donné l'explication tout de suite, en indiquant seulement que le cours de bigonoff répondait à la question, c'était pour inciter à aller le lire... ne serait ce que parce qu'il explique cette histoire mieux que moi et parce que c'est pas la seule qu'il explique...
bref va plutôt parcourir son cours si tu ne veux plus avoir peur
j'étais novice il y a à peine 6 Mois.
puis j'ai passé une semaine à lire Bigonoff...
puis encore une semaine à me mettre à la prog en C.
maintenant je fais pas "ce que je veux" avec les PIC. et je suis certainement pas un pro de la question. mais tous les projets que j'ai voulu réaliser sont aujourd'hui fonctionnels. et certains me semblaient bien velu il y a quelques mois...
faut procéder par étapes
Minioim, pour reprendre une expression de Daudet:
"Tu as picolé ce soir?"
dje8269 rassure toi tu as bien raison de trouver ça débile et fais comme si tu n'avais rien lu.
Ce bout de code ne rime strictement à rien ainsi que l'explication farfelue de son auteur.
Bonne soirée quand même...
Merci pour ces explications !! Je suis en train jsutement de lire bigonof ! le lire ne me feras qu'avoir une meilleure idée de la chose ; J'ai également pas mal de petit projet autour de µC ( picaxe pour moi) . En tout cas je le lis et je reviens vers vous pour mes questions . car sinon on va polluer ce sujet .
C'est en faisant des erreurs; que l'on apprend le mieux !!
Il est si facile de dénigrer... et pourtant cher "HULK", je te laisse faire l'essaiEnvoyé par HULK28
je viens de le faire. et ce que j'avance est parfaitement vérifié.
Alors je t'accorde sans problème que ce bout de code ne sert à rien. il n'est là que pour illustrer ce qu'il se passe dans le PIC.
en revanche l'explication est bien réelle (pages 105-106 de la première partie du cours de Bigonoff) et je vais peut être finalement remettre un peu en doute ton expertise de la question...
ps: tu m'as quand même mis un doute l'espace d'un instant et j'ai donc fait le montage et testé pour vérifier avant d'écrire ce message.
ps2: comme je le disais déjà, l'explication est assez approximative, et Bigonoff en donne une bien plus claire que la mienne. mais l'essence y est.
"Bonne soirée quand même"
Dernière modification par minioim ; 06/07/2014 à 20h19.
Bsr,
je vais rejoindre l'avis de Hulk.
Vu mon âge, j'ai connu l'apparition des microprocesseurs......et donc la programmation en assembleur.(forcément, il n'y avait rien d'autre)
puis, des langages évolués, cobol, algol, PL1 .....en scientifique, j'ai fini par le fortran 4 étendu.....
Aujourd'hui, je suis loin de ce type de questions. Je travaille sur ce qu'on appelle des systèmes, voire des systèmes de systèmes.
Mais je vois les ravages des erreurs de programmation.......et des patches de (soi-disant) correction
Bientôt retraité, je vais m'initier au C.......sans doute sur C party
Cordialement,
JY
