formatage long int 32 bits, MPLAB bad, MikroC OK

[paulfjujo]

bonjour,

pour pouvoir passer un fichier wav de 106Ko, j'ai modifier la taille de mes compteur/pointeurs
de Word 16 bits -> Long 32 bits
or je constate que le formatage de sortie sur un long unsigned int
n'est pas OK avec MPLABX , alors que c'est correct avec MikroC
Le pire est que la valleur obtenue de la taille fichier ( File_Size) divisée par 128 (taille de bloc) , me donne quand meme un bon resultat
Nb de bloc 874 x 128 => 106112 =correct !
Le probleme ne serait qu la representation du nombre ,mais pas le nombre lui meme ..

voici les 2 versions
mikroC OK

Code : Tout sélectionner

//  *********************  TEST ZONE  **********************************************
unsigned long int File_Size;


       p1=&Buffer1[0]+40;
       *(p1)=0x26; *(p1+1)=0xB5;*(p1+2)=0x01;*(p1+3)=0; //  Exemple de datas lues depuis le fichier wav 
            memcpy(CRam1,p1,4);
   //       Imprime_Asc_Hex( CRam1,4);
            p2=&File_Size;
            *(p2+3)=*(p1+3);
            *(p2+2)=*(p1+2);
            *(p2+1)=*(p1+1);
            *(p2+0)=*(p1);
    //        sprintf(CRam1," Taille Data = %6u bytes \r\n",File_Size);
    //        Print(CRam1);
            MaxBlocs=File_Size>>7;  //  15-09-2022
     //       sprintf(CRam1," Max Blocs de 128 bytes =%5d \r\n",MaxBlocs);
     //       Print(CRam1);


            
TEST avec debugger MikroC 
Name        Value    Address
p1            0x00 72    0x00CE
            [value]    38    0x0072
p2            0x00 3B    0x00D0
            [value]    '&'    0x003B
File_Size    111910    0x003B
MaxBlocs    874        0x00D4
CRam1        {...}    0x0512
    [0]    0x26    0x0512
    [1]    0xB5    0x0513
    [2]    0x01    0x0514
    [3]    0x00    0x0515
    [4]    0x00    0x0516
File_Size    111910                           <-- OK  ( fichier wav de 10 sec)


la version MPLABX

Code : Tout sélectionner



teste avec MPLABX XC8
uint32_t File_Size;
                                                                                                                                    
 DB  26, b5, 01, 00,                               <-- 4 bytes => longueur de fichier   affichée en hexa                                                                                                                                                                                                              
 Taille Data = 46374 bytes                      <-------- resultat sur format Word   0xB526 => 46374                                                                                         
 Max Blocs de 128 bytes =  874  
 
  p1=&Buffer1[0]+40;
  *(p1)=0x26; *(p1+1)=0xB5;*(p1+2)=0x01;*(p1+3)=0;
   memcpy(CRam1,p1,4);
  Imprime_Asc_Hex( CRam1,4);
   p2=&File_Size;
  *(p2+3)=*(p1+3);
  *(p2+2)=*(p1+2);
  *(p2+1)=*(p1+1);
   *(p2+0)=*(p1);
   sprintf(CRam1," Taille Data = %u bytes \r\n",File_Size);
   Print(CRam1);
   MaxBlocs=File_Size>>7;  //  15-09-2022
   sprintf(CRam1," Max Blocs de 128 bytes =%5d \r\n",MaxBlocs);
   Print(CRam1);


Une idée du pourquoi cette différence de comportement ?
Cependant la lecture fichier déconne au dela de 63360 ??

[satinas]

Hello,
On en a déjà parlé, à propos de MikroC il me semble.
Le sprintf "%u" affiche un unsigned int, "%lu" un unsigned long.
106112 c'est 0x19E80, stocké dans la ram ainsi -> 0x80 0x9E 0x01 0x00 (little endian)
Avec "%u", il prend un int, c'est à dire les 2 premiers octets 0x9E80 (little endian) , soit "40576"
Avec "%lu", il prend le long de 4 octet 0x19E80, soit "106112"
Voir doc de sprintf()

Sans oublier le warning xc8

Code : Tout sélectionner

