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
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
bonjour,
j'ai continué mes tests avec XC8 ...
pas moyen de depasser 823 blocs de 128 bytes en flash
et pourtant
Memory Summary:
Program space used 168Ch ( 5772) of 2300h bytes ( 64.4%)
Data space used 1F9h ( 505) of 2000h bytes ( 6.2%)
Configuration bits used 5h ( 5) of 5h words (100.0%)
EEPROM space used 0h ( 0) of 400h bytes ( 0.0%)
ID Location space used 10h ( 16) of 10h bytes (100.0%)
avec #define FLASH_ROW_ADDRESS 0x2300
et customise config linker memory model range 0-27FF
ça devrait le faire !
MAIS XC8 stocke des datas en FLASH ... pendant le run time !
J'ai limité au maximum les impressions sur terminal via CPrint et l'usage de sprintf ..
et malgré tout , deja 5572 bytes annoncés ..
j'ai utilisé Compiler Advisor ...
La messe est dite .. il faudrait la version PRO !
donc je laisse tomber ..
actuellement , seule une taille maxi de 70Ko peut passer correctement, avec une restitution sonore complete et OK.
et sans effet de bords sur la fin du programme.
à noter , que l'echelle ne part pas depuis Zero,
pour renforcer l'argument Publicitaire de la version PRO !
L'un de vous possede-t-il la version pro ?
meme si je peu lire (et affecter en flash) 823 blocs / 832= taille totale
le code final n'etant pas executé !
pas de print sur terminal ? mais pas de plantage ?
..simplement la restitution sonore se passe mal sur la fin
conclusion : LA ZONE FLASH n'est pas complement libre avec XC8 !
le fichier *.map ou *.lst resultant de la compilation est trop indigeste !
le resumé "Memory Summary" n'est pas fiable ..puisque ne precise qu' une zone occupée que de 5772 bytes en flash
comparé aux statistics données coté MikroC
ou chaque fonctions sont bien delimités et l'espace RAM , ROM aussi.
y a pas que du mauvais !
c'est bien ce que j'avais déja remarqué, MikroC PRO est plus performant que XC8 (en version libre).
......Allez un dernier essais avec MikroC
en enlevant aussi les sprintf ou CPrint .. pour voir ! et clore ce sujet .
mais quand meme , en utilisant les fonctions FLASH XC8 .. qui sont déja quasiment à 99% .. en ASM !
nota:
J'ai exactement le meme comportement du programme avec les
fonctions Flash XC8 originales (MCC) qu'avec tes fonctions (C)Satinas.
exemple OK , avec bourrepif_11025_Mono_8b_4.86sec.wav
j'ai continué mes tests avec XC8 ...
pas moyen de depasser 823 blocs de 128 bytes en flash
et pourtant
Memory Summary:
Program space used 168Ch ( 5772) of 2300h bytes ( 64.4%)
Data space used 1F9h ( 505) of 2000h bytes ( 6.2%)
Configuration bits used 5h ( 5) of 5h words (100.0%)
EEPROM space used 0h ( 0) of 400h bytes ( 0.0%)
ID Location space used 10h ( 16) of 10h bytes (100.0%)
avec #define FLASH_ROW_ADDRESS 0x2300
et customise config linker memory model range 0-27FF
ça devrait le faire !
MAIS XC8 stocke des datas en FLASH ... pendant le run time !
J'ai limité au maximum les impressions sur terminal via CPrint et l'usage de sprintf ..
et malgré tout , deja 5572 bytes annoncés ..
j'ai utilisé Compiler Advisor ...
La messe est dite .. il faudrait la version PRO !
donc je laisse tomber ..
actuellement , seule une taille maxi de 70Ko peut passer correctement, avec une restitution sonore complete et OK.
et sans effet de bords sur la fin du programme.
à noter , que l'echelle ne part pas depuis Zero,
pour renforcer l'argument Publicitaire de la version PRO !
L'un de vous possede-t-il la version pro ?
meme si je peu lire (et affecter en flash) 823 blocs / 832= taille totale
le code final n'etant pas executé !
pas de print sur terminal ? mais pas de plantage ?
..simplement la restitution sonore se passe mal sur la fin
conclusion : LA ZONE FLASH n'est pas complement libre avec XC8 !
le fichier *.map ou *.lst resultant de la compilation est trop indigeste !
le resumé "Memory Summary" n'est pas fiable ..puisque ne precise qu' une zone occupée que de 5772 bytes en flash
comparé aux statistics données coté MikroC
ou chaque fonctions sont bien delimités et l'espace RAM , ROM aussi.
y a pas que du mauvais !
c'est bien ce que j'avais déja remarqué, MikroC PRO est plus performant que XC8 (en version libre).
......Allez un dernier essais avec MikroC
en enlevant aussi les sprintf ou CPrint .. pour voir ! et clore ce sujet .
mais quand meme , en utilisant les fonctions FLASH XC8 .. qui sont déja quasiment à 99% .. en ASM !
nota:
J'ai exactement le meme comportement du programme avec les
fonctions Flash XC8 originales (MCC) qu'avec tes fonctions (C)Satinas.
exemple OK , avec bourrepif_11025_Mono_8b_4.86sec.wav
Code : Tout sélectionner
Etape 0
.. Attente IT RX UART1 pour capture fichier wav
Etape 1
Reçu :
RIFFüÅ
Fichier RIFF !
Global File size = Global File size = 50440 bytes
Fichier WAVfmt ..OK
Taille Data = 50176 bytes
MaxBloc= 0391
Etape3 ,lecture datas
Bloc# L2 adresse
0001 00002800
0002 00002880
0003 00002900
...
0390 0000EA80
0391 0000EB00
Fin de lecture data wave
Etape 4
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
formatage long int 32 bits, MPLAB bad, MikroC OK
Bonjour Paul,
C'est très étonnant si le compilateur de son propre chef décide de faire des écritures dans la flash lors de l'exécution du programme. J'ai testé ton programme, mais n'ayant pas branché le port série, j'ai refait l'ajout ci-dessous. Le programme écrit donc toute la flash disponible, il la remplit avec l'octet 0x34.
Après lecture IPE du pic après programmation et après exécution, pas de problème. Peux-tu faire la même manip avec ton programme non modifié et sortir les 2 mêmes fichiers hex IPE ?
Merci
Bon après un café corsé, j'ai retrouvé la vue ;-)
Seule la page 0xB300 est incorrecte car effacée, c'est peut être un problème d'écriture ? Dans le test il n'y a aucune tempo à l'écriture flash. Je continuerai le test un peu plus tard.
C'est très étonnant si le compilateur de son propre chef décide de faire des écritures dans la flash lors de l'exécution du programme. J'ai testé ton programme, mais n'ayant pas branché le port série, j'ai refait l'ajout ci-dessous. Le programme écrit donc toute la flash disponible, il la remplit avec l'octet 0x34.
Après lecture IPE du pic après programmation et après exécution, pas de problème. Peux-tu faire la même manip avec ton programme non modifié et sortir les 2 mêmes fichiers hex IPE ?
Merci
Code : Tout sélectionner
case 0:
CRLF1();
CPrint(" Etape 0\r\n.. Attente IT RX UART1 pour capture fichier wav \r\n");
i1=0;
Index1=0;
RAZ_UART1_Buffer1() ; // arme Interrupt UART Rx
__delay_ms(1000);
for (L2=0; L2<128; L2++) Buffer1[L2] = 0x34;
for (L2 = 0x2800; L2 < 0x20000 ; L2 += 128) {
FLASH_EraseBlock(L2);
FLASH_WriteBlock(L2, Buffer1);
}
break;
Bon après un café corsé, j'ai retrouvé la vue ;-)
Seule la page 0xB300 est incorrecte car effacée, c'est peut être un problème d'écriture ? Dans le test il n'y a aucune tempo à l'écriture flash. Je continuerai le test un peu plus tard.
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
formatage long int 32 bits, MPLAB bad, MikroC OK
Après ajout de 10ms derrière EraseBlock et 10 ms derrière WriteBlock, le problème persiste, c'est même pire. Cette fois les pages sont à 0x00. C'est vraiment surprenant. Je n'ai jamais approfondi comment marchait le debug, il doit mettre du code hors des zones programme, cela remet en question le fait de stocker des données dans la flash depuis le programme.
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
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 :...Je n'ai jamais approfondi comment marchait le debug, il doit mettre du code hors des zones programme,
cela remet en question le fait de stocker des données dans la flash depuis le programme.
tu actives le mode debug du PIC ?
J'ai fait ton 1er TEST , en rajoutant un clignotement de led , au debut et à la fin,
pour verifier que le test va bien jusqu'au bout sans perdre les pedales !
il s'avere que ce test remplit bien toute la Flash avec 4 (0x34) de 0x2800 à 1FFFF .. OK
Nota: je n'ai pas constaté de trou ou mauvaises valeurs stockées dans la flash..
mais le programme se plante en sortie !
La led ne clignote pas , et
le message CPrint("Fin test satinas\r\n");
n'est pas exécuté ?
Code : Tout sélectionner
// --- satinas test 26/09/2022 --------------------
j=0;
while (j<8)
{
Led_Rouge= !Led_Rouge;
__delay_ms(200);
j++;
}
Led_Rouge=1; //eteinte
for (L2=0; L2<128; L2++) Buffer1[L2] = 0x34;
for (L2 = 0x2800; L2 < 0x20000 ; L2 += 128)
{
FLASH_EraseBlock(L2);
FLASH_WriteBlock(L2, Buffer1);
}
j=0;
while (j<8)
{
Led_Rouge= !Led_Rouge;
__delay_ms(200);
j++;
}
CPrint("Fin test satinas\r\n");
while(1);
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
formatage long int 32 bits, MPLAB bad, MikroC OK
Tu actives le mode debug du PIC ?
J'ai n'ai pas compilé en mode debug, avec l'option menu "Build main project". Avec aussi un indicateur led de début et fin d'écriture, cela dure environ 3 secondes sans tempo, et 30 secondes avec les 2 tempos de 10ms.
Nota: je n'ai pas constaté de trou ou mauvaises valeurs stockées dans la flash.
Envoie l'hex à lire après exécution, merci
formatage long int 32 bits, MPLAB bad, MikroC OK
formatage long int 32 bits, MPLAB bad, MikroC OK
Ok, ton fichier est bon, mais le programme ne se termine pas bien, et chez moi il se termine correctement, mais le fichier résultant est pas bon.
J'ai testé ton dernier programme et il est bon, la led clignote, puis écriture flash (3s), puis reclignotement led. Après exécution et lecture par IPE, la flash est bien remplie de 0x34.
Tout cela me laisse perplexe.
J'ai testé ton dernier programme et il est bon, la led clignote, puis écriture flash (3s), puis reclignotement led. Après exécution et lecture par IPE, la flash est bien remplie de 0x34.
Tout cela me laisse perplexe.
formatage long int 32 bits, MPLAB bad, MikroC OK
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Pendant ce test ,mon terminal est connecté
et je vois defiler les 4 ... mais le terminal finit par s'engorger ...
donc je ne peux pas voir le message final..
mais je devrais quand meme voir la led clignoter ,apres la fin d'ecriture en flash
Euh..pourquoi je vois le terminal se remplir de 4 .. alors que je n'ecris pas sur l'UART pendant le remplissage Flash ??
Mystere et boule de suif !
on ne doit pas avoir la meme config ?
global:
C standard C90
Output file format EFL/DWARF
stack options auto
compiler options
Optimisation level 0
XC8 v 2.32
PIC18FK_DFP 1.5.114
j'espere que ce n'est pas Realterm qui seme le boxon !
je viens de faire le meme test avec YAT terminal...
idem
le clignotement est OK en fin d'ecriture
et les '4' ne s'affichent qu'apres
c'est peut etre à cause du CPrint("Fin test satinas\r\n");
le texte "Fin test satinas\r\n" remplacé, ecrabouillé par 44444444 et sans zero terminateur ..ça part en C......
et moi donc !
et je vois defiler les 4 ... mais le terminal finit par s'engorger ...
donc je ne peux pas voir le message final..
mais je devrais quand meme voir la led clignoter ,apres la fin d'ecriture en flash
Euh..pourquoi je vois le terminal se remplir de 4 .. alors que je n'ecris pas sur l'UART pendant le remplissage Flash ??
Mystere et boule de suif !
on ne doit pas avoir la meme config ?
global:
C standard C90
Output file format EFL/DWARF
stack options auto
compiler options
Optimisation level 0
XC8 v 2.32
PIC18FK_DFP 1.5.114
j'espere que ce n'est pas Realterm qui seme le boxon !
je viens de faire le meme test avec YAT terminal...
idem
le clignotement est OK en fin d'ecriture
et les '4' ne s'affichent qu'apres
c'est peut etre à cause du CPrint("Fin test satinas\r\n");
le texte "Fin test satinas\r\n" remplacé, ecrabouillé par 44444444 et sans zero terminateur ..ça part en C......
Satinas a écrit : Tout cela me laisse perplexe.
et moi donc !
Vous n’avez pas les permissions nécessaires pour voir les fichiers joints à ce message.
formatage long int 32 bits, MPLAB bad, MikroC OK
Tout est pareil car j'ai chargé direct ton projet zippé du post #11.
La seul différence est ma version de xc8 2.36, tu es en 2.32.
Ton programme est très chargé, difficile de s'y retrouver, trop dans le cumulatif.
Essaye sans les interruptions activées.
Pour le Cprint, peut être le while(1) ne lui laisse pas le temps de finir, mets une tempo avant le while.
La seul différence est ma version de xc8 2.36, tu es en 2.32.
Ton programme est très chargé, difficile de s'y retrouver, trop dans le cumulatif.
Essaye sans les interruptions activées.
Pour le Cprint, peut être le while(1) ne lui laisse pas le temps de finir, mets une tempo avant le while.
formatage long int 32 bits, MPLAB bad, MikroC OK
- paulfjujo
Expert- Messages : 2589
- Âge : 73
- Enregistré en : juillet 2015
- Localisation : 01800
- Contact :
Sans interruption activée
meme probleme
Apres l'ecriture en Flash ..OK
clignotement en fin d'ecriture OK
mais le CPrint m'affiche une floppée de '4' au lieu du texte prevu
je pense que XC8 stocke le texte définit en dur dans le programme, en flash
comme le fait d'ailleurs MikroC !
contre test :
texte en RAM au lieu de Flash
sur terminal
OK !!!
XC8 stocke bien des datas en Flash,en dehors de la zone specifiée via le linker !
Pas bien !
meme si je predefini d'abord le message en flash
celui est ecrasé au moment du run ,par l'ecriture de 4 en flash..
alors qu'au visu du fichier*.map
extraits du fichier MAP
Meme avec le message Msg1 (en flash) dans la zone protégée <=2300H
celui ci est verollé par les '4'
meme probleme
Apres l'ecriture en Flash ..OK
clignotement en fin d'ecriture OK
mais le CPrint m'affiche une floppée de '4' au lieu du texte prevu
je pense que XC8 stocke le texte définit en dur dans le programme, en flash
comme le fait d'ailleurs MikroC !
contre test :
texte en RAM au lieu de Flash
Code : Tout sélectionner
strConstRamCpy(CRam1,"Fin test satinas\r\n");
j=0;
while (j<8)
{
Led_Rouge= !Led_Rouge;
__delay_ms(200);
j++;
}
Led_Rouge=1; //eteinte
for (L2=0; L2<128; L2++) Buffer1[L2] = 0x34;
for (L2 = 0x2800; L2 < 0x20000 ; L2 += 128)
{
FLASH_EraseBlock(L2);
FLASH_WriteBlock(L2, Buffer1);
}
//Led_Rouge= 0;
j=0;
while (j<8)
{
Led_Rouge= !Led_Rouge;
__delay_ms(200);
j++;
}
// CPrint("Fin test satinas\r\n"); // donne 444444444444444444444444444
Print(CRam1); // OK !
while(1);
sur terminal
Projet MPLABX :18F27K42_Test_Ecr_Lec_Flash_2022-09.X
Etape 0
.. Attente pour capture fichier wav
Fin test satinas
OK !!!
XC8 stocke bien des datas en Flash,en dehors de la zone specifiée via le linker !
Pas bien !
meme si je predefini d'abord le message en flash
celui est ecrasé au moment du run ,par l'ecriture de 4 en flash..
alors qu'au visu du fichier*.map
extraits du fichier MAP
Code : Tout sélectionner
--acfsm=1493 -ACODE=00h-022FFh -ACONST=00h-022FFh \
-ASMALLCONST=02000h-020FFhx3 -AMEDIUMCONST=02000h-022FFh \
_GIE (abs) 01FE97
_GIEH (abs) 01FE97
CONST 000004-000007 4
000BBA-000BBB 2
00156C-002127 BBC
EEDATA 310000-3103FF 400
MEDIUMCONST 002000-002127 128
SMALLCONST 002000-002127 100
_Msg1 MEDIUMCONST 2151 0000 19
Name Load Length Top Selector Space Class
mediumconst 002128 0001D8 002300 1094 0 MEDIUMCO
Meme avec le message Msg1 (en flash) dans la zone protégée <=2300H
celui ci est verollé par les '4'
Modifié en dernier par paulfjujo le mar. 27 sept. 2022 09:40, modifié 1 fois.
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 54 invités