Exercice PIC

[invite03481543]

Mon cher minioim,

Ton explication n'est pas approximative elle est tout simplement fausse.
Je ne crois pas que Bigonoff est en plus traité les PIC12F avec les GPIO, donc tu mélanges tout.

Quand on veut jouer avec moi et me faire passer pour un con, je suis toujours là, mais tu prends un risque... d'être ridicule.
Comme tu veux semer le trouble dans les esprits, je vais donc te répondre:

Je viens de ressortir le document de Bigonoff, partie 1 page 105-106: il s'agit des interruptions, ça commence mal pour toi car rien à voir avec le sujet.

ton bout de code, en l'état, ne peux fonctionner et je vais te dire pourquoi:

1/Pour qu'un code C "tourne" il faut au minimum un main(), puis déclarer le port en entrée ou en sortie, ce que tu ne fais pas.
2/Ton histoire de vitesse ne tient pas la route 1 seconde, un programme est une succession de tâches qui survient l'une après l'autre, donc la modification du registre qui gère l'état de la sortie de ton port est pris en compte aussitôt l'instruction déclarée, il ne peut pas "ne pas avoir le temps" comme tu dis, il ne fera rien avant d'avoir exécuté sa tâche actuelle, c'est ce qu'on appelle le déterminisme.

Tu étais novice il y a 6 mois, tu l'es encore à ce jour à ce que je vois.
Faut être sacrément gonflé pour oser venir me raconter pareille connerie et en plus avec autant d'aplomb.

Tu as une dernière chance de t'en sortir les cuisses propres en postant dans les 5mn ton code complet, celui qui est sensé fonctionner.

J'attends.
-----

[invite03481543]

Et tu me donnes la ref de ton PIC et le quartz.
Je parie que tu utilises un simulateur ou une connerie comme ça.
J'aurai tout entendu ici et pas vu grand chose, je vois que tu as vite disparu une fois mon post publié.

[minioim]

vite disparu parce que j'ai pas répondu dans les 4 minutes (temps entre tes 2 posts) à un message auquel tu as toi même mis 2h30 à répondre? la notion de temps est très relative visiblement...

bon maintenant je vais lire tranquillement ce que tu as écris, et y répondre en bonne intelligence.

[invite03481543]

Oui prends bien ton temps camarade, sors les rames.

[minioim]

ok maintenant que j'ai tout relu...


nom d'un chien faut pas se vexer aussi facilement! Oo

alors oui primo je l'ai testé et pas sur simulateur. en vrai, sur un montage tout ce qu'il y a de plus réel.

Secundo, je n'ai pas posté l'intégralité du code mais uniquement ce qui se trouve dans le while qu'on a l'habitude de mettre pour faire tourner un programme de PIC.

pourquoi? bah parce que c'est la partie qui était intéressante.

tertio, j'ai testé le même programme juste en intervertissant les 2 lignes d'un programme à l'autre, et ce que j'ai dit se vérifie dans la réalité, aussi douloureux cela soit il pour ton ego.

dernièrement, malgré toutes les grandes certitudes que tu as, je peux même te faire une copie d'écran si vraiment ça te soulage, mais sur ma version (il est fort possible qu'elles ne soient pas les mêmes), à savoir le fichier part1-R24.pdf, récupéré du site de Bigonoff, à la fin de la page 105 et au début de la page 106, dans la section 11.8.1 (comme ça ça sera peut être assez précis), je te cite le passage:

11.8.1 Fonctionnement particulier des PORTS

[...]