main1.c:184:24: warning: format specifies type 'unsigned int' but the argument has type 'uint32_t' (aka 'unsigned long') [-Wformat]
    sprintf(toto,"%u", File_Size);
                  ~~   ^~~~~~~~~
                  %lu


Fais comme moi, ralentis la cadence, ça fume

[satinas]

Après n relectures ce matin, j'ai toujours pas compris la question, la réponse d'hier est sans doute pas adéquate :)
106112 n'est pas égal = 874*128, d'où sort-il ?

[paulfjujo]

bonjour à tous,

On en a déjà parlé, à propos de MikroC il me semble.

ça m' avait effectivement un air de déja vu ..mais où ?

..ma memoire devient passoire ..
.... Les neuronnes s'ecoulent comme les grains de sable du sablier
........mais on ne peut plus retourner le sablier

Après n relectures ce matin, j'ai toujours pas compris la question, la réponse d'hier est sans doute pas adéquate :)
106112 n'est pas égal = 874*128, d'où sort-il ?

ta réponse etait pile poil adequate ...

sorry, en fait dans mes tests j'avais pris aussi un fichier wav ecourté 9,5sec (106112) .qui avait cette taille
au lieu de 10 sec (111910) .

mais dans le code, tu peux voir que la taille du wav

Code : Tout sélectionner

 DB  26, b5, 01, 00,                               <-- 4 bytes => longueur de fichier   affichée en hexa                                                                                                                                                                                                              
 Taille Data = 46374 bytes        <-------- resultat sur format Word   0xB526 => 46374     => 111 910 sur 32 bits                                                                                  
 Max Blocs de 128 bytes =  874

-> donne 111910 qui est bien 874x28

[paulfjujo]

bonjour,


Je continue de ce coté, vu que je suis devenu indésirable coté ASM
même si mon sujet parlait déja de lecture fichier wav !

je viens de tester coté MikroC 7.60
Il est possible de contenir le fichier Wav de 106K dans 2 tables de 64Ko maxi !

Code : Tout sélectionner


MikroC
PIC18F27K42_Play_Wav_en_flash_2022_0921.c
#define Version "2022_0921"
#define Directory "C:\\_MikroC\\_MesProjets_MikroC\\_18F27K42_Play_WAV_en_flash_2022 "
#define Project "Read_WAV_en_Flash_by_PWM_18F27K42_2022_09.mcppi"
#define Source  "PIC18F27K42_Play_Wav_en_flash_2022" 
 // test fichier wav de 106Ko stocké en Flash !
 // avec fichier reparti en 4 tables ..OK
 // avec fichier reparti en 2 tables <= 64Ko  => OK
 // 1 seule table =BAD 
 error 
33 437 Object must be smaller than 64kb in size: 'SonWav' PIC18F27K42_Play_Wav_en_flash_2022_0921.c
 
Meme test qu'avec MPLAB XC8 avec "Tout nu tout bronzé... "SonWav 106238 bytes reparti en 4 tables :
[b]Statistics :[/b]
0x00402 SonWave1      32704
0x083C2 SonWav      32608
0x10322 SonWav2     32448
0x181E2 SonWave3      8478
last adresse
0x1A300

=>Test avec fichier WAV reparti en 2 tables < 64Ko ..OK
[b]Statistics et fichier *.lst[/b]
0x002BA     698        SonWav
0x10048     65608   LST => fin en 0x8585 ;_SonWav+64910
0x1004A     65610    SonWav1
0x1A1B8     106936    LSt => fin en 0x0000 ;_SonWave1+41326

0 1144 Used ROM (bytes): 106938 (82%)  Free ROM (bytes): 24134 (18%) 
0 1144 Used RAM (bytes): 16 (1%)  Free RAM (bytes): 8154 (99%) 


je refais donc le meme test avec MPLABX XC8

Code : Tout sélectionner


2 tables <64Ko pour le fichier wav au lieu de 4 tables <32768
Errors
main.c:151:: error: (240) too many initializers
main.c:4210:: error: (240) too many initializers


conclusion (hative ?) :
XC8 limite la table en flash à 32768 au lieu de 65536 pour MiKroC
(cette fois) pour MikroC !

Code : Tout sélectionner



