Salut tout le monde !
 
Je perd pieds. je n'arrive pas a faire marcher ce ****** de pic.  
 
...il sagit d'un PIC12F629. mon shéma est simple :
 
Un bouton relié à GPIO3 (avec res de pullup), deux led reliées a GPIO.1 et GPIO.2 via des resistances de 150 ohms. rien d'autre
 
J'aimerais faire ceci (programme de teste) :
 
Quand j'appuie sur le contact (GPIO.3 = 1) la led 1 s'allume, l'autre non
quand je relache le bouton (GHPIO.3=0) l'inverse se produit.
 
Aucun autre composant, circuit sous 5V, compilateur CC5X, IDE Mplab, envoyé sur le pic avec ICprog
 
pourriez vous, en connaissance de ces informations, me donner quelques infos sur ma réalisation ? (configuration "trisio" & "gpio" ect ... et surtout POURQUOI proceder ainsi) ?
 
merci beaucoup, j'attende vos réponses avec impatience, ++ Tix.

bah pkoi pas essayé de nous décrire ton problème avec la solution que toi tu as ? ça nous permettrai pê de voir un truc qui va pas ...
 
genre, erreur classique avec les pic qui ont un adc : as tu pensais à désactiver le convertisseur analogique des GPIO que tu utilises ?

Merci deadog pour ta réponse, voilà mon shéma et mon code actuel :
 

 

 
probleme : rien ne se passe
 
solution actuelle : trisio mal configuré, je tente ce soir, je vois tiend au courant .
 
merci, ++ Tix.

Salut,
 
Effecctivement TRISIO est mal configuré. En fait TRISIO définit si GP0 à GP5 sont en entrée ou en sortie. Un 1 définit la patte en entrée, 0 en sortie. Ensuite le bit0 de TRISIO configure GPIO0, le bit5 configurant GPIO5.
Dans ton application on a:
GP1 en sortie,
GP2 en sortie,
GP3 en entrée.
(les autres ports sont laissés en entrée)
Donc TRISIO = 0b 1111 1001
 
Lors de la programmation, il faut aussi bien configurer le bit qui correspond au reset (/MCLR), en configurant le reset en interne pour utiliser GP3 comme une entrée.
@+
 
NETeagle
 
PS: le bit0 est situé à droite du mot de 8 bits !

salut
 
merci pour ta réponse, on m'avais dit la meme chose sur un autre forum

 
qui me dit que ANSEL ne marche pas, me serais-je gourré ?[/quote]
 
[color=green]
[EDIT] Pas de souci en fait, les pic12f629 n'ont pas de CAN, je guettais des exemples avec des 12f675 !!!![/EDIT][/color]
 
merci encore, ++ Tix.

J'ai du nouveau !!!
 
j'ai fait un programme qui allume seulement toutes les sorties (à 1)
 
mais voilà, elles ne s'allumes que quand, par inadvertance, j'ai posé le doigt sur certaines de ces sorties !!!!
 
est-ce normal ?

Quels sont tes bits de programmation ?

comment celas ?

Ben quand tu programmes ton pic, tu lui indiques plusieurs chose, comme le type d'oscillateur, la configuration de la patte de reset, etc....
Quel logiciel utilises-tu pour la prog du PIC ?

IC PROG
 
je désactive le watchdog, et je je suis pas sur de maitriser le vocabulairte de l'oscillation ,que pense tu que de doive configurer ?

Ton problème vient surement d'une mauvaise programmation des bits de config !
Dans IC Prog, faut mettre :
Oscillator: INTosc GP4 -> Oscillateur 4 MHz interne, la patte étant libérée pour GP4
BandGap: default
WDT: décoché -> pas de watchDog
PWRT: coché -> ca créer une tempo lors de la mise sous tension pour attendre que les alims soient bien établies
MCLR: décoché -> le reset est relié en interne au PIC, la patte étant libérée pour GP3
BODEN: coché -> fait reset si la tension d'alim chute au dela d'une certaine valeur
CP et CPD: décoché -> protection contre la lecture du code interne.

merci ,j'essaye !

argl toujours le meme probleme, mais, d'apres toi, dou provient le fait que mon programme marche que quand je pose le doigt sur les pin du pic ? (entre alim et pin)
 
ca m'inquiete ^o)

Bizarre en effet ! Vérifie que MCLR est bien décoché dans IC prog.
J'ai aussi vu un truc pas top dans le code:
TRISIO = 0b001000;
à remplacer par TRISIO = 0b00001000;
idem GPIO = 0b11111111;

Okioki, quel en ets la raison exactement ?

