K8076, OSCCAL et Problèmes de codage PIC 12F675

K8076, OSCCAL et Problèmes de codage PIC 12F675

1    Problème avec OSCCAL
2    Principe
2.1    La version prescal 32
3    Réalisation
3.1    Matériel
3.2    Logiciel (s)
3.3    En pratique
4    Que faire si vous ne voulez rien modifier ?
5    Les améliorations du codeur K8076
5.1    Les modifications
5.2    Interaction avec le programme de recherche OSCCAL
6    Conclusions

Si vous arrivez directement sur cette page par un moteur de recherche, vous pouvez avoir accès à la table des matières et à chaque article, en page d'accueil.    L'accès se fait par l'un des deux liens en tête de colonne de droite ----->

ATTENTION à compter du 15/09/2019 les commentaires ne seront plus possibles à causes de quelques imbéciles qui font du spam pour le plaisir de nuire ! désolé  !

---

Avant propos

Si vous avez, ou avez eu quelques difficultés d'écriture (codage) de votre programme sur des PIC 12F675 (ou 12F629) vous ne manquerez pas lors des manipulations erratiques de perdre le byte "OSCCAL" en adresse 0x3FF de la mémoire programme, qui contient la bonne valeur pour que l'oscillateur interne (INTOSC) puisse fonctionner précisément à 4MHz.

Las de tous ces problèmes sur ces petits modèles de PIC que j'apprécie pourtant, simplement pour faire de petites réalisations, j'ai donc pris le taureau par les cornes, car j'ai à un moment donné, été dans l'impossibilité complète de reprogrammer ces PIC.
J'ai cherché et découvert que le programmateur fonctionnait correctement pour des PIC neufs. Une fois codés, je ne pouvais plus reprogrammer pour continuer une mise au point.

Bien que ces PIC ne soient pas très chers, ce n'était pas une solution…
J'avais par habitude gardé les mauvais "sujets" car je ne comprenais pas pourquoi autant de déchets !

Ceci explique également cet article très technique qui ne manquera pas de décourager les novices, mais donne enfin quelques solutions pour réutiliser ces PIC qui ne sont pas "foutus" mais souvent intacts et qui peuvent :

