Pic et MPLAB : comment intégrer mes données E EPROM dans le .hex avec le firmware ?

Bonsoir à tous,

j'aimerai intégrer des données stockées en zone eeprom dans le .hex que me génère MPLAB lors de la compilation de mon firmware. Le but étant que le .hex contiennent ET le programme et ces données.

Vous savez comment on fait ? merci Laurent

Reply to
Laurent CLAUDE
Loading thread data ...

On Oct 22, 7:26 pm, Laurent CLAUDE

Je suppose que ces donn=E9es sont disponibles lors de la compilation ? Si oui, en principe il suffit de les int=E9grer dans ton code source, en les d=E9clarant dans un buffer (const unsigned char par exemple) pour qu'elles soient pr=E9sentes dans le HEX file.

Reply to
Jean-Christophe

Le 22/10/2010 23:13, Jean-Christophe a écrit :

Oui tout à fait, les données son dispo à la compilation. Ce que je fait actuellement est de les intégrer dans la mémoire programme, en déclarant ma variable comme ça :

#pragma udata BYTE tableauConfig [4][25] = {0x00, 0x04, 0x0D, 0x07, 0x0C, .... etc

Mais je souhaite maintenant déplacer ces données en eeprom, à une adresse personnalisable.

Ce qui me manque c'est l'instruction (ou la directive) de déclaration en eeprom.

Merci de vos lumières, Laurent

Reply to
Laurent CLAUDE

il y a aussi la directive de compilation DE de MPLAB.

formatting link

FS

Le 23/10/2010 08:58, Laurent CLAUDE a écrit :

Reply to
fabriceS

Le 23/10/10 08:58, Laurent CLAUDE a écrit :