Pire, si vous écrivez plus simplement ceci, en admettant RB1 et RB4 soient en sortie :
bsf PORTB,1 ; on met RB1 à 1
bsf PORTB,4 ; on met RB4 à 1
Le résultat vous semble évident, puisque RB1 et RB4 sont placés tous les deux à 1. Or, de nouveau, il y a un piège caché. En effet, imaginez que sur RB1 vous avez placé une charge fortement capacitive. La sortie, constituée de la résistance interne de RB1 et du condensateur de la charge, forme ainsi un réseau RC. Ce réseau a une certaine constante de temps. Il faut donc un certain temps à la sortie RB1 pour atteindre Vdd/2 et donc d’être considérée comme un état 1. Vous comprenez maintenant ce qui va arriver ?
En fait, au moment du bsf PORTB,4, il va se passer ceci :
- Le PIC lit PORTB, mais RB1 n’est pas encore arrivé à une tension suffisante et donc est lu « « 0 »
- Le bit 4 est forcé à 1
- Le PIC réécrit le PORTB, et donc remet RB1 à 0.
Moralité, RB1 ne passera pas à 1 et restera (dans ce cas précis) à 0. Si on étudie le datasheet au niveau des caractéristiques électriques, on s’aperçoit qu’on peut rencontrer ce cas même si on respecte le dit datasheet. Par contre, toujours en respectant le datasheet, le temps d’établissement restera inférieur à un temps de cycle d’instruction. Moralité, pour éviter ce cas, il vous faut ajouter une instruction « nop » :
bsfPORTB,1; on met RB1 à 1
nop ; on attend d’être certain que le niveau soit stable
bsf PORTB,4 ; on met RB4 à 1
Donc, sauf si vous avez calculé exactement le temps d’établissement de vos tensions de sortie en fonction de vos charges, de la fréquence du PIC, et du cycle interne des instructions :
Placez toujours une instruction « nop » entre deux instructions de manipulation successives de deux pins situées sur le même port.
Par contre, souvenez-vous : pour RA4, « nop » ou pas, rien n’y changera, vous devez tenir éventuellement compte de cette possibilité en conservant en mémoire l’état que votre programme est censé imposer à RA4. Sur d’autres PIC, comme les 18F, ce problème n’existe plus.

maintenant qu'est ce que j'ai utiilisé pour les essais? ce que j'avais sous la main: un 12F629 sur oscillateur interne.

mais je me souviens avoir déjà eu le problème sur d'autres pics, notamment un 16f877.

pour ce qui est du code complet,

j'ai repris celui d'un projet en cours parfaitement fonctionnel, en remplaçant seulement le contenu du while.

alors j'ai viré la partie interruption du code cité ici tout simplement pour faciliter la lecture et parce que j'ai pas l'intention de faire étalage de mon code.

rassure toi elle marche bien et ne bloque pas le programme... mais si vraiment tu ne me fais pas confiance je pourrais toujours refaire un projet, filmer le montage etc... j'aurais bien 5 min à perdre demain.

#include <pic.h>
#include <stdlib.h>
#define _XTAL_FREQ 4000000

// déclarations variables

unsigned char debug = 0;

unsigned char lightOn = 1;
unsigned char state = 0;
unsigned char Wcount = 0;

unsigned char backup_left = 0;
unsigned char backup_right = 0;
unsigned char backup_lightOn = 0;

unsigned char count_timer0 = 0;
unsigned char count_timer1 = 0;
//GP0 sur phare gauche
//GP1 sur phare droit

//GP4 sur capteur gauche
//GP5 sur capteur droit
void interrupt GestionIT()
{

[...]
}



void main()
{ 

OPTION_REG = 0b10000111;
// timer0 prediv 256
INTCON = 0b00101000; // 
//GIE|PEIE|T0IE|INTE|GPIE|T0IF|INTF|GPIF
// 0	0	 1	  0	   1    0    0   0
//GIE et PEIE passés à 1 plus loin


PIE1=0b00000000;

OSCCAL=0b10000000;

TRISIO=0b00110000;
//GP4,5 = input
//GP0,1,2 = output

WPU = 0b00000000;
//no pull-up

IOC = 0b00110000;
//interrupt on change allowed on GP4 & GP5;


//init timers

//timer0

TMR0 = 0;
T0IF = 0;
T0IE = 1; //activation timer0

count_timer0 = 0;


//initialisation timer1 prescaler 1;

T1CON = 0b00110001;


PEIE = 1;
GIE=1;



while(1)
   {  


 GP1=1;
 GP0=0;
 __delay_ms(1000);
 GPIO = 0;
 __delay_ms(1000);

 }
}

