J'ai l'impression que la doc du 16F18875 est un peu foireuse, elle date de 2015 et est encore qualifiée de "préliminaire".
Quelqu'un aurait-il utilisé les IOC ?
Dans mon programme, lorsqu'un changement d'état survient le bit correspondant de IOCAF ne passe pas à 1.
Et j'en suis fort marri.
1) après appui sur BP (sur porta)
2) quelques cycles plus tard (plus d'une dizaine dans le doute)
3) le bout de programme qui configure les interruptions (INTCON est paramétré avant)
Bon, j'ai forcé IOCAF,0 à 1 en introduisant un bsf IOCAF,0 dans le programme
le flag IOCIR passe à 1
et le programme se déroute bien vers le traitement des interruptions et ça marche.
Demain j'essaye avec un nouveau PIC.
Toujours concernant le 16F18875, le portd est assez comique.
Les bits TRIS,3 LAT,3 et ANS,3 sont en lecture seule avec état indéterminé sur reset,
une lecture du registre ANSEL retourne le contenu du registre PORT, . . .
Y z'ont pas osé écrire "le bit3 est inutilisable".
Dernière modification par antek ; 03/02/2017 à 13h58.
Même résultat avec un nouveau composant.
Il me reste un 16F1719 et un 1947 pour faire la même chose, mais les oscillateurs et timer sont pas organisés pareil, tout à refaire . . .
Toujours personne qui aurait pratiqué le 16F18875 ?
Salut Antek,
J'ai utilisé le PIC16F18875 sur la carte curiosity HPC avec MCC (plugin). Il y a beaucoup de registres à initialiser, y compris pour les ports d'E/S.
Beaucoup de nouvelles options existent sur les ports d'E/S et il est facile d'oublier d'initialiser certains registres.
Pour les anciens PICs ils n'y avaient que les registres ADCON, TRISx et parfois CMCON.
Je n'utilise que le langage C
a+
Oui, je les ai tous épluchés un par un.Envoyé par RISC
Tu as utilisé les IOC ?
Personne qui aurait un bout de code utilisant les IOC, pour 16f18875, 1719 ou 1947 ?
Salut, tu as bien mis ANSELA à 0x00 ?
Oh que oui . . .
J'ai l'impression que c'est le débuggueur, ça marche bien avec le simulateur.
J'ai jamais utilisé le simulateur, et quand le debugger affiche un truc pas net, j'allume une led.
Oui mais là c'est un fonctionnement interne, le flag IOC ne passe pas à 1, donc pas d'interruption.
Et c'est dans l'interruption que je positionne un bit qui allume un voyant plus tard.
Je vais faire un bout de programme qui allume/éteint dans l'interruption avec rien d'autres
et le faire tourner en "release".
Sans utiliser les interruptions, pour simplifier, tu peux faire une boucle qui surveille les bits IOCAFx et PIR0.IOCIF
Ouais, encore plus rustique !
Merci
J'ai regardé un bout de code désassemblé par curiosité en simulateur.
Alors je veux bien qu'il transforme un LATD en PORTD
mais un ANSELB en PORTB
puis un IOCBN en TMR0
c'est quand même bizarre.
Et pourtant le simulateur fonctionne !
Demain j'essaye en vrai.
J'ai utilisé le PIC16F18875 sur la carte curiosity HPC avec MCC (plugin). Il y a beaucoup de registres à initialiser, y compris pour les ports d'E/S.
Beaucoup de nouvelles options existent sur les ports d'E/S et il est facile d'oublier d'initialiser certains registres.
Oui, c'est ce qu'a dit RISC . . .
Bon, j'ai mis un programme simpliste dedans et ça marche.
C'est leur débuggueur qui doit être pourri, sauf si c'est mon Linux . . .
Je fais installer W10 par mon fils en dualboot et j'essaye plus tard.
Le programme est sur un 1947, je met son alter ego dans un 18875 et hop.
Le programme (modifié) fonctionne en release sur un 18875.
Ensuite un programme qui allume une led dans l'interruption IOC fonctionne.
Toujours avec MPLABX 3.45
J'ai installé W10 sur mon PC (athlon 64 X2 4800+), une erreur apparait dans les notifications en débug -> ... une erreur s'est produite ...
Linux est plus précis -> java.lang.NullPointerException
Je vais essayer sur un PC "moderne" avec 3.45 et si ça marche pas avec 3.55
Parce que mon programme est trop compliqué pour tout débugguer avec des led . . .
Je t'ai parlé de debugger avec une led, mais je fais toujours du debug sur console série. Il suffit d'une pin output connectée sur un convertisseur uart-usb. Il n'y a même pas besoin d'uart, pour sortir en bitbang série 9600 bauds, il suffit de quelques lignes de code. Pour régler la vitesse, je reste appuyé sur 'U' du clavier PC, je regarde la largeur du mot transmis à l'oscillo, et je règle pareil au pif côté pic avec une boucle, quand on est flemmard ...
Ca évite d'utiliser les debuggers bugués.
Tu la fait comment la console ?
Tu pourrais détailler, parce que je vois pas ?
Je me sens moins seul . . .
ben, la console c'est un PC avec logiciel putty, Teraterm, ...
D'accord pour la console.
Il faut alors un programme dans le PIC qui envoie l'état des registres qu'on veut surveiller ?
C'est ça ?
C'est pas pour faire du suivi temps réel, c'est pour rendre parlant un programme muet.
En créant la fonction basique d'envoi d'un octet void SendSerialChar(unsigned char c)
et celle d'envoi d'un octet en hexa sur 2 caractères void SendSerialHexa(unsigned char c)
Bon j'avais oublié que tu es en asm, mais l'asm c'est encore plus simple pour la précision des timings, car le compilateur C, il fait un peu ce qu'il veut.
Je me suis mis aux µC il y a 4 ans avec BIGONOFF en assembleur, juste par intérêt personnel.
Mais c'est bien ton truc, j'y aurais pas pensé !
Un exemple d'uart bitbang pic, la fonction Xmtr envoi l'octet W sur la pin _tx.
Ensuite la vitesse peut être réglée dans la fonction WaitOneBit.
http://www.sonic.net/~schlae/rs232.asm
Suite et pas fin . . .
Ayant eu des doutes sur la sélection des bank j'ai introduit une petite boucle qui allume des led sur PORTB.
Rassurez-moi, il y a une erreur quelque part, car rien ne s'allume !?Code:test_bsr movf BSR, w banksel PORTA movwf LATB bcf led_ok goto test_bsr
Les led vérifiées avec un
LATB, x
dans la même boucle au même endroit.
PS - c'est introduit après le banksel que je veux vérifier bien sûr !
Dernière modification par antek ; 03/03/2017 à 17h17.
salut, ce programme copie la valeur de BSR vers LATB, pas la peine de boucler dessus, une fois suffit.
C'est quoi led_ok ?
En fait, la boucle fait que à partir de la 2ème passe BSR passe et reste à 0.
Et merde, c'était trop gros pour que je le vois.
"led_ok" c'est un autre port, indique que je passe bien dans la boucle.
A la prochaine . . .
La console série t'aurait affiché la bonne valeur de BSR
