La programmation de pic ... La misère!

[pollho]

Bonjour
Voilà, moi qui fait de l'électronique et des montages depuis des années avec de la CMOS & TTL,
ça me chatouiller les neuronnes depuis longtemps de me lancer dans la programmation de PIC .
J'ai donc acheté un PICKIT 3.5, j'me suis un peu documenté "quand même ^^ "
Bon MPLAB IDE, pas un mot de français, et le langage utilisé là dedant reste de l'hebreu\chinois,
j'y comprend kedal
- Bon alors j'ai fais 3 petits montages vu sur le net et aucun ne fonctionne
- Un vumètre 2x16 leds avec PIC 16F88, le programmateur me dit "succefull" mais mon vumètre
ressemble plus à une guirlande de noel qu'un vumètre, et une rampe reste entiérement allumée .
Question: y a t-il une mer^^de dans le fichier HEX ???
-Ensuite j'ai fais un voltmètre avec un PIC 16F676, l'afficheur m'écrit encore de l'hebreu .
- Et le troisième, Un K2000 15 leds PIC 16F628A, problème, le site propose un fichier "TXT" et non HEX, bon je fais quoi avec un fichier TXT ?
J'ai lu plein de chose sur l'échec des programmations de PIC, ils sont nombreux, au point que j'me dis que
c'est comme gagnait au loto
SI VOUS AVEZ DES REPONSES A MES MISERES, JE SUIS PRENNEUR, mais ne me dites pas que j'ai qu'a
commencer à faire clignoter une led, comme j'ai pu lire !
Faire clignoter une led ne me fera pas tomber sur "Q"
-----

[antek]

Bonjour
Faire clignoter une led ne me fera pas tomber sur "Q"

Quelle version quel OS quel langage d'où sort ce pickit qu'est-ce t'as contre les led qui clignotent quels schémas

Ce que tu voudrais est une réponse encyclopédique qui te permettrait de passer outre les phases d'apprentissage (et en français s'il vous plaît !).
Cela n'existe pas, même en anglais.

Si tu as des questions précises, essaye là -> https://fantaspic.fr/index.php

Ne pas rejeter d'emblée la possibilité d'erreurs humaines . . .

[mag1]

Bonjour,
Pourquoi vouloir mettre les doigts dans les µC en commençant par un truc compliqué pour un néophyte?
On peut commencer par des µC simples pour quelques euros, comme les arduino, ou autres.
J'utilise les picaxes. Voici une présentation, avec quelques exemples:
http://electromag1.wifeo.com/

MM

[Forhorse]

J'ai pas mal programmé de PIC avec un compilateur BASIC (Proton, qui malheureusement à disparu...)
Ce n'est en rien compliqué, mais la base c'est quand même d'essayer de comprendre ce que l'on fait plutôt que de charger n'importe quoi sans comprendre et en espérant que ça tombe en marche...

[A voir en vidéo sur Futura]

[Piefra]

Bjr,

Concept de base:
La programmation c'est ecrire un fichier txt ( avec une extension adapte selon langage )
Le compiler pour en faire un hex ( avec biensur toutes les librairies necessaires installees )
L'envoyer dans le pic
Et tester

Utiliser un hex prefabrique par quelqu'un n'est possible que si l'electronique est exactement la meme
Une divergence dans les e/s ou seuil de tension ou courant mene a une situation inconnue et inextricable si on a pas le source
Pour comprendre , controller et adapter l'electronique ou le programme

Prendre directement un hex n'est utilisable que pour un montage en kit defini par ex

Si vous aviez demande avant , je vous aurais conseiller un arduino ou like pour decouvrir ces concepts de base avec une communautee libre sur internet ( tuto , source , sketch , schema ... avec tous fourni dans un meme projet )

Cdlt

[Murayama]

Bonjour!

Bon, j'ai du temps pendant que ma CNC tourne...

Bon MPLAB IDE, pas un mot de français, et le langage utilisé là dedant reste de l'hebreu\chinois,

