[Temps-x]

Re

Source du message e n'est pas un wav ...

J'ai regroupé le fichier hexadécimal et le Wav Ici ou le lien restera active 30 jours à partir de cette date.

A+

[satinas]

Bonjour à tous

nota : une lecture de byte FLASH dans une boucle en C ..prend 3µS

Paul, c'est plus rapide dans mes essais.
L'essai consiste à lire 25 fois la flash de 128ko, avec FOSC=64Mhz et Tcy=62,5ns.

En ASM on retrouve bien les 2 cycles, la led clignote chaque seconde.
Cela fait 125ns pour lire 1 octet en flash, 300ns avec les instructions de la boucle.
TABLAT peut être utilisé comme variable.

Code : Tout sélectionner

rdf10   movlw   25                      ; 25 lectures de toute la flash
        movwf   wloopl                  ; soit 25 * 131072 * 5 * 62,5ns
        clrf    TBLPTRL                 ; soit environ 1 seconde
        clrf    TBLPTRH
rdf20   clrf    TBLPTRU
rdf30   tblrd*+                         ; 2 cycles de 62,5ns
        btfss   TBLPTRU,1               ; 1 cycle
        bra     rdf30                   ; 2 cycles
        decfsz  wloopl
        bra     rdf20
        btg     LATC,2                  ; toggle led
        bra     rdf10


En xc8, c'est environ 3 fois plus lent, la led clignote toutes les 3 secondes.
Cela fait 900ns pour lire 1 octet en flash, instructions de boucle comprises.

Code : Tout sélectionner

  unsigned char val;                    // doit être globale
  while (1) {
    unsigned char i;                    // 25 lectures de toute la flash
    for (i=0; i<25; i++) {
      unsigned long j=0x20000;
      TBLPTRU = TBLPTRH = TBLPTRL = 0;
      while (j--) {
        asm("tblrd*+");
        asm("movf TABLAT,W");
        asm("movwf _val");
      }
    }
    LATCbits.LATC2 = !LATCbits.LATC2;   // toggle led
  }


[paulfjujo]

bonsoir Satinas,

merçi pour ta demo,
tres rapide ,mais on exploite pas la lecture ...

... il y a un peu d'ASM dans ta version XC8 ....

je n'ai jamais douté que l'ASM est le moyen le plus rapide ...
mais vu qu'il faut un delay de 90µS pour l'envoi au PWM ... à 11025Hz
voir 45µS à 22050Hz
on a le temps de se tourner les pouces ..

XC8 sans ASM :

Code : Tout sélectionner


 CPrint("\r\n --------------------------------------------------\r\n");
                CPrint(" Joue en boucle , le fichier wave 11025 Hz en 8 bits (en flash)\r\n");
                CPrint("-----------------------------------------------------\r\n") ;
                L2=FLASH_ROW_ADDRESS+ File_Size-64;
                sprintf(txt," Maxi position en Flash = %u  soit 0x%X \r\n",L2,L2);
                p2=&L2;
                sprintf(txt," Maxi position en Flash = %u  soit 0x%02x%02x%02x%02x \r\n",L2,*(p2),*(p2+1),*(p2+2),*(p2+3));
                Print(txt);
                CCPR1H=0;
                if (L2 < 131072)   //0x20000)
                {       
                  for (L1=FLASH_ROW_ADDRESS; L1< L2  ;L1++)
                  {
                      SQA=1;
                      T2PR=180;
                      T2CONbits.T2ON=1; // pour synchro
                      CCPR1H=0;
                      CCPR1L  =FLASH_ReadByte(L1); // cx ; 
                      __delay_us(85);
                      T2CONbits.T2ON=0;
                      SQA=0;
                  }
                }
                else
                CPrint("Too Big Wav file datas..\r\n");


je me pose la question sur la synchro debut de PWM via Timer ou via CCP1 enable ?
à suivre ...


j'ai revu les tailles de variable Word -> long pour passer le cap de 65535 ...

j'essai en ce moment un morceau de 10sec de Tout_nu_tout_bronze_10s.wav 116Ko ... à reduire un poil!
Memory Summary:
Program space used 35AEh ( 13742) of 20000h bytes ( 10.5%) <-- limite arrondie à 4000h pour debut zone flash de stockage
Data space used 1E1Bh ( 7707) of 2000h bytes ( 94.1%)
car je ne dispose que de 20000H-4000h => 114688 bytes en flash
à suivre .

[satinas]

Ta fonction FLASH_ReadByte(L1) elle fait aussi de l'asm ? :)
Pour faire le TBLRD*+, Il n'y pas d'équivalent en C, mais comme je pratique pratiquement plus, je suis plus sûr de rien.
Par contre En déclarant une variable C à la même adresse que TABLAT, on peut travailler directement avec cette variable après la lecture de la flash. Mais c'est vrai que c'est déjà assez rapide comme cela, toujours la manie d'optimiser si sympa en assembleur, en C c'est moins rigolo :)