void main(void)
{
   OSCCON1 = 0x60; // NOSC HFINTOSC; NDIV 1;
   OSCCON3 = 0x00;// CSWHOLD may proceed; SOSCPWR Low power;
   OSCEN = 0x00;  // MFOEN dis; LFOEN dis; ADOEN dis; SOSCEN dis; EXTOEN dis; HFOEN dis;
   OSCFRQ = 0x08;  // HFFRQ 64_MHz;
   OSCTUNE = 0x00;// TUN 0;
   Delay_ms(500);
   //REGISTER 8-1: CLKRCON: REFERENCE CLOCK CONTROL REGISTER  p113
   CLKRCON=0b10010000;
   //REGISTER 8-2: CLKRCLK: CLOCK REFERENCE CLOCK SELECTION MUX
   CLKRCLK=3; // 500Khz

   Init_Hardware();
   CM1CON0=0;
   CM1CON1=0;
   for (i=0;i<8;i++)
   {
    Led_Rouge=0;
    Delay_ms(500);
       Led_Rouge=1;
    Delay_ms(500);
    }

   File_Size=sizeof(SonWav);
   L2=sizeof(SonWave1);
   INTCON0.GIEL =0;
   INTCON0.GIEH=0;
   Init_Timer2();
   Init_CCP1_PWM();
   j=0;

        CCPR1H=0;
        CCP1CON.B7=1;
        T2CON.T2ON=1;
       for (L1=0; L1<File_Size  ;L1++)
        {
            T2PR=180;
            T2CON.T2ON=1;
            CCPR1H=0;
            CCPR1L  =SonWav[L1];
            Delay_us(85);
            T2CON.T2ON=0;
          }
         for (L1=0; L1<L2 ;L1++)
        {
            T2PR=180;
            T2CON.T2ON=1;
            CCPR1H=0;
            CCPR1L  =SonWave1[L1];
            Delay_us(85);
            T2CON.T2ON=0;
           }
      CCP1CON.B7=0;
     Delay_ms(2000);
      _asm reset

}


[satinas]

Hello,

La doc de xc8 dit :
For baseline PIC devices, the maximum size of a single const object is 255 bytes.
For all other 8-bit devices, the maximum size of a const-qualified object is limited only by the available program memory.

Dans le programme où tu avais divisé en 4 blocs de 32k, cette compilation passe :

Code : Tout sélectionner

const uint8_t SonWav[53120]=
{
  53120 octets
};
const uint8_t SonWave1[53120]=
{
  53120 octets
};

Par contre :

Code : Tout sélectionner

const uint8_t SonWav[106240]=
{
  106240 octets
};

retourne l'erreur
main.c:150:22: error: array is too large (106240 elements)
const uint8_t SonWav[106240]=
Il n'arrive peut être pas à dégager un bloc de 100k dans la flash, pourtant le pic n'est pas plein.
Si je le mets dans un programme plus petit, même erreur, après essais il est limité à 65535.

[paulfjujo]

Bonjour Satinas,

Oui, j'ai bien compris qu'un bloc de 106Ko ne peut pas passer !

pourtant avec mikroC , je passe 2 blocs de presque 64Ko
le 1er de 64910 byte
le 2em de 41326 bytes

alors qu'avec XC8 , mes 2 blocs de datas ( les memes utilisés avec MikroC)
ne passent pas , ils sont pourtants inferieurs à 64ko
Errors
main.c:151:: error: (240) too many initializers
main.c:4210:: error: (240) too many initializers

en divisant par 4 blocs
1er bloc 32752 ( lignes 144 à 2191 ) *16 datas
2em 32704 ( lignes 2196 à 4240) *16 datas
3em 32448 ( lignes 4244 à 6272) *16 datas
4em 840 ( lignes 6276 à 6806) *16 datas
ça passe bien !

nota:
la partie code est quasiment la meme !
à la syntaxe pres .