Je ne sais pas si c'est à prendre au sens propre ou figuré, mais le langage de la plupart des
environnements de développement est l'anglais. Certains trouvent intéressant de traduire l'interface,
d'avoir un menu "fichier" au lieu de "file", mais par contre je ne suis pas certain que les messages
de compilateur soient traduits. Conséquence: que vous le vouliez ou non, il serait bon de vous mettre
à l'anglais.
Bon, vos messages, ils sont en anglais (qui pour vous est de l'hébreu ou du chinois), c'est ça?

Cette histoire de fichier hex ne me dit rien qui vaille. Généralement, tous les compilateurs que je connais
(bien peu, en fait, disons STM32, MSP430 et un peu MPLAB) ne vous montrent jamais le "hex" sauf
si vous le demandez. En principe, on écrit un fichier texte (.c ou .cpp et des .h dans les deux cas),
et le compilateur génère un fichier binaire que vous ne voyez pas et qui n'est pas du hex. Le hex,
c'est du binaire traduit en fichier texte en base 16 pour pouvoir être lu en texte, rien de plus. Et
contrairement à ce qui est souvent dit, ce n'est pas le hex qui entre dans votre microcontrôleur,
mais une image binaire du fichier hex.

Bon alors j'ai fais 3 petits montages vu sur le net et aucun ne fonctionne

Si vous prenez des fichiers source sur le net, il y a de fortes chances qu'ils ne correspondent pas à
votre hardware, comme dit plus haut.
Comment branchez-vous les 16 leds? Et pour commencer, est-ce que vous pouvez allumer par exemple
la première (qu'on peut appeler par exemple LED0)?

Petit guide de ce que vous devriez faire, à mon sens, pour faire un vu-mètre.
NB: ce n'est même pas une histoire de débutant ou pas, c'est exactement ce que je ferais
si j'avais à en faire un sur une plaque à trous.
- Commencez par connecter uniquement 16 LEDs. Si vous menez ce projet jusqu'à la fin,
vous pourrez penser à en mettre 2x16. Branchez les LEDs à un seul port (i.e. pas façon arduino)
ou 2 maximum si c'est un µP 8 bits. Et mettez-les dans l'ordre (première LED sur port1.0,
deuxième sur port1.1, etc...
- Vérifiez d'abord que vous pouvez allumer les LEDS une par une de façon indépendante.
- Créez la fonction suivante:
void vumetre(uint8 val, uint8 lr);
val: la valeur est un nombre entre 0 et 15.
lr est un boolean pour left/right. Par exemple 0 pour left, 1 pour right. Et vu que c'est du chinois
pour vous, left = gauche, right = droite.
Testez jusqu'à ce que ça marche, ne commencez rien d'autre s'il y a le moindre problème.
[changement d'outil de la CNC]...
vu_metre(0) -> aucune LED allumée
vu_metre(15)-> toutes les LEDs allumées.
et bien sur toutes les valeurs intermédiaires.
- Une fois que ça marche, il faut ajouter la lecture d'une valeur analogique. Mettez un potentiomètre
entre VCC, GND et analog0 (je ne vous explique pas quelle patte, réfléchissez vous même).
Donc maintenant quand vous tournez, potentiomètre à 0 -> rien d'allumé, puis progressivement
en tournant à droite, les LEDs s'allument successivement jusqu'à pleins feux.
- À ce stade, je ne sais pas si votre vu-mètre est censé être connecté à une source
audio, mais il faut mesurer le signal audio, qui ne sera probablement pas à la
même échelle.

À chaque étape, leçon de modestie. S'il y a quelque chose qui ne fonctionne pas, le plus probable
n'est pas une couille dans le hex ou dans le compilateur, etc. Le plus probable, c'est que vous
ayez merdé quelque part. Les outils disponibles (MPLab par exemple) ont été testés par des
millions de techniciens, d'étudiants, d'ingénieurs, et à chaque fois qu'il y a une mouche dans le
kebab, l'éditeur du software est tenu au courant et publie une correction. Quand je dis "le plus
probable" quand il ne s'agit que d'allumer des LEDs, je dirais que c'est dans les 99.99....99%,
beaucoup de 9 après la virgule, beaucoup plus probable que de ne rien gagner au loto.
Bref, c'est juste une façon de dire que si quelque chose ne fonctionne pas, c'est absolument
certain que l'erreur vient de vous.

Bon ben yapuka!

Pascal

[entropie12]

Bonjour , j'espère qu'il s'agit de MPLABX et pas MPLAB (qui était vraiment capricieux !).
Je fait quelques projets assez conséquent, je commence toujours a faire clignoter une led : on est sûr du hardware , du compilateur (assembleur pour les petits pic 8 pattes , XC8 pour les plus gros par exemple) , du linker ,du programmateur bref de l’intégrité de l'IDE.
Cordialement.

[entropie12]

http://f5ubz.fr/Mplabx/Mplabx.pdf

et lire les datas sheets des µC pour comprendre ce que l'on fait .

[webscience]

Bonjour,

Écrit par mag1 : J'utilise les picaxes

Les picaxes sont des Pic

Écrit par antek : Si tu as des questions précises, essaye là : https://fantaspic.fr/index.php

Exact, et tu vas en apprendre beaucoup ici

Mais bon, pour l'instant aucune nouvelle du demandeur, pas la peine de faire plus.

A+

[antek]

Les picaxes sont des Pic

Pas exactement, non, mais ne chipotons pas . . .

[Forhorse]

Le hardaware c'est des PIC, mais le software pas vraiment.
Si c'est resté comme à l'origine, un interpréteur basic embarqué, ça doit vite être limité pour des applications un peu pointues sur le timings.

[mag1]

Le hardaware c'est des PIC, mais le software pas vraiment.
Si c'est resté comme à l'origine, un interpréteur basic embarqué, ça doit vite être limité pour des applications un peu pointues sur le timings.

Bonjour,
En fait, le plus petit des picaxes, le 08M2 à 8 pattes est un 12F1840. C'est un basic interprété assez efficace et un amateur bidouilleur moyen (comme moi) reste loin des limites (c'est arrivé une fois avec le protocole du DHT11).
Tout dépend des buts recherchés, si on reste hors du domaine professionnel, c'est largement suffisant pour les applications courantes.
Mais pour un primo débutant, la mise en œuvre et la programmation sont ce qu'il y a de plus simple, je pense l'avoir montré. Le C de l'arduino est déjà plus rébarbatif.

Après, on peut faire comme notre ami pollho (il reviendra peut être, beaucoup ne sont pas habitués à la réactivité des forums). On achète un PIC, auquel on ne connait rien, un PICKIT, on lit les datasheet qu'on ne sait pas lire, on télécharge des programmes que l'on ne comprend pas....il ne faut pas s'étonner que ça ne fonctionne pas.

La question était:

SI VOUS AVEZ DES REPONSES A MES MISERES, JE SUIS PRENNEUR, mais ne me dites pas que j'ai qu'a
commencer à faire clignoter une led, comme j'ai pu lire !

Faut pas bruler les étapes, quand on a fait clignoté la première led, c'est que l'on a déjà résolu pas mal de problèmes.
MM

[Seb.26]

Drôle d'idée d'apprendre à programmer sur un uCPU ... c'est un peu comme apprendre à conduire avec un tractopelle ...

[jiherve]

bonjour,

Drôle d'idée d'apprendre à programmer sur un uCPU

je ne vois pas pourquoi!
JR

[Bitrode]

Le C de l'arduino est déjà plus rébarbatif.

Juste parce que ce n'est pas du C et que c'est la plupart du temps écrit avec les pieds...
Quitte à apprendre quelque chose autant que ce soit quelque chose de durable et de pérenne, on ne le dira jamais assez, surtout ici.

[Bitrode]

bonjour,

je ne vois pas pourquoi!
JR

Parce qu'il faut apprendre les bases et les bases ça ne s'apprend pas sur une cible telle qu'un µC.

[antek]

Le demandeur veut bricoler avec des µC, c'est tout.
Ceux qui ont eut une mauvaise expérience avec une tractopelle ne devraient pas décourager

[Bitrode]

On peut bricoler bien, ça se fait aussi.
Mag1 en est l'exemple, le seul en fait ici.

Perso je ne réponds plus à des sujets où se trouve le mot arduino, pour ne pas participer et encourager à la bêtise collective.

[AstroFOX]

Bonjour,

Parce qu'il faut apprendre les bases et les bases ça ne s'apprend pas sur une cible telle qu'un µC.

Il n'y a rien de contre-indicatif à commencer à programmer sur des petits uC tels que PIC16F ou 18F (dans le cas des PIC) ou MSP430G2 (le kit 430G2 Launchpad était plus abordable qu'un Arduino UNO à sa sortie).

J'ai commencé la programmation en 2009 (1ère STI électronique) sur des PIC18F4550 en C, avec des exercices pour comprendre comment fonctionnent les registres. Le projet final consistait à faire un terminal sur écran 4 lignes 20 caractères en envoyant les données depuis un terminal sur le port USB même du 4550 (il fallait coder le protocole USB CDC nous même). Mais comme tout projet, il ne faut pas sauter les étapes.

1) Bits de configuration
2) Horloge système
3) initialisation des E/S
4) Timer + LED pour vérifier que la LED clignote, et surtout à la bonne fréquence. Si la base de temps n'est pas bonne ça sert à rien de poursuivre (on a parfois des surprises avec un facteur 2 ou une mauvaise source, comme par exemple 32kHz interne au lieu du quartz externe de 4 MHz)
5) Un UART qui dit "bonjour" sur un port com
6) A partir de là on peut s'attaquer aux périphériques "niveau intermédiaire" comme les PWM, I²C, SPI, qui demandent un peu plus de notions pour la configuration et l'utilisation, autant du côté uC que composants avec lesquels ils dialoguent.
7) Etc...