Et la ca dépend vraiment de ton compilateur. Il doit y avoir quelque part, déclaré un segment EEPROM. Par exemple gcc doit faire cela (et ca dépend encore de l'arch cible ...) const unsigned char[] = __atribute__( (section(".eeprom")) ) ="Mon joli tableau 1D"

Si c'est gcc que tu utilise je te conseille ce lien

formatting link

qui décrit les extensions (bien pratiques) GNU au C/C++

Voila. Ai je été assez clair ?

Reply to
Habib Bouaziz-Viallet

Le 23/10/10 09:56, Habib Bouaziz-Viallet a écrit :

Oh horreur ! C'est cela plutôt : const unsigned char[] __atribute__( (section(".eeprom")) ) = "Mon joli tableau 1D"

scouzi.

Reply to
Habib Bouaziz-Viallet

Le 23/10/2010 10:08, Habib Bouaziz-Viallet a écrit :

oui, tout à fait.

Alors mon compilo est MCC18 la cible est un PIC18F

...

Reply to
Laurent CLAUDE

Le 23/10/2010 10:38, Laurent CLAUDE a écrit :

ça y'est j'ai quelque chose, mais j'y suis allé à tâtons (...), donc merci de me relire et de commenter si vous voyez des trucs pas clairs !

#pragma romdata eedata=0xF00010 rom BYTE tableauConfigeeprom [4][25] = {0x00, 0x04, 0x0D, 0x07, .... etc

Reply to
Laurent CLAUDE

On Oct 23, 8:58 am, Laurent CLAUDE

Je vois qu'il s'agit d'une centaine d'octets de configuration de ta carte ( la config par d=E9faut, sans doute ? )

Dans ce cas ce que je fais parfois est de d=E9clarer ce tableau en const et log=E9 en ROM (non modifiable pour retrourner =E0 cette config par d=E9faut en cas de besoin) A la toute premi=E8re mise sous tension le soft copie cette table en EEprom, et aux mises sous tension suivantes il ne le fait pas car il sait que cela a d=E9ja =E9t=E9 fait ( grace =E0 un bit en EEprom ) Ensuite l'utilisateur peut =E9ventuellement modifier =E0 volont=E9 cette config non volatile dans l'EEprom.

L'avantage est que l'on garde la s=E9curit=E9 de pouvoir retourner =E0 la config par d=E9faut en cas de crash s=E9rieux ou autre al=E9a critique. ( c'est l'option =AB retour =E0 la config d'usine =BB ) Maintenant, =E0 toi de voir si c'est utile ou pas pour ton appli.

Reply to
Jean-Christophe

Le 23/10/2010 14:38, Jean-Christophe a écrit :

Oui, c'est exactement ce que je fais !

en fait ta remarque me fais dire que je n'ai pas la nécessité d'intégrer toutes ces données en eeprom avec le .hex. Il me suffit juste d'intégrer le bit de "retour config d'usine"

Et dire que j'allais tout mettre... Merci, ça va alléger le bousin !

laurent

Reply to
Laurent CLAUDE

On Oct 23, 3:07 pm, Laurent CLAUDE

| Maintenant, =E0 toi de voir si c'est utile ou pas pour ton appli.

Ok.

Tu n'as pas meme besoin d'int=E9grer dans le HEX le moindre octet EEprom, il suffira d'avoir la config par d=E9faut dans une zone ROM non volatile.

Une EEprom vierge =E9tant =E0 0xFF, =E0 chaque boot ton programme va v=E9rifier si le bit =AB retour =E0 la config d'usine =BB est =E0 '1' sachant qu'=E0 la toute premi=E8re mise sous tension ce sera le cas.

- Si le bit est =E0 '1' le soft copie la config par d=E9faut de la ROM vers l'EEprom puis il met ce bit =E0 '0'.

- Si le bit est =E0 '0' le soft ne touche =E0 rien.

Maintenant, pour d=E9clencher le =AB retour =E0 la config d'usine =BB il suffit de mettre ce bit =E0 '1' puis de rebooter le firmware.

De rien :-)

Reply to
Jean-Christophe

Le 23/10/2010 15:35, Jean-Christophe a écrit :

Oui en effet, sauf que dans mon contexte j'ai quand même besoin de mettre à 1 mon bit de retour config usine, par ce que mon application, quand il y' aura une nouvelle version, sera mise à jour par l'utilisateur (via un bootloader), et si je ne repositionne pas ce bit avec le .hex alors il risque d'hériter des l'anciennes données eeprom qui ne correspondront pas forcément...

Mais c'est cool, j'avance ! Laurent

Reply to
Laurent CLAUDE

Laurent CLAUDE a ecrit

suggestion Selon tes versions de soft tu compare à l'init une constante contenant la version du soft, (à voir pour dimensionner mais déjà sur 16 bits ça laisse du temps au temps :D )cette valeur avec le contenu déjà en eeprom (mettre ça à la fin de la zone eeprom est la solution la plus simple sauf si d'autres imperatifs viennent s'ajouter) Et en fonction de la lecture et par comparaison tu peux jouer à faire ce que tu veux !

Rvl

Reply to
rvlegran

Laurent CLAUDE a ecrit

suggestion Selon tes versions de soft tu compare à l'init une constante contenant la version du soft, (à voir pour dimensionner mais déjà sur 16 bits ça laisse du temps au temps :D )cette valeur avec le contenu déjà en eeprom de la version precedemment implementée (mettre ça à la fin de la zone eeprom est la solution la plus simple sauf si d'autres imperatifs viennent s'ajouter) Et en fonction de la lecture et par comparaison tu peux jouer à faire ce que tu veux !

Rvl

Reply to
rvlegran

Le 23/10/2010 16:31, rvlegran a écrit :

oui, c'est une solution qui rajoute sont lot de possibilités ... et de complications (du boulot quoi !). Je ne crois pas en avoir besoin actuellement ;-)

mais je me note cette astuce intéressante, elle peut ouvrir des pistes ! Merci

--
Laurent.

---------------------------------------------

laurent (point) claude (chez) free (point) fr

---------------------------------------------
Reply to
Laurent CLAUDE

On Oct 23, 5:07 pm, Laurent CLAUDE

| Le 23/10/2010 16:31, rvlegran a =E9crit : | Selon tes versions de soft tu compare =E0 l'init une constante contenant | la version du soft, (=E0 voir pour dimensionner mais d=E9j=E0 sur 16 bits =E7a | laisse du temps au temps :D )cette valeur avec le contenu d=E9j=E0 en eeprom | de la version precedemment implement=E9e (mettre =E7a =E0 la fin de la zone | eeprom est la solution la plus simple sauf si d'autres imperatifs | viennent s'ajouter) Et en fonction de la lecture et par comparaison | tu peux jouer =E0 faire ce que tu veux !

Ca sent le v=E9cu ;-)

Bof, pas tant que ca par rapport =E0 ce que ca apporte. Dans ton source un #define pour le num=E9ro de version, une petite fonction pour v=E9rifier l'up-date : 3 fois rien.

L'exp=E9rience montre qu'on regrette toujours de n'avoir pas pr=E9vu =E0 l'avance l'ouverture de choix pour l'avenir. Je ne sais pas s'il s'agit d'une r=E9alisation perso ou d'un projet pour un employeur (ou un client) mais si ta carte s'utilise beaucoup, tu seras content d'avoir pr=E9vu la possibilit=E9 d'un up-date automatique, ( c-=E0-d sans avoir =E0 envoyer un tech chez le client ) meme si pour l'instant cela te semble superflu.

!
Reply to
Jean-Christophe

Le 23/10/2010 20:47, Jean-Christophe a écrit :

oh, mais je n'ai pas pris cette astuce à la légère, comme je l'ai écrit je la trouve intéressante. Actuellement (à court terme) je vais m'en passer, sachant que je travaille avec un bootloader je pourrais faire ce genre d'ajouts quand mon soft sera plus globalement abouti. Je gère mes priorités.

Mais merci Jean-Christophe d'insister, je vais la noter *en gras* ;-) et y réfléchir, assurément.

--
Laurent.

---------------------------------------------
Pour me contacter en direct :
laurent (point) claude (chez) free (point) fr
Reply to
Laurent CLAUDE

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.