ABCelectronique : portail d'information dans le domaine de l'électronique
Recherche sur le site
 
 
  Home » Forum de discussion » Archive Forum » fichier HEX PIC 16F84  

Sujet: fichier HEX PIC 16F84

samy
Date: 2004-06-10 00:11:04
Salut,

Mon soucis est que je ne copmprend pas tres bien les 1ko de mémoire pour ce micro PIC 16F84), en effet lorsque je compile un programme avec MPLAB il me crée un fichier Hexa de 3ko sans m'indiquer d'erreur.
Est ce que quelqu'un peut m'expliquer comment evaluer la taille d'un programme ( ou le principe d'allocation de la memoire et la compilation d'un programme source afin qu'il soit déstiné à ce dit µC en étant sûre que ce programme pourra être logé et fonctionner de façon certaine dans ce µC) et comment être sûre qu'il va fonctionner dans le µC selectionné?

Merci
picsou
2004-06-10 00:28:10
3ko est la taille du fichier texte qui n'a rien à voir avec la taille de votre programme
il y'a dans ce fichers des données qui ne seront pas enregistré dans la mémoire du PIC16F84.
si ton programe dépasse la mémoire du µc alors l'assembleur ou le compilateur doit le signaler
bon courage
Gilles
2004-06-10 01:56:59
Bonjour
Pour le F84, les 1K signifie 1000 mots de 14bits, cela te donne 1000 lignes en assembleur, dans ton programme. Je parle des lignes signficatives, pas les instructions qui servent au reglage de ton compilateurs (include define org etc), pas les commentaire et pas les labels. Cela te laisse de la marge. Pour connaitre la place occupée par ton programme, sous Mplab, tu peux regarder à la fin de "absolute listing" le nombre de mots (de 14 bits) utilisés (Program Memory Words Used) et de mots disponibles (Program Memory Words Free).
Gilles
samy
2004-06-10 09:04:09
je ne parle pas du listing de mon programme je parle de l'objet ( le fichier issu de la compilation .HEX ) qui est destiné à être logé dans le µC.

je sais que le 16F84 peut contenir 1k mot de 14 bit mais je ne comprends pas pk lorsque je compile j'ai un .HEX de 3Ko alors que normalement il devrais m'indiuqer une erreur.

Petite précision en ce qui concerne les paramètres du projet sous MPLAB tout est ok; programme en C avec compilateur CCS; type de µC selectionné dans developement.... PIC16F84 etc....

J'ai lu sur certains site que le fichier HEX devait avoir 1ko ( fribotte etc...) mais j'ai trouvé sur le net des fichier HEX destinés aux 16F84 qui font 1ko, 2ko, 3ko etc.... et depuis que j'ai vu ça je ne sais pas comment je dois comprendre et interpreter la taille des fichiers HEX issu de la compilation.


constantin
2004-06-10 10:55:56
Salut
la taille des fichier hex est la taille qu'il occupe sur le systeme d'explotation de ton pc

En faite fichier hex est un fichier text qui sera intreté par le progammeur.

edit le avec notepad .
il ya d'ailleurs différent standard ds les fichiers hex.

a+
Sethy
2004-06-10 12:15:31
Moi je dirais qu'étant donné qu'un nombre 8bit dans un fichier hex se présente sous la forme :

0C 0D 0C ...

Cela fait 3 bytes par octet ...

Thierry

samy
2004-06-10 12:24:19
ok merci les gars mais pourquoi sur le site http://fribotte.free.fr/bdtech/cours/pic16f84/PART1_cours03.html
ils mettent :

CUT-------------------------------------------------------------

La mémoire programme est constituée de 1K mots de 14 bits. C’est dans cette zone que vous allez écrire votre programme. Ceci explique pourquoi vos fichiers sur PC font 2Kbytes.

CUT-------------------------------------------------------------

je suis complétement largué par rapport à ça.

tgq
2004-06-10 14:11:42
si tu veux vraiment savoir comment c'est fait tu regarde
http://users.swing.be/gonzague.colpaert/intelhex.html
et tu compte de nb de caractères nécessaires pour un mot de 14 bits + les header et fin de fichier
samy
2004-06-10 15:53:13
Ok merci je vais regarder ça de plus près.
samy
2004-06-10 22:07:34
juste une derniere question, mis à part la longueur des mots ( dans notre cas 14 Bits ) tous les fichiers hexa ont se format quelque soit le type de micro ?
Bigonoff
2004-06-11 00:02:34
Salut
-----

Quand je dis que les fichiers stockés sur PC font 2 Koctets, je parlais du CONTENU des fichiers .hex, dont l'adressage s'étend sur 2 Koctets, et pas de la TAILLE PHYSIQUE que le fichier hex occupe sur le disque.

C'est vrai que ça prête à confusion.

En fait, si tu ouvres un fichier .hex d'un 16F84 "rempli" avec un éditeur, tu verras que tu as 2Koctets utilisés dans le fichier.
C'est dû au fait que chaque adresse mémoire programme du pic doit être stockée sur 2 octets dans le fichier .hex.
La taille mémoire qui semble être utilisée par le fichier .hex est donc le double de la taille mémoire du PIC exprimée en mots de programme.

C'est également pourquoi si tu prends un programmateur universel, et que tu examines le buffer (exprimé en octets), tu verras également que le buffer d'un 16F84 s'étend sur 2 Koctets.

A+
Bigonoff
Bigonoff
2004-06-11 00:04:05
Salut bis
----------

Pour le format .hex, il y a plusieurs types de format.