si vous voyez d'autres conneries de ma part, ou si vous avez d'autres conseils, je suis preneur, je revien tout de suite.

Ben c'est tout simple: le registre TRISIO et GPIO sont des registres 8 bits, il est plus sur de mettre des valeurs de 8 bits dedans, pas de 6 bits...

d'accord, ca me parait sensé
 
bon, sinon, mon probleme persiste .... j'ai le doigt magique, à tout les coups ....

Lors de la programmation sous IC Prog, quelle valeur y a-t-il dans le mot config word (en bas à droite) ?

je te dis ca tout a l(heure

Question débile :
 
C'est moi oul es cathode des leds sont au VCC ?
 

elles y sont

c est la question que je me suis aussi posée mais comme il dis qu il vois les leds s allumer c est que le schéma doit etre faux. mais son montage juste donc....

Je bricole mon montage au fur et a mesure que je me rend compte de betises ... par exemple, là , ya un condo de decouplage, mis sur conseils ...
 
apparemment, j'ai fait une fausse manip et mon exemplaire à cramé. je reprend des samples dans la semaine. en attendant , je vais essayer sur des 16f84 ou un 10f222 ....
 
++ Tix.

   Ca y est les gars , j'ai trouvé le problème , j'ai eu la même surprise (état instable du PIC ... Patte sensible ) , en fait c'est le CCS C Compiler qui bug un peu , je m'explique :
 
    Sur un pic 12F629 j'a fait un programme qui fait clignoter une Led : j'ai examiné le code généré par le compilateur et il semblerait qu'il y ait un problème sur le Vecteur RESET adresse 0000h , en effet a cette adresse on devrait retrouver un "GOTO MAIN" Main etant l'adresse de depart du programme principal , mais la CCS essaie de calibrer le registre OSCAL (calibration de l'oscillateur interne ) visiblement ca marche pas a tous les coups . Un peu de code pour etayer :
 
0000 3000       00001 MOVLW  00   <---- Adresse 0000h Vecteur RESET
0001 008A       00002 MOVWF  PCLATH
0002 2804       00003 GOTO   004
0003 0000       00004 NOP
0004 23FF       00005 CALL   3FF
0005 1683       00006 BSF    STATUS.RP0
0006 0090       00007 MOVWF  OSCCAL
0007 3000       00008 MOVLW  00
0008 008A       00009 MOVWF  PCLATH
0009 2824       00010 GOTO   MAIN   <---- Adresse 0009h Goto programme principal  
 
 
entre l'adresse 0000h et 0009h   le compilateur intègre la valeur de calibration de l'oscilateur interne dans le registre "OSCAL" (voir datasheet du pic )
c'est la ou le programme plante une fois sur 2 . Voila la facon de regler le Pb :
 
il suffit de mettre lors de la programmation du PIC (pour mon cas avec ICPROG) le GOTO MAIN a l'adresse 0000h , de cette facon le programme démarre toujours bien et curieusement le PIC est stable !!!!!
 
ca donne donc :  
 
0000 2824       00001 MOVLW  00   <---- GOTO MAIN ICI
0001 008A       00002 MOVWF  PCLATH
0002 2804       00003 GOTO   004
0003 0000       00004 NOP
0004 23FF       00005 CALL   3FF
0005 1683       00006 BSF    STATUS.RP0
0006 0090       00007 MOVWF  OSCCAL
0007 3000       00008 MOVLW  00
0008 008A       00009 MOVWF  PCLATH
0009 2824       00010 GOTO   MAIN   <---- Adresse 0009h Goto programme principal  
 
bien entendu bien respecter l'adresse du programme principal  (pour ma part je copie le les 2 octets de l'instruction GOTO MAIN Compilée par le CSS) ici 2824.
 
en parallèle , il y a 2 bug sur le PIC12F629 :
 
pour le premier voir l'excellent document de Jonathan Scott, SMIEE, Daniel Rosborough, and Michael Cosgrove : http://eng.waikato.ac.nz/research/ [...] 2F675.html
le 12F629 étant un clone du 12F675 sans l'ADC mais avec 2 comparateurs
 
pour le 2eme voir le correctif "80125G errata" de microchip  : ww1.microchip.com/downloads/en/DeviceDoc/80125G.pdf
 
et pour finir merci Mr picadilly :members.shaw.ca/picgroup/Resources/Picadilly%205.pdf  
 
Voila si ca peut aider , j'ai cherche une bon moment moi aussi pour faire fonctionner le PIC n'hésitez pas a poser des questions

merci pour ton éclairement, et désolé de répondre si tard !
 
je n'ai pas le temps de tout lire, mais je m'y attele des que je peu, merci encore, ++ Tix.