pour finir, si tu n'es pas d'accord avec ce que j'ai dit, au lieu de juste te contenter de cracher sur mes explications, je suis tout à fait ouvert à un "cours"! explique dans ce cas ce "phénomènne". explique aussi pourquoi le montage que j'ai sous les yeux réagit ainsi? explique en bref, en quoi tu n'es visiblement pas d'accord avec ce qu'annonce Bigonoff.

très honnêtement, je suis parfaitement près à revoir ma position, à accepter mon erreur, ce n'est pas du tout un problème.

ce que j'accepte moins c'est les tons condescendants du genre "je parie que tu utilises un simulateur ou autre conneries comme ça" sachant que j'ai justement précisé que j'avais fait un test réel.

et l'idée d'être pris pour un con sur le thème "le bout de code que t'as mis marchera pas" alors que j'ai dit l'avoir testé... c'est qu'il faut peut être aller chercher un poil plus loin et se dire "tiens peut être qu'il a fait un programme fonctionnel mais n'as pas TOUT copié pour garder le truc lisible".

mais ça implique de croire un minimum ses interlocuteurs.

bien à toi.

[invite03481543]

Tu vois que quand tu veux, tu peux être plus concis, c'est toujours mieux que 3 lignes.

Le plus pénible avec les gens comme toi, c'est de devoir perdre du temps à convaincre, l'égo il est de ton coté pas du mien, moi perso j'en ai rien à foutre si tu es convaincu d'avoir raison, je n'ai rien à prouver, d'ailleurs je suis un pur anonyme, seulement je pratique tous les jours et ce depuis 27 ans, soit plus que ton âge, et si je viens ici c'est pour essayer que les jeunes que je vais embaucher ou qui le seront ailleurs aient plus de chance d'évoluer favorablement, et combler le peu que l'éducation nationale veut bien leur apprendre sur la réalité qui les attends.

Tu noteras que dans l'explication donnée par Bigonoff il parle en réalité du RMW (traduction: Read/modify/write sans le nommer expressément), d'où ma question sur ton quartz, ce phénomène est lié à la vitesse et à la consommation sur le port.
Si tu as fait un essai réel, il te sera facile de vérifier que sans tes leds le phénomène disparait.
Quand tu as fait ton inversion c'est uniquement le temps de cycle que tu as ajouté qui a suffit à donner le temps au RMW, rien à voir avec la déclaration avant et après.

Les PIC sont loin d'être la panacée dans le monde du µC, Microchip est à ma connaissance le seul fabricant de µC à avoir ce genre de problème, ce qui n'est pas si surprenant.

Fais cet essai et dis moi si tu constate la même chose.
Je continuerai plus tard mes explications, là je vais au lit.

[invite03481543]

Et vexer n'est pas le terme qui convient, balancer à un novice qui vient poser une question sur la programmation des PIC un post comme le tien me rend dingue tout simplement.
Tu aurais dû t'efforcer d'être aussi clair que dans ta dernière réponse.
Relis toi et demande toi si tu aurais aimé ta propre réponse.

Honnêtement?
Sans rancunes et bonne nuit, elle porte conseil.

[minioim]

je n'ai jamais dit le contraire, tout dépend de ce que tu mets derrière évidemment.

encore une fois, j'ai avant tout dit qu'il fallait consulter le cours de Bigonoff pour avoir l'explication complète non? j'ai même précisé que je ne mettais ce bout de code, sans autre forme de procès, que pour donner l'envie d'aller lire le cours détaillé. c'est bien ce que j'ai dit non?

oui sans led, la transition est quasi immédiate et ce problème disparait.

mais dans le contexte, l'objectif était de montrer à quelqu'un l'intérêt d'aller lire ce cours de Bigonoff. hors c'est quoi la première chose qu'on fait avec un µC? on fait clignoter une led.
et de toute façon, une pin sans charge au bout, ça arrive mais dans les premières applications c'est relativement rare.

par rapport à la déclaration avant après, ce n'est pas ce que j'ai dit, si on avait mis GP0=1; et GP1=1; quelque soit le sens des lignes, la première aurait été "ignorée"