de meme que je constate que je ne peux meme pas approcher la limite de 65535 !( voir 65535-128 ( puisque j'ecris par bloc)
avec l'adresse flash = depart + taille de fichier
avec depart autour de 4000H -> 16384 ... du fait que XC8 est envahissant ..
j'ai essayer de reduire avec l'option ROM du linker .. inefficace
je pense qu'il doit y avoir un tas d'option pre reglees avec ..avec Make file ?
Autant retourner à 100% ASM si c'est trop complexe.


il y a un bug .. mais où ?


à remarquer
sous mikroC
Depart 1er bloc en flash 0x0402 ! seulement
derniere adress flash de l'ensemble last adresse 0x1A300

je vais laisser tomber un moment .. ça me gave !

[satinas]

La limite de 65535 doit être liée à une histoire de pointeur 16 bits. 65535 passe, pas 65536.

Tu n'as pas vu la subtilité, je mets le nombre d'octets entre les crochets :)
C'est la doc sur l'erreur 240 qui m'a donné l'idée de le rajouter.
(240) too many initializers (Parser)
There are too many initializers for this object. Check the number of initializers against
the object definition (array or structure), for example:
/* three elements, but four initializers */
int ivals[3] = { 2, 4, 6, 8};

[paulfjujo]

bonjour Satinas,


J'ai quand même voulu tester ta remarque ...

Effectivement ça passe en 2 tables (<=64Ko) ,dont le nombre de datas est initialisé au depart

Code : Tout sélectionner


const uint8_t SonWav[64000]=    // 4000 lignes de 16 datas
{ 0x02,0x9E,0xF0,0x49,0x40,0x33,0x33,0x3C,0x46,0x59,0x60,0x52,0x4C,0x57,0x5F,0x5A
..etc 
.....
 0x84,0x8C,0x85,0x71,0x69,0x7F,0x91,0x86,0x75,0x6D,0x70,0x7C,0x84,0x81,0x81,0x85
 };
const uint8_t  SonWave1[42304]=     // 2644 lignes de datas
{
 0x81,0x7D,0x7C,0x81,0x8D,0x8C,0x79,0x67,0x6C,0x77,0x79,0x77,0x7B,0x7D,0x7A,0x78,
 0x7E,0x8A,0x95,0x95,0x90,0x89,0x81,0x7C,0x7E,0x83,0x82,0x7E,0x82,0x8F,0x8C,0x7C,
 ...etc ..
  0x80,0x80,0x80,0x80,0x80,0x80,0x81,0x81,0x80,0x80,0x80,0x80,0x80,0x81,0x00,0x00
   };


extrait du fichier *.map resultant de la compilation

Code : Tout sélectionner


shared
        _SonWave1              CONST              15ABC    0000    42304
        __initialization        CODE               5D1E      0000    12
        _SonWav                CONST              60BC      0000    64000

shared estimated size: [b]106316[/b]

main.c
        _Init_Timer2           CODE               5D4E    0000    44
        _Init_CCP1_PWM     CODE               5D30    0000    30
        _main                  CODE               5F0E    0000    430
        _Init_Hardware     CODE               5E54    0000    186
        _delay_ms              CODE               5DE6    0000    110

main.c estimated size: 800


USAGE MAP

Code : Tout sélectionner


Legend:
  - = Unused memory
  F = Filled ROM
  S = Stored serial code
  A = Stored ASCII string
  R = Reserved for checksum
  C = Stored checksum result
  T = Trailing code
  & = Find & replace opcode
  X = Find & delete opcode
    1 = dist/default/production\Test_Lec_Wav_en_Flash_18F27K42.X.production.hex
00000000: 1111FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
00000040: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
 ... etc ...
 00005D00: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1111111111111111111111111111111111    <-- code programme
 00005D40: 1111111111111111111111111111111111111111111111111111111111111111
 ....
 00006080: 1111111111111111111111111111111111111111111111111111111111111111  <- le Wav debuterai  en 60BC 
000060C0: 1111111111111111111111111111111111111111111111111111111111111111  
 ... etc  jusqu'à la fin
 0001FF40: 1111111111111111111111111111111111111111111111111111111111111111
0001FF80: 1111111111111111111111111111111111111111111111111111111111111111
0001FFC0: 1111111111111111111111111111111111111111111111111111111111111111
00300000: 1111111111------------------------------------------------------
 


la difference entre MikroC et XC8
est que MikroC s'initialise tout seul avec le nombre de datas contenues...
alors qu'il faut le specifier obligatoirement avec XC8 !

XC8 demande plus de rigueur


.. mais est un peu bete aussi ,ça lui coute quoi, de compter le nb de datas entre les parentheses.
surtout avec le nombre de Mo qu'il occupe !

[satinas]

Bonjour, à mon avis c'est un bug, c'est pas simple de faire un compilateur :)