[paulfjujo]

Ta fonction FLASH_ReadByte(L1) elle fait aussi de l'asm ? :)

Bien vu!
on peut en conclure que XC8 habille bien l'ASM ... sans trop se fouler.
Pourquoi ré-inventer la poudre , si elle détonne bien ...

[paulfjujo]

Bonjour,

Il s'avere qu'on est loin de disposer de tout l'espace FLASH à notre disposition ...
vu que mes essais bloquent au dessus d'une taille de fichier de 42624 bytes !
mon code occupant
Program space used 35E2h ( 13794) of 20000h bytes ( 10.5%)
Data space used 1B32h ( 6962) of 2000h bytes ( 85.0%)

j'ai mis un FLASH_ROW_ADDRESS à 4000h (16384) adresse de départ stockage datas wav en flash
or l'application se plante des que je depasse 45696 datas ! (16384 offset) + 45696 => adresse max 62080
et j'ai jeté un oeil au fichier résultant de la compilation où l'on peut voir :

qu'il y a du code en

011E18 _UART1_rx_vect_isr: 73240 !
10706 012ADC _INT0_ISR: 76508

un autre truc qui traine
2741 ; Clear objects allocated to BIGRAM (6144 bytes)
2742 01237C EE00 F380 lfsr 0,__pbssBIGRAM
2743 012380 EE16 F000 lfsr 1,6144
2744 012384 clear_0:
2745 012384 6AEE clrf postinc0,c
2746 012386 50E5 movf postdec1,w,c
2747 012388 50E1 movf fsr1l,w,c
2748 01238A E1FC bnz clear_0
2749 01238C 50E2 movf fsr1h,w,c
2750 01238E E1FA bnz clear_0

F380 => 62080 <---- la limite exacte est autour de cette valeur .

Bref avec MPLAB XC8 .. il y a tellement de code dormant qu'il me semble impossible de gérer l'espace Flash
sans ecrabouiller une zone déja utilisée.
...à moins d'utiliser Memory Management ?
je l'ai déja utilisé , mais seulement avec la RAM ! et sous Mikro C ..
Il semblerait bien que le seul ESPACE DATAS FLASH SAFE ne soit que de 128bytes ! avec le bit SAF

Bref ça se complique un peut trop pour jouer un Wav de 9sec...
j'attends de voir si TempsX s'en debrouille en ASM
et voir quelle taille (ou duréee) maxi il peut jouer.
donc j'en reste à ce wav là Tou_nu_tou_bronze_11025hz_8bPCM_mono_4.42sec.wav de 45Ko
(limite max adresse flash en dur dans le programme!)
qui donne de bon resultats ..ou autre fichier wav de taille moindre ...


dans le zip ci dessous :
mon projet MPLABX XC8 et le *. hex compilé .. s'utilise avec Realterm pour charger le Wav..
18F27K42_Test_Ecr_Lec_Flash_2022-09.X.production.hex
Tou_nu_tou_bronze_11025hz_8bPCM_mono_4.42sec.wav
Tou_nu_tou_bronze_9.6sec.wav
capture_2022-0917c.txt <- deroulement programme , lecture du wav et restitution
"tout nu tout bronzés on est bien ".........

18F27K42_Test_Ecr_Lec_Flash_et_Wav_2022-0917.zip

sortie PWM sur RC1 !

en dernier ressort ... un test avec une Eeprom 24FC1026 de 128K x 8b
Là au moins on peut maitriser l'espace .. à voir de pres la vitesse maxi possible ( et fiable)...













.

[satinas]

D'après mes essais avec le bootloader, xc8 met à l'adresse reset 0 juste un jump vers le programme implanté en fin de flash.
Pour réserver une zone de la flash aux données, tu peux utiliser l'option "Project Properties/XC8 linker/Memory model/ROM ranges". Par exemple, en mettant 0-0ffff le programme se placera dans la première moitié de la flash, et la 2ème moitié reste disponible pour les données.

Comment fais-tu pour mettre le WAV dans la flash, directement à la compilation, ou c'est ton programme qui écrit la flash après réception du WAV par port série ?

[Temps-x]

Bonjour paulfjujo, satinas, et tout le forum,

Source du message j'attends de voir si TempsX s'en debrouille en ASM

J'ai prie un Pic18F27K42 pour les essais

ça plante, je vais essayer de comprendre le pourquoi de la chose
Apparemment si j'attends un peu, ça redémarre au bout de 3 à 4 minutes, je pense que ça viens d'un mauvais calcul avec la fonction decfsz

A+

[paulfjujo]

bonjour à tous,

Comment fais-tu pour mettre le WAV dans la flash, directement à la compilation, ou c'est ton programme qui écrit la flash après réception du WAV par port série ?