[Bitrode]

Il n'y a rien de contre-indicatif à commencer à programmer sur des petits uC tels que PIC16F ou 18F (dans le cas des PIC) ou MSP430G2 (le kit 430G2 Launchpad était plus abordable qu'un Arduino UNO à sa sortie).

En effet, mais avec les cibles dont tu parles on est très loin des arduino et autres raspberry.
La programmation embarquée nécessite d'avoir une bonne connaissance du hardware et de l'électronique en général pour éviter les pièges classiques de mises en oeuvre des interfaces de communication, de puissance et de la CEM au final.
Je ne parle même pas du PCB/câblages qui généralement sont totalement négligés, donc l'I2C, la commande de moteurs et autres périphériques à piloter font rapidement capoter le projet.
Il suffit de voir sur ce forum le type de questions posées pour comprendre que seule la programmation ne suffit pas.
En commençant par les bases et en étant un minimum attentif/minutieux il n'est pas plus compliqué que ça de bien débuter et d'évoluer durablement, contrairement aux autres gadgets en vogue dont la seule connaissance pratique est finalement le bête copié-collé.

[Seb.26]

En commençant par les bases et en étant un minimum attentif/minutieux il n'est pas plus compliqué que ça de bien débuter et d'évoluer durablement, contrairement aux autres gadgets en vogue dont la seule connaissance pratique est finalement le bête copié-collé.