Ce sont des standards, et ils ne dépendent pas du type de micro utilisé.

La structure d'un fichier .hex telle que celle dont tu parles est donnée dans l'aide de MPLAB.

A+
Bigonoff
samy
2004-06-11 01:53:18
Merci beaucoups pour toutes ces infos.... c'est bête mais j'ai tapé une multitude de programme et c'est la 1ere fois que je me heurte à ce problème... en fait j'ai fait ( en quelque sorte ) exprès d'utiliser un 16F84 pour ma derniere application en sachant que je risquais d'avoir ce type de problème en me disant qu'il suffira d'essayer d'optimiser le code, mais j'ai négligé le fait que j'allais me heurter à un malentendu....
Effectivement quand on compile un programme et qu'il n'y a pas d'erreur de compilation on obtient ce type de message :

ROM used: 0 (0%)
Largest free fragment is 1024
RAM used: 59 (87%) at main() level
68 (100%) worst case
Stack: 4 worst case (2 in main + 2 for interrupts)


et on ne comprend pas de suite pourquoi le compilateur refuse de créer le fichier objet, ensuite quand on creuse on se rend compte qu'en supprimant quelque ligne ( ou variable ) et qu'on obtient un fichier HEX; il ne correspond pas à ce qui est expliqué sur le net..


samy
2004-06-11 01:56:31
au fait une dernière question sur ce message ... 68 (100%) worst case ....
c'est bien un problème de variable que j'ai ?
en fait la RAM et surutiliée n'est ce pas ?
Don y'a trop de variable?

Merci encore

samy
2004-06-11 17:46:37
J'ai trouvé pourquoi le compilateur ne veut pas créer d'objet ( HEX )... oui quand j'ai reussi à compiler mon programme( en supprimant une grande partie de celui-ci ) alors le fichier HEX pesait 3Ko alors j'ai pensé que le compilateur deconnait, jusqu'à ce Bigonoff m'éclaire.

En fait en tattonant et en baissant le nombre de variable ( en les supprimant ) j'ai constaté que le compilateur créait un fichier HEX ... Ce qui m'amène à une nouvelle question:

Quel est le nombre MAx de variable que l'on peut créer pour un PIC 16F84 ?

Merci
Bigonoff
2004-06-11 19:38:51
Salut
------

Sur le 16F84, on dispose de 68 octets de RAM (donc 68 variables différentes de type octet, ou 34 de type mot de 16 bits etc).

MAIS, on utilise en général des variables locales. Ces variables n'ont qu'une durée de vie limitée à une sous-routine particulière et peuvent donc être réutilisées par une autre.

Si on programme en assembleur, on voit très bien l'utilisation de la mémoire RAM, et on maîtrise son utilisation.

Par contre, dans un langage évolué (C, basic etc), le compilateur prend une partie des optimisations en charge.
La façon dont il le fait dépend de la façon dont est écrit le code, et de la façon dont le compilateur travaille.
Il est dans ce cas intéressant pour l'utilisateur de se renseigner sur les syntaxes pour forcer certaines variables à travailler en mode local.

Pour te donner un exemple :

Si tu as besoin d'une variable "i" pour stocker un compteur de boucles
dans une routine, et d'une variable "j" pour le résultat d'un test dans une autre routine,

- A partir du moment où la première routine est toujours terminée lorsque tu appelles la seconde, rien n'empêche d'utiliser l'emplacement de la variable "i" pour stocker le résultat "j". Dans ce cas, un seul emplacement est utilisé.

- PAr contre, si la routine 2 est appelée dans la boucle de la routine 1, alors l'utilisation du même emplacement pour "i" et "j" détruirait le compteur de boucles "i" avant la fin de son utilisation.

Tu vois donc qu'il n'est pas simple, en utilisant un compilateur, de prévoir avec exactitude la taille de la RAM utilisée.

Donc, si tu me suis, il est impossible de répondre à ta question, à savoir "combien de variables peut-on utiliser dans un programme".

Tout au plus, je peux te dire que tu as droit à 68 octets différents pour l'intégralité de ton programme.

A+
Bigonoff
samy
2004-06-12 03:26:37
Merci beaucoups pour toutes ces infos....
et effectivement habitué à taper mes codes en assembleur, je me suis heurté à une multitudes de questions qui m'ont eclairci ( grace à vous ) plus en detail le " coté obscur des µC " à savoir que ce que l'on croit évident ne l'est pas dans tous les cas.

En fait pour ceux qui liront ce post et qui debutent dans la programmation des µC je leur conseil de débuter sur des petit µC style 16F84 car la limitation de la mémoire vaut mieux la subire au debut de son apprentissage, que plus tard, après être passer par de plus gros µC style ( 16F876 voir 16F877 ), car ce type de µC pour les charger à fond il faut vraiment avoir un mege projet, bien que l'on soit tenter de les privilegier à la place des plus petits, car il nous apporte beaucoups plus de souplesse d'utilisation ( plus d'entrée/sortie, plus de timer, etc...) ça ne rend pas service de chercher le plus souple.

Perso j'ai fait exprès de faire un de mes 1er code en C pour le 16F84 car je savais que j'allais me heurter à ce type de problèmes qui me forceront à chercher plus en detail le lien abstrait entre le code en langage évolué et le langage machine ( µC ) et je peux vous confirmer que le fait de faire ces codes en assembleur est plus aisé, quand on veut maitriser des evenements, que le langage C.


Merci de votre aide et grace à vous je vais enfin pouvoir dormir et me coucher moins bête ;-)