Bonjour à tous, voilà j'ai une petite question. Je suis développeur, je fais du soft embarqué sur un oscilloscope. Nous utilisons comme noyaux temps réel VxWorks. Le micro utilisé dans l'appareil est un ppc mpc823. Ma question va venir. Sur VxWorks 5.4 et tornadoo 2.0 nous avons 4 méthodes pour construire notre projet:
 1-VxWork : le soft est chargé par Ethernet directement en ram. C'est le build que nous utilisons pour débuguer. Explication fournit par VxWorks sur ce build(RAM based VxWorks image, linked to RAM_LOW_ADRS. It is loaded into RAM via some external program such as a bootROM. This is the default development image.)
 
2-VxWork_rom : Le soft est d'abort stoké en flash puis au démarrage de l'appareil le code et tous l'appli sous chargé en ram. L'application fonctionne en ram. C'est le build que nous utilisons pour la production. Explication fournit par VxWorks (RAM based image that starts in ROM. The ROM startup code copies the entire image to RAM and then jumps to it. This image generally has a slower startup time, but faster execution time, than vxWorks_romResident)  
 
3- VxWorks_romCompress Comme précédement le soft est stoké en Flash et en plus il est compressé. Au démarrage de l'appareil le code est d'abort décompressé puis chargé en RAM.L'application fonctionne en ram. Explication fournit par VxWorks(Compressed RAM based image that starts in ROM. This image can fit almost twice the code as other ROM images. But it has the slowest boot time, since the image must be uncompressed. The run-time speed is the same as for vxWorks_rom)
 
4- Et enfin quatrième et dernière possibilité: Le soft est stoké en en Flash. Au démarage de l'appareil l'application fonctionne directement en flash. Ce système fonctionne plus lentement mais permet de gagner de la place en RAM.Explication fournit par VxWorks(ROM resident image. The program text remains in ROM, only the data is copied to RAM. This image has the fastest boot time and uses the least amount of RAM, but runs slower on boards with slow ROM access).
 
Nous avons testé et validé les 3 premiers points, nous n'avons eu aucun problème.Maintenant avec le temps qui passe l'application grossie et nous voulons gagner de la place dans la ram. Donc la solution est d'utiliser la solution 4 et la impossible ça marche pas. En fait l'application commence bien à démarrer mais elle se plante au bout d'un moment plus exactement dans le fichier usrCache.c dans la fonction usrCacheEnable() apres l'instructions  cacheEnable (DATA_CACHE). Malgrés de multiple recherche sur le net je n'ai trouvé aucune solution.  
Si quelqu'un a déjà travaillé sur VxWorks et utilisé l'option VxWorks resident peut être pourra t'il me renseigner?
Si quelqu'un a des renseignement sur le fait qu'un mpc823 peut bloquer en utilisant VxWork resident peut 'il m'aider?
A l'aide svp.
help me.  
 

Bonjour,
 
Je pense pas que tu sois sur le bon forum, essaye plutôt un newsgroup comme comp.os.vxworks.
 
Fais aussi attention à ta flash, si tu fais beaucoup de lectures/écritures dessus, tu risques de la faire vieillir rapidement.
 
Tu ne peux pas désactiver le cache?
 
vw

ok merci pour ton aide Combi_A_Vendre j'ai effectivemnt déjà écrit sur le forum comp.os.vxworks. en faite j'arrose un peu partout pour avoir une réponse.
 

Tu n'as pas de support avec tes licences Tornado? Moi j'en avais et c'était plutôt efficace.
 
vw

Tu veux dire l'aide par internet. Si c'est ça on ne paye plus donc on a plus le droit. Dans la doc en elle même j'ai fouillé et refouillé pas moyen. En faite on ne comprend pas pourquoi dans ce mode de build cela ne marche. Tous les autres modes ont été validée donc cela veut dire que les option du fichier config.h sont correctes. Sinon j'ai eu deux reponses sur le forum comp.os.vxWorks mais je n'ai pas eu encore le temps de les mettres en application je vais essayer.

arf! La solution est peut être Xenomai avec la skin vxworks alors
Bon courage.

cela va te paraître idiot mais je ne connais pas le terme Xenomai tu peux m'aider.

Non non, ça ne me parait pas idiot !
Xenomai est un patch temps réel sous GPL pour Linux. C'est un co-kernel qui permet de faire du temps réel dur. Ca marche très très bien (jitter<20µs même avec l'interface graphique d'activée) et ça a plein de fonctionnalités intéressantes. Par exemple, on peut avoir un tic oneshot et pas que du périodique comme sous VxWorks.
Et donc il y a des "skins" avec qui te permettent de porter pas trop difficilement ton code VxWorks.

vw