Exactement .. Realterm terminal me sert à envoyer le fichier * wav au PIC via la liaison UART
115200bds 8,n,1 ,CTS la pin RC5 me sert de signal RTS -> vers terminal ,pour gerer le flux. ( testé aussi à 464800bds ! )
reception par paquet de 128 bytes correspondant à l'ecriture en flash de chaque bloc.
Comme precisé precédement, j'ai été obligé de limiter la taille maxi d'ecriture en flash autour de 45000 bytes.
ça permet d'y stocker 4,8sec .
replique de Bernard Blier : bourrepif_11025_Mono_8b_4.86sec.wav de 50ko
ou tout nu tout bronzés on est bien ..... 45920 bytes seulement sur 106Ko

* wav , qui doit etre au format 11025,mono,8bits PCM
avec Audacity ou Switch by NCH (gratuit pour usage perso) , on peut adapter n'importe quel *.wav.
La config de Realterm est assez minutieuse ... je joints mon fichier d'ini "realterm.ini" dans le zip (pas le slip!)

j'avais mis ,en debut de programme un test sur Timer2 CCP1 pour mesurer le timming exact .. supprimé

mais j'ai rajouté :
* en debut de programme , la lecture en Epprom d'un Flag pour voir si on a deja lu un *.wav,et stocké en Flash
exemple:
Read Eeprom 0 à 3
Wav flag= 99 File_size=44928 MaxBlocs= 95

* en fin de programme , le stockage en Eeeprom PIC, d'un Flag , positionné à 99
precisant qu'on vient de mettre en flash un fichier wav , sa taille en bytes et le nombre de blocs
Le programme fait ensuite un Reset Software .. donc redemarre ..
si le flag est à 99, va direct en lecture du Wav (stocké en flash).
Le PIC joue alors le Wav ,des sa mise sous tension ou sur reset ...
je n'ai pas prevu qu'on puisse à nouveau y remettre un autre Wav dedans ,mais c'est facile de le faire .
(source et Hex dans le zip)

j'ai donc recupéré le contenu du PIC déja chargé avec le wav ( exportation avec pickit 3 )
ce qui donne le fichier 18F27K42_Lec_Flash_Bourrepif_2022-0917.hex (dans le zip)
il suffit donc de charger ce hex ,pour qu'il cause tout seul....en boucle !

switch_soft_for_wav.jpg

contenu_zip.jpg

18F27K42_Lec_Flash_Bourrepif_2022-0918.zip

----------------------------------------------------------------

Pour réserver une zone de la flash aux données, tu peux utiliser
l'option "Project Properties/XC8 linker/Memory model/ROM ranges". Par exemple, en mettant 0-0ffff le programme
se placera dans la première moitié de la flash, et la 2ème moitié reste disponible pour les données.

j'ai testé :
set project configuration
customize
project properties
XC8 linker
options : memory model
rom ranges :
additional options : 0-3FFF

Specify ROM ranges The compiler initially knows about on-chip ROM only.
If external ROM is available then this can be specified via this option.
Areas of on-chip ROM that must be reserved can also be listed.
Examples: 0-7FF,1000-1FFF ignore on-chip ROM, use only specified ranges;
default,3000-3FFF use default on-chip ROM, plus an additional range;
default,-7F0-7FF use default ROM, but reserve 16 bytes at 7F0.


j'ai mis comme option 0-3FFF

apres compilation :
Memory Summary:
Program space used 355Eh ( 13662) of 4000h bytes ( 83.4%) <-- limit 4000H ..OK
Data space used 1B32h ( 6962) of 2000h bytes ( 85.0%)
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%)

mais dans Pickit3 Programm memory :
02D50 815E 0E00 6E7F 8E7E 0012 6E06 0139 A9A3
02D60 EFB4 F016 EFB6 F016 EFAE F016 0060 F01B
02D70 FDEA 0012 FFFF FFFF FFFF FFFF FFFF FFFF
02D80 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF

avec 355Eh used ,comment se fait-il que j'ai Flash vierge apres 02D72h ?

neamoins, le programme tourne OK !!!
je vais tester avec 106Ko ...
-------------------------------------------------------------------------------------------

[satinas]

Bonjour à tous

Paul, on a fait la même chose en même temps :)
J'ai compilé ton programme, avec 0-3600 et ça passe. Normalement il reste 1CA00 soit 117248 octets disponible dans la flash. En regardant le fichier HEX avec un éditeur de texte, on voit qu'il n'y a rien au dessus de l'adresse 0x3600.
C'est le PicKit3 qui doit ajouter du code pour le debug peut être ?

Temps-x j'ai vu que tu décrémentes un compteur 24 bits. C'est pas évident avec l'instruction decfsz. Le decf des 18F est mieux que celui des 16F, car il retourne C à 0 uniquement si on passe de 0x00 à 0xFF, ce qui permet de décrémenter le compteur de plus haut niveau.

Code : Tout sélectionner

   decf L
   btfss STATUS,C
   decf H
   btfss STATUS,C
   decf U


Par contre pour tester la fin de boucle, il faut ajouter du code, par exemple attendre que les 3 octets du compteur soient nuls avec tstfsz.