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.
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.
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 :
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++
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.
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 !
| 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.
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...
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 !
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 !
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
| 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.
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
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.