Tu aurais pas un dauphin -1 en tête toi ?

[Seb.26]

Il n'y a rien de contre-indicatif à commencer à programmer sur des petits uC tels que PIC16F ou 18F (dans le cas des PIC) ou MSP430G2 (le kit 430G2 Launchpad était plus abordable qu'un Arduino UNO à sa sortie).

OK, mais à une condition : avec un debugger pour regarder la pile, ce que c'est qu'un appel de fonction, ce qu'est une variable, un paramètre, un pointeur ...etc...

[jiherve]

bonsoir,

Parce qu'il faut apprendre les bases et les bases ça ne s'apprend pas sur une cible telle qu'un µC.

ben si il existe l'assembleur ce qui est à la base de tout et vous êtes tous trop jeunes pour avoir connu autre chose que les µC,µP, moi j'ai commencé avec des processeurs série câblés en logique TTL dont il fallait déjà faire fonctionner le hard avant de pouvoir les programmer soit directement en binaire soit ensuite avec un assembleur et un compilateur.
j'ai utilisé a peu prés touts les processeurs depuis les 6502/6800/Z80 jusqu'aux PPC en passant par nombre d'autres, une fois que l'on a compris pour l'un c'est presque trivial pour les autres.
JR

[Murayama]

Bonojour!


Juste pour me situer: je ne suis pas vraiment un fan d'Arduino et je n'ai jamais fait
un projet complet avec. Juste utilisé un écran 20x4, quelques LEDs, et fait quelques
tests (notemment mesurer le temps que met digitalWrite pour s'exécuter). Mais je
reconnais sa valeur qui rend possible la programmation pour des gens qui sans cela
ne s'y lanceraient pas.

Juste parce que ce n'est pas du C et que c'est la plupart du temps écrit avec les pieds...

Si, évidemment c'est du C. Créer un compilateur est quelque chose de très complexe,
alors on commence évidemment par utiliser ce qui existe. Je crois qu'Arduino a commencé
par un sujet de thèse. En 3 ans et tout seul, on ne peut pas créer un compilateur.
La librairie Arduino met en place le main() qui appelle setup() puis loop(), ce qui
fait qu'on ne voit pas de main().


Ceci dit, bien que je ne l'utilise pas, je reconnais sa valeur sans laquelle cette
plateforme n'aurait pas le succès qu'elle a. Programmé avec les pieds, par les utilisateurs,
oui, sans aucun doute. Par ceux qui ont créé la plateforme, non, je ne pense pas.
Les fonctions de base genre du digitalWrite cité plus haut prennent un temps fou, mais
c'est le prix à payer pour une souplesse maximale. Pas besoin de savoir à quel port
appartient PinX, Arduino gère cela tout seul.


De plus, une grande partie de ce qui est caché sert précisément à éviter les erreurs
pour les débutants, ce qui rend le système relativement fiable. Pas jusqu'à faire un
contrôleur de vol pour Airbus, mais tout de même fiable.


Mais par contre, d'une certaine façon, Arduino ne fait que repousser la difficulté.
En jugeant par le code écrit par le Kevin moyen qui se lance, aucune notion de ce
qu'est un timer, une interruption. On obtient un programme mono-thread dur de chez
dur, qui rend très difficile les actions les plus simples comme gérer un simple bouton
poussoir. Surconsommation de cycles d'horloge avec des delais bloquants, etc...

j'ai commencé avec des processeurs série câblés en logique TTL dont il fallait déjà
faire fonctionner le hard avant de pouvoir les programmer soit directement en binaire
soit ensuite avec un assembleur et un compilateur

Sans aucune mauvaise intention, à chacun son époque et son expérience. Quelqu'un disait
sur ce site même il y a longtemps, nous sommes la seule génération qui aura tout connu,
les lampes, le transistor, la logique ttl, les premier compilateurs, les microprocesseurs,
etc.
Ce n'est pas faux, toute expérience peut être réutilisée... dans certains cas.
Pour le cas des lampes, je sais ce qu'est une lampe, principalement pour en avoir
construit une en TP, formage de la base de la lampe, insertion dans un tube, pompe à
vide, puis chauffer le capillaire qui fait le vide, et arrêter juste à temps quand
ça fond pour ne pas que le vide ait le temps d'absorber le verre fondu.
Essais. Mouais, ça marchait un peu. Par contre, avouons-le franchement, cela ne me
sert à rien. Savoir un peu ce qui se passe dans les registres quand on programme,
c'est évidemment différent puisque des registres, il y en a. Des lampes, non.
De la même façon, connaître précisément le fonctionnement d'un transistor ne me sert
à rien pour le développement de software embarqué.


Pascal

[Forhorse]

Mais par contre, d'une certaine façon, Arduino ne fait que repousser la difficulté.
En jugeant par le code écrit par le Kevin moyen qui se lance, aucune notion de ce
qu'est un timer, une interruption. On obtient un programme mono-thread dur de chez
dur, qui rend très difficile les actions les plus simples comme gérer un simple bouton
poussoir. Surconsommation de cycles d'horloge avec des delais bloquants, etc...

Du peu que je constate, c'est souvent l'inverse en fait.
Le kevin moyen écrit un programme a grand coup de "delay" et de "wait" dedans et se rend rapidement compte qu'il est infoutu de faire 2 choses à la fois.
Il pose des questions sur un forum et un autre kevin lui parle des interruptions...
Et on se retrouve avec un programme qui ne fonctionne que par des interruptions pour simplement lire un bouton poussoir, là ou une bête scrutation fait tout aussi bien, et son auteur n'a toujours rien compris à la façon de faire du "multi tâche" simplement avec un programme bien écrit.
Le problème ce n'est souvent pas la plateforme (j'ai plusieurs petit projets arduino qui tournent sans problème, depuis plusieurs années pour certains) ni le langage, mais bien la façon de l'utiliser...

