Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : Jérémy
formatage long int 32 bits, MPLAB bad, MikroC OK
Que l'impression se fasse depuis des données en flash ou en ram, cela ne change pas grand chose, car au départ toutes les chaînes littérales sont dans la flash, et donc dans le fichier HEX. Alors pourquoi le pic écrirait-il en flash lors de l'exécution, je ne vois toujours pas. T'es vraiment tenace, cela fait longtemps que je serais passé à autre chose :)
formatage long int 32 bits, MPLAB bad, MikroC OK
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
satinas a écrit :.... Alors pourquoi le pic écrirait-il en flash lors de l'exécution, je ne vois toujours pas...
n'écrit pas, mais va lire en flash le message à envoyer via CPrint ...sur le terminal.
Le message en flash qui était définit au moment de la programmation
est ensuite ecrabouillé par la sequence d'ecriture 0x34 ... de 0x2800 à 0X1FFFF
...et pourtant le Msg1 est situé avant 2800h (voir MAP)
et je vois bien la serie de '4' sur le terminal
si le message est en RAM, bien sur, non affecté par une écriture en flash..
Pourquoi et comment .. Là est la question ....
tu as raison, j'en fais une fixation !
.....et vais passer à autre chose , trop d'energie gaspillée la dessus.
encore pour ton implication
sujet à classer dans le dossier de MULDER et SCULLY ..
formatage long int 32 bits, MPLAB bad, MikroC OK
-
Jérémy
Administrateur du site- Messages : 2722
- Âge : 44
- Enregistré en : juillet 2015
- Localisation : Dans le sud
- Contact :
paulfjujo a écrit :Source du message sujet à classer dans le dossier de MULDER et SCULLY ..
Comme souvent avec les compilateurs !
formatage long int 32 bits, MPLAB bad, MikroC OK
formatage long int 32 bits, MPLAB bad, MikroC OK
-
Jérémy
Administrateur du site- Messages : 2722
- Âge : 44
- Enregistré en : juillet 2015
- Localisation : Dans le sud
- Contact :
C'est pas faux !
Je reste convaincu que dans l'un ou dans l'autre compilateur( quelques soit son prix) il y aura des coquilles. Avec le temps j'ai appris à me remettre en cause mais aussi les outils que l'on utilise et même la remise en cause de la façon de remettre en cause les outils qu'on remet en cause ...
Je reste convaincu que dans l'un ou dans l'autre compilateur( quelques soit son prix) il y aura des coquilles. Avec le temps j'ai appris à me remettre en cause mais aussi les outils que l'on utilise et même la remise en cause de la façon de remettre en cause les outils qu'on remet en cause ...
formatage long int 32 bits, MPLAB bad, MikroC OK
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonjour,
avec version MikroC Pro 7.60
Lecture d'un fichier Wav via UART 115200 bds et restitution via sortie PWM 11025Hz 8 bits ... OK
avec fichier Tou_nu_tou_bronze_10sec.wav 110Ko 874 blocs de 128 bytes .. 111910 Bytes
pas d'anomalie constatée!
derniere MAJ sur ma page
: +1: cette fois, pour MikroC !
les statistiques mikroC montrent une adresse haute de 9000 ..soit l'adresse maxi 0x2328
mais le tableau des adresses , montre des pointeurs FSR2PTR,FSR1PTR,FSR0PTR,TBLPR dans l'espace 0x3FD9 .. 0X3FF8
L'espace Flash dispo debuterait en 0x3000 ?
=> 20000-3000=1D000 => 118784 bytes maxima ?
d'ou la question :
XC8 utilise-t-il des adresse ROM au delà de l'espace reservé par le linker
ex: 0x2800h ROM programme reservé via 0 -27FF car alea de programme apres 828 blocs
sans pour autant planter completement le programme
avec MikroC ,l'offset Flash est le meme : 3000H
sans faire de réservation par ailleurs
donc au dessus de maxi 0x2328 mais en dessous de 0x3FD9 ?
La RAM de 8192 byte => adresse maxi 0x2000
J'avoue ne pas trop comprendre ces adresses .... si elle sont en FLASH
elles seraient ecrabouillées par l'application !
0 1144 Used RAM (bytes): 432 (5%) Free RAM (bytes): 7738 (95%)
0 1144 Used ROM (bytes): 10042 (8%) Free ROM (bytes): 121030
les stat ne peuvent pas montrer l'espace Flash occupé,
car celui est chargé en dynamique pendant l'execution du programme !
Je peux donc passer à autre chose , avec un programme qui marche ...
j'espere qu'il ne " tombe pas en marche " (Sic Daudet78)
02/10
Rajout option via etat pin RB2
RB2=0 on garde le dernier fichier wav chargé en flash .. rejoué directement (test si taille > 1024 bytes!)
RB2=1 saisie d'un nouveau fichier wav à charger en flash
un flag et la taille fichier étant stocké en Eeprom.. après une saisie correcte de fichier *.wav
avec version MikroC Pro 7.60
Lecture d'un fichier Wav via UART 115200 bds et restitution via sortie PWM 11025Hz 8 bits ... OK
avec fichier Tou_nu_tou_bronze_10sec.wav 110Ko 874 blocs de 128 bytes .. 111910 Bytes
pas d'anomalie constatée!
derniere MAJ sur ma page
: +1: cette fois, pour MikroC !
les statistiques mikroC montrent une adresse haute de 9000 ..soit l'adresse maxi 0x2328
mais le tableau des adresses , montre des pointeurs FSR2PTR,FSR1PTR,FSR0PTR,TBLPR dans l'espace 0x3FD9 .. 0X3FF8
L'espace Flash dispo debuterait en 0x3000 ?
=> 20000-3000=1D000 => 118784 bytes maxima ?
d'ou la question :
XC8 utilise-t-il des adresse ROM au delà de l'espace reservé par le linker
ex: 0x2800h ROM programme reservé via 0 -27FF car alea de programme apres 828 blocs
sans pour autant planter completement le programme
avec MikroC ,l'offset Flash est le meme : 3000H
sans faire de réservation par ailleurs
donc au dessus de maxi 0x2328 mais en dessous de 0x3FD9 ?
La RAM de 8192 byte => adresse maxi 0x2000
J'avoue ne pas trop comprendre ces adresses .... si elle sont en FLASH
elles seraient ecrabouillées par l'application !
0 1144 Used RAM (bytes): 432 (5%) Free RAM (bytes): 7738 (95%)
0 1144 Used ROM (bytes): 10042 (8%) Free ROM (bytes): 121030
les stat ne peuvent pas montrer l'espace Flash occupé,
car celui est chargé en dynamique pendant l'execution du programme !
Je peux donc passer à autre chose , avec un programme qui marche ...
j'espere qu'il ne " tombe pas en marche " (Sic Daudet78)
02/10
Rajout option via etat pin RB2
RB2=0 on garde le dernier fichier wav chargé en flash .. rejoué directement (test si taille > 1024 bytes!)
RB2=1 saisie d'un nouveau fichier wav à charger en flash
un flag et la taille fichier étant stocké en Eeprom.. après une saisie correcte de fichier *.wav
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 46 invités