effectivement toujours à cause du temps que met la pin à atteindre la tension nécessaire. et donc ce phénomène est très dépendant de la vitesse du PIC etc.. on est aussi d'accord là dessus.

mais est ce que pour autant ce que j'ai dit est faux? non.

En soi, mon ego va bien, que mes connaissances soient relativement limitées, et certainement plus que les tiennes dans ce domaine, je le conçois sans problème. c'est pas mon métier, moi j'suis dev Java, et c'est pas mon diplome d'ingé mécatronique qui me donne une expertise en électronique. tout au plus une connaissance générale.

Seulement est ce que le fait que ta carrière soit plus longue que mon existence suffit à lui seul des phrases du genre

Oui prends bien ton temps camarade, sors les rames.

Tu étais novice il y a 6 mois, tu l'es encore à ce jour à ce que je vois.
Faut être sacrément gonflé pour oser venir me raconter pareille connerie et en plus avec autant d'aplomb.

etc etc... je vais pas faire la liste t'as saisi l'idée.

surtout pour au final admettre, ou au moins être nettement moins vindicatif, que j'ai pas forcément tort. vu le changement de ton assez... radical.

Un grand auteur a dit "la valeur n'attend pas le nombre des années". je ne souhaite pas me placer en comparaison par rapport à toi, mais l'ancienneté n'est pas TOUJOURS un argument incassable. que ça donne de l'expérience et TRES SOUVENT raison, je suis bien d'accord mais bon... cessez de nous sortir cet argument à tous les coins de post... ça perd de sa force à la longue et ça donnerait presque envie de modifier sa date de naissance sur le profil pour être un minimum entendu (dingue le nombre "d'anciens" qui utilisent le net sur ce forum... limite à se demander si je suis le premier a avoir pensé à cette soluion... mais là je ne parle pas de toi Hulk, vu que tu n'affiches pas ton age )

bref, je lirais avec plaisir tes explications, surement plus fournies que celles de Bigonoff, mais est ce que ça valait vraiment la peine d'avoir besoin d'autant de lignes pour en arriver à ça?

Bonne nuit

ps: et sans animosité

Tu vois que quand tu veux, tu peux être plus concis, c'est toujours mieux que 3 lignes.

la concision c'est le fait d'exprimer beaucoup de choses en très peu de mots.
typiquement... écrire 3 lignes c'est être concis.
détailler comme tu m'as demandé de le faire, c'est être loquace

Ya toujours quelque chose à apprendre, même des plus jeunes (bon d'accord, c'était peut être juste la fatigue qui t'as fait intervertir le sens des mots, mais je trouvais ça rigolo )

bonne soirée

[minioim]

Oui sans rancunes

par rapport à ma réponse, avec mes bouts de codes atrophiés... je ne sais pas pour les autres, mais dje8269 a eu la réaction que j'espérais: "euh c'est quoi ton bordel là... bon je vais aller lire Bigonoff"

Alors que tout expliquer pour répondre à une question qui n'a pas été posée (parce qu'au final c'est uniquement moi qui ait introduit cette histoire de code qui marche ou pas selon comment on l'écrit) ça va donner quoi? une lecture en diagonale, une pensée du genre "ah ouais? tiens marrant" et oubliée dans la minute.
aucun intérêt... je suivais là la même philosophie que les anciens de ce forum quand ils répondent à une demande de schéma "donne nous tes infos, ton boulot actuel etc... on va t'aider mais pas faire le schéma pour toi".
L'idée c'est de donner envie de s'interroger... après chacun est libre de le faire ou de laisser tomber. en fonction de l'intérêt qu'il a pour la question

[invite03481543]

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...

Ca par exemple est faux.

[JPL]

Discussion temporairement fermée pour cause d'alerte à la bombe. Je laisse les modérateurs habituels de ce forum décider de son avenir ainsi que de celui de certains messages que j'ai supprimés au moins provisoirement.

[Jack]

La discussion est rouverte de manière provisoire. Au prochain dérapage, elle sera définitivement fermée.