[gienas]

Bonjour à tous

… Perso je ne réponds plus à des sujets où se trouve le mot Arduino, pour ne pas participer et encourager à la bêtise collective.

Ce serait bien de vraiment tenir parole, et de respecter tes engagements.

Le forum n’est pas fréquenté que par des professionnels qui viennent chercher de l’aide gratuite. Il y a aussi le commun des mortels qui cherche à se faire plaisir, et qui; en aucun cas, n’aura besoin de réaliser des équipements à commercialiser qui devront aussi respecter les standards de normalisations internationaux en particulier CEM.

C’est bien de prêcher la bonne parole, mais il ne faut pas que cela devienne une sorte de prosélytisme ou d’intégrisme en jetant l’anathème sur tout ce qui n’est pas "béni" par la théorie.

Il faut accepter de parler avec tout le monde.

[Bitrode]

bonsoir,

ben si il existe l'assembleur ce qui est à la base de tout et vous êtes tous trop jeunes pour avoir connu autre chose que les µC,µP, moi j'ai commencé avec des processeurs série câblés en logique TTL dont il fallait déjà faire fonctionner le hard avant de pouvoir les programmer soit directement en binaire soit ensuite avec un assembleur et un compilateur.

Tu es mignon, tu n'es pas le seul vieux ici, d'autant que l'âge que j'ai indiqué sur mon profil est faux.
J'ai mangé de l'assembleur plus que de raison d'ailleurs, pour autant j'ai toujours défendu qu'un bon code se doit d'en introduire, notamment pour les couches bas niveaux matériels.