1-parfaitement être reprogrammés
2-être réinitialisés à la bonne valeur OSCCAL du constructeur. (Il y en a cependant certains dont l'oscillateur a été irrémédiablement détruit à cause du codage lui-même)

Il faut surtout ajouter que ces problèmes sont principalement dus au manque de signalement dans la notice du Kit de programmation K8076 de VELLEMAN qui, au moins au début de sa sortie, n'a indiqué nulle part les restrictions de programmation en début de commercialisation du kit …

On aura l'occasion d'en reparler dans la deuxième partie de cet article qui évoquera comment programmer de nouveau ces PIC récalcitrants.

La première partie d'article traite de la récupération du byte OSCCAL si il a été perdu ou écrasé.

La partie suivante traite d'une solution pour pouvoir coder et avoir la bonne fréquence de l'oscillateur RC INTOSC sans développer quoi que ce soit.

Enfin la dernière partie traite d'une modification du codeur K8076 qui "facilite" le codage et éviterait à priori de détruire l'oscillateur tout en évitant au PIC de démarrer son programme dans le codeur juste après (ou avant) programmation.

1 Problème avec OSCCAL

Les PIC de la série 12F (12F675 et 12F629) possèdent un oscillateur interne de type RC régulé en tension et température, mais dont la valeur précise ne peut être obtenue qu'en ajoutant quelques instructions pour lire un byte situé en fin de mémoire programme à l'adresse 0x3FF.
Ce byte spécifique à chaque PIC a été écrit par le fabricant MICROCHIP lors des essais en production et permet d'affecter la bonne valeur de 4MHz à l'oscillateur par ces quelques instructions.

Lors des aléas de programmation, de mise au point et des erreurs, et surtout en utilisant le programmateur low cost cité, on arrive à perdre la valeur de ce byte, et notamment lorsque l'on réalise un "bulk erase", c'est-à-dire un effacement complet du PIC.

Dans l'esprit, ce n'est pas vraiment dramatique, car il suffit de faire un bout de programme, à charger dans CE PIC et de mesurer au scope la durée d'une I/O, tout en faisant varier la valeur dans le registre spécifique OSCCAL situé en BANK1.

Néanmoins ce n'est pas non plus ultra simple car il y a plusieurs écueils.

Note: OSCCAL désignera aussi bien le registre en BANK1 et la valeur du byte à placer  en adresse 0x3FF, que en EEPROM (Suite au programme de recherche)

J'ai donc initialement réalisé un petit circuit avec 3 switchs pour faire évoluer la valeur de ce registre jusqu'à ce que l'on observe au scope précisément la valeur de 1µs (fosc/4).
Certes ça marche bien, mais tout le monde n'a pas de scope assez précis, et en plus j'avais prévu que ce montage me servirait également à tester des quartz de récupération.

Alors j'ai donc revu à la hausse les possibilités en rendant automatique la recherche de la bonne fréquence, sans pour autant négliger une petite observation au scope si l'on en est équipé.

Faut-il un montage particulier ? Oui et non, car tout montage peut s'adapter facilement au principe dans la mesure où on peut ajouter un ensemble oscillateur externe à quartz à 32.768 KHz. Si vous désirez le faire sur votre propre montage, vous pourrez, à la condition que vous utilisiez l'oscillateur OSC1 & 2, sinon ce sera impossible sans une référence de temps. Dans le cas inverse vous devriez utiliser un montage dédié comme celui que j'ai réalisé.

Je publie ci-après le schéma d'origine avec les switchs, mais ceux-ci ne servent plus à rien maintenant.

J'avais dans l'idée d'utiliser ce montage à "planter" dans le support ZIF du codeur, pour à la fois lancer le programme de recherche du code OSCCAL et être prêt à coder ensuite ce fameux byte en 0x3FF, sans changer de montage ou de branchements.
(Il y a quelques petites difficultés pratiques au niveau des straps de codage qu'il faut modifier en soudant latéralement les pins "Berg" pour pouvoir insérer le petit circuit sur le ZIF. Le plus simple est peut-être de mettre à demeure un petit câble à 5 fils avec connecteur pour ICSP, et à brancher sur le K8076)

En effet sur ce type de PIC, il n'y a aucune possibilité de modifier en dynamique le programme à cette adresse 0x3FF, aussi il sera toujours nécessaire de reprendre le codeur pour écrire ce byte.

(Notez également que SI vous connaissez la valeur de ce byte, vous pouvez aussi mettre directement cette valeur dans le registre OSCCAL situé en BANK1 , mais c'est une méthode "délicate" car cela veut dire que le programme sera dépendant du PIC et ce n'est guère pratique et peu professionnel, alors oublions cette possibilité...)

Pourquoi tant d'histoires sur ce PIC ? C'est un PIC très intéressant par sa petite taille et son nombre réduit de pattes (8 pattes). Certes, tout n'est pas possible avec, mais il suffit souvent pour régler des petits problèmes d'automatisation.

J'avais un instant pensé à l'acquisition d'un programmateur Pickit3 de MICROCHIP, puis je me suis ravisé en voulant déjà régler ce problème avant d'aller plus loin. Le Pickit3 semble très intéressant surtout par ses fonctions de debug, mais ce très petit montage et le logiciel associé auront tout de même leur utilité, même avec un programmateur Pickit.
De plus cela intéressera aussi les amateurs de ce modèle de PIC associé au programmateur K8076.

Il faut bien comprendre que sur un PIC que l'on pourra encore coder, on va implanter le programme de recherche qui va calculer la bonne valeur du byte OSCCAL pour obtenir 4MHz.
Ce programme de recherche ne pourra que l'inscrire en EEPROM, car il n'y a aucun périphérique de communication, et il ne pourra pas non plus l'écrire directement en zone programme 0x3FF.

On relira ensuite le PIC (et surtout l'EEPROM) sur le codeur pour noter cette valeur qui sera transcrite ensuite manuellement en adresse programme 0x3FF par le codeur avec son programme spécifique sous WINDOWS ("PicProg" du codeur K8076).
Le programme de recherche sera alors écrasé au profit de votre application ou d'une remise à zéro (1 en réalité) par "erase". Le micro contrôleur sera marqué manuellement avec cette valeur si possible (Assez difficile sur les modèles SOIC, car très petits)

2 Principe

Le principe est très simple puisque sur la base d'un oscillateur LF à quartz de 32.768 KHz (avec OSC1 & 2) , qui va compter le temps avec précision dans le TIMER1, on va compter les cycles du PIC dans le TIMER0  (durant la référence de temps de 2 secondes).

Il s'avère après essais que le comptage sur 8 bits des seuls reports du TIMER0 est suffisant pour permettre d'ajuster, sans avoir à faire des calculs en 24 ou 32 bits prenant en compte les valeurs restantes dans les prescalers et les compteurs. (C'est un peu pour cela que j'avais envisagé les switchs pour éviter ces complications arithmétiques).

En effet en utilisant un prescaler à 64 et le report TMR0 à 256, on obtient une interrupt toutes les 16384 cycles, ce qui donne en 2 secondes 1 998 848 µs, soit un comptage des interrupts de 122 (sous 8 bits !)

Les valeurs extrêmes de comptages rencontrées ponctuellement sur un PIC sont respectivement de 104 et 170 (Toujours 8 bits)

Pour aller au plus simple j'avais donc choisi initialement ce principe sans diminuer le prescaler du TIMER0, ce qui serait pourtant possible, seulement en partant des valeurs faibles pour atteindre ainsi un comptage non plus de 122, mais de 243 ou 244 pour une valeur optimale.
(Le temps de réponse aux interrupts doit aussi être surveillé et le prescaler à 64 semblait un bon compromis de sécurité)

Bien entendu, il y a quelques instructions (qq cycles) qui sont nécessaires puisqu'il n'y a pas d'autres possibilités de traitement hardware rigoureux (Par capture par exemple). Les reliquats de comptage dans les prescalers ou timers sont serrés au plus juste et principalement pour celui du TIMER1 qui pourrait entraîner un nombre important de comptages excédentaires sur le TIMER0.

Le circuit et le programme (Sans aucun périphérique) ont été dernièrement équipés d'une LED sur GPIO2 pour tout de même indiquer qu'il travaille et qu'il a terminé ! (Cela apparaît en ajout sur le schéma)

Une fois le programme terminé, (signalé par l'allumage "permanent" de la LED), il a alors écrit dans le premier byte de l'EEPROM la valeur de OSCCAL calculée pour CE PIC particulier. (Le programme ne peut pas écrire directement en zone programme pour ce type de PIC)

Ainsi qu'il a été indiqué, l'opération suivante consiste à écraser ce programme enregistré pour effectuer cette recherche, et à le remplacer par celui que vous voudrez ou même de remettre le PIC complètement à zéro (0xFF en réalité) avec un bulk erase, mais en gardant bien dans un petit coin "de votre cœur" (à traiter manuellement) cette valeur OSCCAL pour un prochain codage.

(Cette valeur sera nécessairement introduite manuellement dans le logiciel de codage (PicProg) du programmateur K8076 dans la zone prévue entourée en bleu. Le "0x" est ajouté à posteriori par PicProg)
(Voir recopie d'écran avec les zones spécifiques pour lesquelles on clickera "OUI")

Pour la suite de l'exemple, vous allez coder votre programme sur lequel vous travailliez et qui vous a causé des problèmes.
Pour ce faire vous chargerez votre fichier .HEX et juste avant de lancer la programmation vous devrez écrire dans la zone écran OSCCAL du logiciel du programmateur K8076, la valeur "34yy" (34 est l'instruction RETLW) suivie de la valeur précédemment inscrite en EEPROM par le programme de recherche (yy en hexadécimal).

Vous rentrerez les chiffres et les lettres (En minuscules et sans le 0x !) et seulement après cela vous lancerez la "write all" du codeur.

Votre programme pourra alors utiliser la séquence prévue par le constructeur pour fonctionner au plus près de 4 MHz avec le rappel ci-dessous de cette séquence (qui ne sera traitée en principe qu'une seule fois en début de programme) :

     Bank1                                  ; pour atteindre le registre OSCCAL en Bank 1 (macro équivalente à bsf STATUS,RP0)
             call             0x3FF         ; retour avec valeur en W du byte calculé
             movwf        OSCCAL     ;  inscription dans le registre OSCCAL situé en BANK1
    Bank0                                   ; retour en BANK0 ou où vous voulez ! (macro équivalente à bcf STATUS,RP0)

2.1 La version prescal 32

Comme la version prescal 64 préalablement décrite fonctionnait bien, j'ai préféré tout de même augmenter la précision et passer cette fois en prescal 32 sur TIMER0 au lieu de 64.

Le TIMER 0 fait donc +1 toutes les 32 µs ainsi qu'une interruption toutes les 8192 µs.
Le temps de traitement des interrupts n'est pas un problème, car on a le temps.

Si l'on veut garder des valeurs 8 bits c'est encore possible puisque de prescal 64 à 32 on va doubler le comptage des interruptions et pour la valeur de 4MHz, on devrait donc se trouver vers des comptages de l'ordre de 240 à 250.

Il serait tout à fait possible de diminuer encore le prescaler, mais cette fois il faudrait compter en 16 bits ce qui à mon sens n'en vaut pas la peine au vu de la précision requise.

On procédera de façon séquentielle en partant des plus faibles valeurs pour ne pas dépasser 255 en comptage. Cette façon de faire était déjà celle utilisée en prescal 64, et il ne serait maintenant plus possible de procéder en visant pour commencer une valeur centrale, ce qui serait plus rapide.

C'est donc cette version prescal 32 que je finalise.

La critique se concentre sur la lenteur du procédé à minimum 2 secondes d'incrément, mais c'est tellement plus simple, surtout pour une opération unique, que je n'ai pas voulu faire mieux.

Vous noterez que le changement on-line d' OSCCAL introduit une petite instabilité de la fréquence que l'on doit prendre en compte au moment de ce changement, car il y a une petite oscillation entre le changement de deux valeurs d'OSCCAL. (Il ne faut pas oublier que c'est un oscillateur à quartz, et qu'il lui faut du temps pour se stabiliser)

3 Réalisation

3.1 Matériel

Le typon a été laissé en .TIF pour ne pas perturber la précision. Vous pouvez le télécharger TSTOSCAL_TYPON .
Ce typon en 4 exemplaires comporte également le "micro CI" pour loger un transistor MOSFET CMS utilisé au paragraphe 5 (Modification du codeur). ATTENTION ce typon ne comporte pas la LED.

Je ne m'étendrai pas sur le schéma qui ne présente aucune difficulté. Vous pourrez le simplifier à l'extrême puisque les switchs ne servent plus du tout. Vous pourriez également ajouter un connecteur ICSP pour programmer directement (Surtout pour les PIC CMS SOIC8).

Le circuit sera le complémentaire du programme et je joins mon modèle sur lequel manque la LED sur GPIO bit2.
Vous pouvez donc réaliser ce circuit et ne pas monter les switchs ni les composants associés. (Laissez les résistances qui ont le seul mérite de fixer les potentiels des entrées)
C'est un montage à utiliser occasionnellement et je n'ai pas prévu de dentelle ni de "chi chi"...!

Pour le test des quartz, j'avais envisagé deux emplacements de tailles différentes à gauche et à droite du PIC.
J'avais aussi prévu des pins en // sur les broches du PIC pour placer le CI directement sur le ZIF du codeur, mais cela ne pourrait fonctionner qu'avec la version programme automatique et surtout sans les composants des switchs (Pas de condensateurs surtout).

Ayant eu un doute sur l'implantation directe sur le codeur pour l'alimenter (voir la suite au §5), j'avais également prévu deux connecteurs d'alimentation par câbles USB (USB micro ou USB "carré" imprimante) pour éviter une alimentation externe.

Les PIC sont prévus en DIP et en SOIC, avec pour SOIC la nécessité de souder (Un essai de contact seul a été  décevant et prévisible !), mais le sujet est caduque, car sur le codeur il faut impérativement un DIP (ou ICSP sur version automatique) à moins que l'on mette les picots pour être insérés dans le support ZIF du codeur… (Ou souder un câble  5 conducteurs sur connecteur femelle 5 broches à pluger sur un connecteur ICSP du K8076)

C'est finalement ce que je vais faire, mais il y aura peut-être un problème complémentaire de coupure du VDD (voir au §5).

Cela explique tous ces composants et réservations dont on ne comprend pas toujours, à priori l'utilité.

3.2 Logiciel (s)

Deux logiciels de recherche de OSCCAL ont été réalisés. L'un manuel avec les switchs et l'autre automatique. Seule la version automatique en prescal 32 sur TIMER0 est disponible. Vous pouvez la télécharger TEST2_OSCAL.HEX

C'est à ce niveau que les particularités sont importantes. En effet tous les problèmes viennent du codeur K8076 qui alimente en permanence sous VDD les PIC à coder.

Or, si sur ces PIC vous utilisez l'oscillateur interne et MCLR*, vous ne devez pas programmer en ayant la tension VDD présente en premier. (Notice MICROCHIP DS 41204H §3.0 page 12)

C'est dans ce cas la deuxième méthode qui doit être utilisée, avec VPP qui doit apparaître le premier, or ce programmateur dans sa version d'origine est incapable de réaliser cela puisqu'il ne dispose pas d'une commande ON/OFF de VDD.

Cela pose effectivement le problème du PIC dont le programme peut démarrer (1024 cycles du start-up plus tard après VDD) juste avant d'être codé, mais surtout juste après être codé et avant d'avoir pu passer en vérif. 

Comme c'est justement le programme qui recherche la bonne valeur d'OSCCAL. C'est très embêtant.
Il y a donc 2 verrous d'exécution du programme car le codeur au repos donne un signal à zéro sur GPIO3.

Il était donc impossible d'alimenter ce montage par le codeur lui-même puisque le switch "SW_Valid" était déjà à zéro ("pinoches" prévues en // sur le PIC)

Sur la version automatique, cela n'a plus d'importance, mais j'ai laissé ce contrôle sur GPIO3 qui est maintenu à 0V par le codeur en l'absence de programmation (+12V du VPP).

L'autre problème implique cette fois que l'on démarre le programme de recherche uniquement si l'on vient de coder ce même programme. Ce logiciel de recherche OSCCAL ne fonctionnera qu'une seule fois (Montage alimenté une seule fois) et écrira donc la valeur OSCCAL calculée, en adresse EEPROM 0x2100.

Puis avec le codeur, et manuellement cette fois le byte OSCCAL sera écrit en 0x3FF à l'aide de "PicProg".

Comment savoir pour ce logiciel de recherche si la valeur lue en EEPROM en tout début est une valeur initiale ou une valeur à ne pas détruire ou déjà traitée ? (à savoir que 00 ou FF sont des valeurs possibles)

Le lancement du programme va reconnaître la valeur EEPROM écrite par ce programme de recherche comme valeur de départ qui sera figée à 0x03, car cette valeur ne peut pas exister en tant que valeur OSCCAL, puisque ces deux bits sont normalement à 0 car il n'y a que 6 bits de possibilités qui sont cadrés à gauche.

Ainsi dans "la panique des PIC" dont on ne sait plus très bien "qui est qui ou quoi", le programme de recherche OSCCAL refusera de travailler si ce byte est différent de 0x03, ceci pour ne pas écraser un éventuel passage préalable ou une valeur ancienne correcte.

3.3 En pratique

J'ai fait une réalisation qui est ce qu'elle est, avec ses défauts et ses qualités. Elle est largement amendable, et ce sera à chacun d'y ajouter sa touche personnelle. C'est le principe qui est le plus important.

Dans la pratique, j'ai essayé un certain nombre de PIC initialement déclarés "foutus", et je me suis aperçu que presque tous étaient potentiellement codables (Un seul était complètement mort, car il n'était plus du tout reconnu par son ident "12F675".

Cependant quelques uns étaient partiellement défectueux sur la partie oscillateur interne (Osc1 et Osc2)

Comment j'en arrive à cette conclusion ?

Le programme de recherche a pu être écrit sans problèmes et vérifié également. Cependant son exécution n'a pas pu démarrer faute à l'absence de l'oscillateur Osc1 et 2 qui définit le temps de mesure de 2 secondes par palier.
Ceci étant, le programme était bloqué en attente d'une synchronisation sur deux fronts.
En rédigeant ce texte, je vois qu'il serait utile en se basant sur le TIMER0 comptant cette fois sur 9 bits, de contrôler dans la boucle des 2 secondes que l'on ne dépasse pas de trop ces deux secondes.

Le comptage en overflow pourrait ainsi faire une sortie erreur avec clignotement rapide de la LED. Cette routine d'erreur existe déjà pour une erreur d'écriture en EEPROM (Différence entre écriture et relecture). 40 flashs sur la LED signalent toutes les erreurs (Désolé difficile d'être plus précis à moins d'écrire (même si on ne sait pas écrire) sans erreur EEPROM !!!!)

4 Que faire si vous ne voulez rien modifier ?

Un premier conseil permet d'éviter de rechercher cette valeur OSCCAL en lisant préalablement à tout codage tout nouveau PIC (PIC neuf). Vous noterez alors la valeur OSCCAL retournée par le codeur et vous l'inscrirez manuellement au dessous du circuit (En tout petit petit…!)

Si vous ne pouvez plus coder ces PIC ou que vous ayez des erreurs, alors vous pouvez choisir de forcer la réponse "Yes"  au PIC non reconnu (The settings don't match the PIC in the programmer do you want to continue ?)  pour faire un effacement complet (erase) du PIC. Après cela vous retrouverez en principe la situation "normale" d'un PIC "presque neuf", dans 95% des cas.
Il sera cependant possible que l'oscillateur OSC1 etOSC2 soit détruit ? C'est la partie faible des PIC et particulièrement de ces modèles.

A savoir que le byte OSCCAL est parfois effacé et qu'il faut le retrouver comme indiqué en début d'article. (Ce byte est effacé principalement lorsque le PIC n'est pas reconnu et que l'on force un codage)
Si le temps et l'oscillateur (Osc1 & 2) n'ont pas d'importance pour votre application, vous pouvez aussi laisser ainsi et fonctionner très normalement avec des I/O !

5 Les améliorations du codeur K8076

Le problème ainsi qu'énoncé en début d'article vient du fait que le VDD 5V du PIC est présent en permanence et ne peut pas être interrompu.
Ce fait empêche de présenter le VPP en premier lieu comme le préconise la notice DS41204H de MICROCHIP, dans le cas ou l'oscillateur est INTOSC et MCLR*.

En deuxième embêtement le programme présent en mémoire démarre avant ET immédiatement après codage alors qu'il est encore sur le codeur et cela est très gênant, surtout si il y a des opérations en EEPROM dès le démarrage d'un programme....
(Cet état de faits donne des erreurs systématiques en vérification de codage si le programme réalise une écriture EEPROM en tout début de codage)

"Mais qu'est-ce qu'on peut faire" ? (Clin d'œil !)

Sans s'attaquer au logiciel VELLEMAN "PicProg" (dont on n'a pas le source), qui fonctionne sur le port série d'un PC, il y a tout de même une petite possibilité que je viens de tester pour ce type de PIC ainsi que pour le 16F690.

Je pense que cela peut également être valable pour d'autres modèles, que les 12F675, 12F629, 16F690, mais c'est à vérifier.

Le principe que j'ai adopté est d'établir le 5V dès que le 12V VPP apparaît. Certes, ce n'est pas vraiment beaucoup APRÈS le VPP, (seulement quelques nano secondes après), et cela peut suffire pour ne pas détruire l'oscillateur des PIC. (C'est un point qui reste en interrogation et que je ne peux pas vérifier)

Cela permet surtout d'éviter que le programme fraîchement codé ne démarre stupidement en dehors de son cadre d'exécution (à cet instant il est encore sur le codeur)

Alors il faut modifier le codeur K8076 et après quelques coupures de runs, l'utilisation d'une porte libre existante du 4049, et l'adjonction d'un transistor MOSFET FDV304 canal P, j'ai codé plusieurs PIC 12F675 (DIP et SOIC8) ainsi qu'un PIC 16F690 sans problèmes et en tous cas sans destruction de l'oscillateur.

Ne manquez pas d'apporter vos expériences sur ce sujet et même si vous aviez réalisé une modification similaire du codeur.
Ce que je regrette le plus est de ne pas avoir un codeur sans soucis, car il y a déjà bien des occasions de soucis sur les programmes que l'on développe sans conjuguer tous les problèmes…

5.1 Les modifications

Elles sont très simples et requièrent seulement la fabrication d'un tout petit CI pour souder le transistor MOSFET FDV304.
Les différentes photos montrent clairement les coupures et fils à raccorder.

La résistance R7 sera dédoublée en 2 résistances dont le total (peu critique) est identique et permet seulement de fournir un niveau de 5V pour la commande de la porte MOS 4049.

On utilise les pins 14 et 15 pour inverser le signal de commande du MOSFET (qui est inversé) puisqu'il s'agit d'un MOSFET type P. La conduction est active par un 0 sur la gate (et réciproquement)

(Il faut décaler un peu le petit CI vers les LED pour ne pas être gêné en manoeuvrant le levier du support ZIF, voir photo ci-dessous)

(Le fil blanc a été pris un peu en amont car il était déjà en place suite à une erreur, car j'avais coupé à tort l'alim du 4049 !!! C'est pourquoi il y a un fil nu qui corrige mon erreur repère "B" sur photo)

Vous constaterez aussi qu'il y a un court-circuit sur une des diodes du régulateur 7812 car il n'y a pas de raison de monter exagérément cette tension comme l'a fait VELLEMAN (14 Volts est un maximum)

Pour éviter d'accrocher par mégarde les fils de modifs, vous percerez un trou de 2.5 mm en face de la pin 14 du 4049 (En faisant attention bien entendu de ne pas percer où il ne faut pas…!)
Tous les fils de connexions au petit CI et de modification passeront par ce trou.

La connaissance de la présence tension d'alimentation est toujours utile dans ce genre de montage, aussi j'ai ajouté cette fois une LED de présence sur le 12 Volts permanent (fournissant également le 5V VDD) cette fois (pour des raisons de facilité) avec une résistance de limitation en CMS (côté cuivre du CI cette fois). Aucun fil supplémentaire n'est nécessaire).
Le 5V de codage (LED verte) fonctionnera seulement lors du codage.

En résumé :

Percez à 2.5mm le trou en face de la pin 14 du 4049 en faisant attention...

Percez également à 0.7 les deux trous pour la LED.

Commencez par réaliser les 3 coupures en jaune.
La coupure de masse pour la LED 12V est faite sous la résistance CMS (18K)

La liaison "A" permet de mettre la masse sur la partie métallique du connecteur 9 br. (C'est une simple facilité)

La liaison "B" est seulement la correction d'une erreur d'emplacement de coupure!!!

La liaison "C" court-circuite la diode D3 pour réduire un peu la tension de programmation VPP à 13V au lieu de presque 14.

Supprimez  la résistance R7 et remplacez la, par 2 résistances de 39K et 68K dans l'ordre de la figure et soudez en même temps au point milieu, le fil qui ira sur la gate.

Réalisez ensuite les autres liaisons comme sur le schéma. (Le fil blanc pourrait être placé plus près, juste à côté du fil bleu près de la coupure, mais c'est ainsi suite à erreur et peut être pas plus mal pour le découplage...)

La nouvelle LED ne nécessite aucun fil,  hormis les pattes de la LED. L'une des pattes (Anode) est repliée sur le run en biais, l'autre, le côté masse, la rejoint par la résistance CMS de 18K. (Voir agrandissement ci contre)

(Le petit circuit du FVD304 peut au besoin être collé sur la résistance, mais ça ma parait suffisamment rigide à mon humble avis.)

J'ajoute également que j'ai modifié depuis la nuit des temps, justement suite à des problèmes de codage la résistance R10 de 47 ohms en sortie de régulateur 5V par une 22 ohms. Ce n'est pas impératif, mais c'est mieux pour ma satisfaction personnelle...

Enfin en dernière modification, j'ajoute que j'utilise le paramètre "Hardware delay" de PicProg à la valeur 7. Depuis les modifications je n'ai pas fait de nouveau essais sur la véritable nécessité de cette valeur.

5.2 Interaction avec le programme de recherche OSCCAL

Avec cette modification, une fois que le PIC 12F675 aura été codé, ce programme ne redémarrera pas, car le 5V est maintenant coupé dès la fin du codage.
Il sera lors nécessaire de retirer le PIC du codeur et d'alimenter le montage par l'USB par exemple. (Le codeur ne peut plus maintenant être utilisé comme alimentations 5V !)
Le programme de recherche va alors s'exécuter et écrire la bonne valeur en adresse EEPROM 0x2100.

Après on fera comme d'habitude en plaçant de nouveau le PIC sur le codeur pour effacer ou coder votre  programme particulier mais en remplissant la zone OSCCAL avec la valeur donnée par le programme de  recherche. Cette fois cette valeur sera bien mise en adresse programme 0x3FF (la dernière adresse programme) par le programme "PicProg".

Vous pourrez ensuite utiliser cette adresse 0x3FF (surtout son contenu !) dans VOTRE programme avec les quelques instructions prévues et citées précédemment.

6 Conclusions

Il reste l'incertitude des éventuelles conséquences de l'apparition presque simultanée des tensions 5V et 12V, pour la modification du §5, mais je reste très optimiste au vu de mes essais, car de toutes façons, il me semble tout de même beaucoup plus logique et même prudent de ne pas laisser un micro contrôleur démarrer son programme particulier sur le codeur, alors qu'il n'a pas le hardware qui lui correspond.

Est-ce une erreur de conception ou une obligation réelle ? Je ne saurais le dire, mais voilà assez longtemps que je m'étais posé cette question suite à des erreurs en vérification sur l'EEPROM, et je constate effectivement que cela peut poser des problèmes lors du codage.

Si MICROCHIP lit mes blogs, j'aimerais que quelques petits PIC à 10 et 12 broches soient développés, car les modèles 12F sont seulement à 8 broches et il en manque souvent quelques unes, ainsi que quelques facilités complémentaires des plus grands PIC  (capture, RS232,...)... !

D'autre part j'ai remarqué que la valeur initiale OSCCAL fournie par le constructeur ne correspond pas toujours exactement à celle mesurée par mon oscillo, alors je préfère ma propre valeur mesurée à l'aide du TEKTRO TDS220 qui me parait plus proche de la réalité. (J'ai fait la contre mesure qui confirme mes propos, à moins que TEKTRO en visu ET en "measure" soit faux, ce dont j'ai quelques doutes...)

(On ne tombe jamais sur une valeur précise, mais seulement très proche, car ce n'est pas un oscillateur de précision mais seulement un oscillateur de type RC, aussi il serait illusoire d'attendre une précision identique à celle d'un quartz). Pour ma part je regarde seulement la soustraction par "notcarry" (NC) et je n'attends donc pas une égalité qui serait toujours impossible à trouver.
Je pense que MICROCHIP procède de façon similaire sans chercher de toutes façons l'écart le plus faible, soit par le haut ou par le bas ou autour du point central pour qu'une première valeur tombe dans les spécifications annoncées, ce qui sera suffisant. (Fourchette donnée de ± 40KHz pour 4MHz).

Dans tous les cas vous aurez passé un bon moment à vous casser la tête sur cette prose pas trop facile à suivre pour le profane, et surtout pour ceux qui ne programment qu'en langage C, assez loin des problèmes hardware.

J'ai volontairement fait beaucoup de "redites" pour toujours bien re-situer les différents éléments, car on peut vite se perdre entre le programme de recherche, votre programme, l'EEPROM, l'adresse programme 0x3FF, le programme Picprog, le codeur... Ce n'est pas toujours facile à comprendre !
 
OSSCALement vôtre,

bricolsec/lokistagnepas.