Pour autant encore faut-il AVANT de coder sur une cible, connaitre dans les détails le/les langage(s), connaitre ce qu'est une architecture microprocesseur/microcontroleur, savoir un minimum comment on pilote un transistor, une led, un relais, etc.
Savoir lire une datasheet tout simplement...
Bref, tout ce que ne sait pas faire un débutant qui code sans rien comprendre la plupart du temps (merci arduino ), en même temps je ne vais pas lui jeter la pierre vu l'état de l'enseignement dans ce domaine...

[Bitrode]

C’est bien de prêcher la bonne parole, mais il ne faut pas que cela devienne une sorte de prosélytisme ou d’intégrisme en jetant l’anathème sur tout ce qui n’est pas "béni" par la théorie.
Il faut accepter de parler avec tout le monde.

Ce n'est pas de l'intégrisme, à l'époque (en 2006) dans Futura Sciences il y avait sciences, maintenant il est vrai que le mot sciences a disparu, il n'y a pas de hasard.
Je considère que sur ce forum on doit aussi pouvoir éclairer les petits jeunes et les petits nouveaux, histoire de contre balancer la crasse ambiante.

Je n'ai rien contre les gadgets de hobbystes, à condition que le message reste bien clair dans les esprits, que cela reste des "solutions" de bricolage et de bricoleurs du dimanche.
Je pense que depuis 2006 j'ai montré que je sais parler avec tout le monde , en tout cas tout le monde avec qui il est possible de parler, c'est à dire ceux qui ont à coeur d'apprendre et d'évoluer, de savoir comment ça se passe dans une vraie vie d'électronicien qu'ils connaitront peut être un jour.

Antoane ici en est la meilleure preuve, je suis fier de voir ce qu'il est devenu un peu grâce à quelques uns, dont je suis le seul survivant sur le forum au passage.

S'améliorer et être curieux n'est pas un vilain défaut , bien au contraire.
Futura doit se démarquer des forums tout pourris comme celui que je ne citerai pas mais que tout le monde connait, il suffit d'y aller jeter un oeil pour comprendre la misère de ce type de forums.

Croire que les choses se passent ainsi dans la vraie vie comme certains le pensent est une erreur, le laisser croire est encore bien pire.
Je suis donc complètement dans mon rôle en équilibrant les affirmations de certains néophytes ou hobbystes qui répandent bon nombre de "légendes urbaines" sur tel ou tel sujet et discréditent mon métier.

[jiherve]

Bonjour

Antoane ici en est la meilleure preuve, je suis fier de voir ce qu'il est devenu un peu grâce à quelques uns, dont je suis le seul survivant sur le forum au passage.

Je crois que tu t'avances un peu!
JR

[Seb.26]

Pfff ... il est donc interdit de toucher un Piano si ce n'est pas pour à terme savoir jouer La Polonaise Héroïque de Chopin ???

Il faut accepter de parler avec tout le monde.

Merci !!!!!!!!!!!!!!!!!!!!!!!!