|
| la carte de developpement BASE 18F27K42 (Vue Photo Sprint Layout6) |
 |
| Vue MCC MplabX XC8 |
Version 0.0 : 09/09/2021
rev. 29/12/2022
Fichier *.Wav et PIC18F27K42
(avec MikroC version 7.60 )
Datasheet MCU (PIC18FxxK42
DS 40001919B rev 2017)
Platine
d'essai : circuit imprimé et schema
Generalité sur la présentaion de mes
applications ...
Lecture
Wav via protocole Software XON XOFF ->
BAD
Lecture
Wav (7,5 Ko en RAM) via UART Hardware CTS, restitution Audio via
PWM rev 03/09/2022)
Test
Ecriture/Lecture en FLASH (Mplabx
XC8)
Lecture
datas fichier *.wav en Flash, restitution Audio (via PWM) .MPLAB
XC8.. OK
Lecture
fichier son *.wav (104ko) via UART, datas en Flash et restitution Audio ...XC8 ...:-(| presque
OK
Lecture fichier son *.wav (110ko) via UART, Stockage en Flash et restitution Audio.MikroC ..OK..
Lecture
fichier son *.wav (110ko) via UART, stockage en Flash, fichier texte ,et restitution Audio.MPLAB XC7 ..OK..
.Rejouer un fichier WAV capturé: .mode Autonome
direct sur HP, ou via applis PC Win10 NCH
Wavepad, ou via VLC (entréé Micro)
Projet
Anti-Chats 26/12/2024 MikroC
!
Mesures
sur signal DTMF PWM restitué (parmi 16 notes *.wav en flash)(10/10/2022)
Configuration
et Usage du terminal Realterm pour envoi d'un fichier (Protocole
RTS) *.wav ou autre
autres liens :
Generateur DTMF (version MikroC 7.60
et PWM1... adaptation V.O; Roman Black)
Generateur DTMF (version MPLAB XC8
et PWM5... adaptation V.O; Roman Black)
Hardware :
avec la carte BASE commune aux 18FxxKxx ou vieux 18Fxxx, 18Fxxxx
en DPIP28
Schema ISIS : Schema
de principe .
.
|
| la carte de developpement BASE 18F27K42 (Vue Photo Sprint Layout6) |
|
| Vue MCC MplabX XC8 |
Un mimimum de configuration
avec :
* Fosc interne =64MHz
* Liaison UART1 Hardware avec RC6=TX et RC7=RX
* Une voie analogique ADC 12 bits sur RA1
* une sortie Led sur RA4
* Timer0 + interrupt
Liaison UART 1
Hardware
Connection Interface Prolific TTL/USB , sur connecteur Uart de la
carte : RC7 et RC6 du MCU
Terminal YAT 19200,8,N,1 coté PC.
Utilisation quasi "standard" des Pins RC6=Tx et RC7=RX
Uart1
au niveau Hardware (PPS) , UART1 TX est
par défaut sur RC6.
ainsi que de la librairie UART1 MikroC
FOSC interne MCU à 64Mhz
config UART1 : 19200 (,8,N,1 par défaut).
Affectation des pins via PPS
:
Unlock_IOLOCK();
// UART1 (optionnel ! )
//RC6PPS = 0x13; //RC6->UART1:TX1;
U1RXPPS = 0x17; //RC7->UART1:RX1;
// NCO
RA5PPS = 0x26; //RA5->NCO1:NCO1;
Lock_IOLOCK();
*nota: la librairie PPS doit etre active,
elle occupe 1500 bytes !
Generalité sur mes applications :
au lancement du programme :
Courte présentation de l'application
sur le terminal (via UART)
Ce Modele est
présent sur TOUTES MES APPLICATIONS ( Programmes)
pour connaitre le contenu du PIC en présence et avec quoi il est
programmé !.
Nota : L'UART1 est quasiment toujours utilisé pour suivre
le deroulement du programme
vu le tres peu de ressources MCU necessaires.
La premiere action est de definir FOSC du
PIC .. ici FOSC Interne 64MHz.
puis l'Init Hardware
Entrées Analogiques, Entrées , Sorties ...etc..
et l'aiguillage des fonctions et PINS, via PPS .
puis l'init de L'UART1 hardware. (19200,8,N,1)
et le texte de présentation
proprement dit, (placé pour la partie invariable, en Flash).
exemple
#define Version "2021_0107"
#define With_I2C1_Softw
#define Directory "C:\\_MikroC\\_MesProjets_MikroC\\_BASE_18F27K42"
#define Project "BASE_18F27K42_Minimal.mcppi"
#define Source "BASE_PIC18F27K42"
#define Others "OLED_128x32_Tables_2021.h\r\n BMP_images_128x32_2021.inc\r\n"
#define Eeprom "not used ...."
#define Config "P18F27K42_Fosc_Interne_64Mhz_with_RA6_Clockout.cfgsch"
#define PROCESSOR "18F27K42"
#define POWER_SUPPLY " 3.6V"
#define OSCILLATEUR_INTERNE
#define FOSC "64.0" // MHz
#define BAUD "19200" // UART1
const code char mesg0[]="
Directory :"Directory"\r\n";
const code char mesg1[]=" MikroC pro 7.60\r\n";
const code char mesg2[] =" Projet :"Project"\r\n";
const code char mesg3[]=" Test PIC18F27K42 I2C1 Softw\r\n";
const char char mesg4[]=" Config bit : "Config"\r\n
FOSC:"FOSC" MHz\r\n";
const char char mesg5[]=" Eeprom: "Eeprom"\r\n";
const char char mesg6[]=" Source : "Source"_"Version".c\r\n";
#ifdef With_I2C1_Softw
const char char mesg7[]=" 18F27K42 UART1 19200, OLED LCD ,
RTC , ADC1 EA1 LM35DZ\r\n";
const char char mesg8[]=" Mini_OLED_128x32_I2C1_Softw_18Fx7K42_2021.c
et *.h\r\n";
const char char mesg9[] =" Tiny_RTC_DS3231_I2C_Softw_for_AI2_2021_01.c\r\n";
const char char mesg10[]=" Autres "Others"\r\n";
#else
const char char mesg7[]=" 18F27K42 UART1 19200bds, ADC1 12
bits sur EA1 \r\n";
const char char mesg8[]=" I2C1 Software NON activé ! donc
pas de RTC ,ni OLED !\r\n";
const char char mesg9[] =" ";
const char char mesg10[]=" ";
#endif
const code char * Messages[]={mesg0,mesg1,mesg2,mesg3,mesg4,mesg5,mesg6,mesg7,mesg8,mesg9,mesg10};
const char Blancs[]=" ";
L'usage de compilation conditionnelle , via #define
OPTION
permet d'activer ou pas l' OPTION lors de la compilation.
Le meme fichier source servant alors de TRAME , peut etre
réutilié par ailleurs.
PWM 10bits
Duty cyle cde 0 à 1023
Ressources :
Oscillateur 64Mhz
Potar ver entree RA0 analogique
Pin RC5 PWM output -> MOSFET IRLZ14 -> Ampoule 12V 5W -- alim externe 12V
pins RC6 (TX) et RC7 (RX) -> cordon Prolific TTL/USB <->
Terminal YAT
pin RA3-> SQA trigger
pin Gnd
TMR4 associé à PMW5
SOFTWARE :
rev 07/01/2021
Compiler MikroC 7.60:
Projet : _BASE_18F27K42_minimale_2021.zip
Main code : BASE_PIC18F27K42_2021_0107.c
Lib RTC: Tiny_RTC_DS3231_I2C_Softw_for_AI2_2021_01.mcl
Header : Tiny_RTC_DS3231_I2C_Softw_for_AI2_2021_01.h
Lib Mini-Oled 20x10mm : Mini_OLED_128x32_I2C1_Softw_18F27K42_2021.mcl
Header : Mini_OLED_128x32_I2C1_Softw_18Fx7K42_2021.h
Images BMP : BMP_images_128x32_2021.inc
Fontes caracteres : OLED_128x32_Tables_2021.h
Config projet : P18F27K42_Fosc_Interne_64Mhz_with_RA6_Clockout.cfgsch
Test lecture
fichier Wav avec protocole Software XON XOFF
Usage du terminal PC VBRAY terminal en mode XON XOFF
UART1 à 19200 bauds
void dump Hexa de "Welcom.wav"
avec le programme wxHexEditor 0.24
Beta for windows
mono=01, mode=1=PCM , Echantillonage à 22050hz , taille datas =
30130
Au niveau de l'interrupt RX UART, lecture par bloc de 64 bytes ,
envoi de XOFF pour bloquer l'envoi dès le 64em char
il aura donc forcement l'entete WAV de 44 bytes contenue dans
cette portion de datas
un pointeur sur cette zone permet de recuperer les infos /
structure du fichier WAV
datasheet PIC 31.17.3.1 Special Considerations
Break Character
A Break is detected when the RX input remains in the
space state for 11 bit periods for asynchronous and LIN modes,
and 23 bit periods for DMX mode.
To avoid character errors or character fragments during a wake-up
event, the wake-up character must be all zeros.
MAIS :
l'envoi de la valeur 0 necessite quand meme , au niveau hardware,
l'envoi d'un start et un stop !
le niveau logique ne reste donc pas à ZERO plus de 10 moments
------ autre explication , concernant le mode XON XOFF en
LECTURE---------------
explication du grand nombre de valeur 81 et 83 dans le fichier
wav
(sic)
En cas de paramétrage du contrôle du
flux de données XON/XOFF, les données utiles ne
doivent contenir aucun des caractères XON ou XOFF paramétrés.
Les valeurs par défaut sont
DC1 = 11H pour XON et DC3 = 13H pour XOFF.
Comment transmettre les valeurs 17 et
19 ?
La solution de ce problème consiste à échapper les octets
ayant la valeur (XON) 17 et (XOFF)19,
en les faisant précéder d'un autre caractère, par exemple DLE
(Data Link Escape)
de valeur 16. C'est à dire que pour transmettre un octet à 17
ou 19, on commence d'abord
par transmettre un octet à 16. Cependant,
cette solution a un inconvénient de taille :
les caractères de contrôles de flux sont émis dans une
situation d'urgence (surtout XOFF),
et être obligé d'attendre l'émission de 2 caractères avant de
les envoyer peut être
source de perte de données. On décide donc d'ajouter un offset
de 64 à chaque caractère
transmis après DLE, c'est à dire que l'octet 17 sera maintenant
transmis comme la suit
e d'octets [DLE = 16, 17+64 = 81], et l'octet 19 comme [16, 83].
La séquence d'octets [16, 19, 81] peut ainsi être correctement
comprise comme le début
d'une séquence d'échappement, la transmission d'un XOFF, et la
fin de la séquence
d'échappement définissant l'octet 17. Un autre problème
survient alors : la transmission
du caractère d'échappement, qui doit être échappé lui-même,
faute de quoi le caractère
qui le suit risque d'être interprété comme le second
caractère d'une séquence d'échappement.
L'octet 16 sera donc transmis comme la séquence d'octets [DLE=16,
16+64=80].
---------------------------------------
Conclusion :
BAD SOLUTION !
Reserver le protocole mode XON-XOFF software au fichiers
contenant uniquement une représentation en Ascii ..
Passer en mode protocole CTS Hardware pour le binaire pur
Test lecture
fichier Wav ,via UART1, avec protocole Hardware CTS
(File transfer via terminal-> UART)
Pin RC5utilisé comme envoi info CTS du PIC -> terminal
sbit CTS at LATC.B5;
05/11/2021
Pour cela , il faut pouvoir
utiliser CTS , info envoyée par le PIC au
terminal, pour l'autoriser à envoyer des datas .
On peut donc ainsi gerer le flux de reception coté PIC
usage d'un cordon Prolific 6 fils .. comprenant CTS et RTS en plus de RX,TX
RTS non utilisé, car l'usage de CTS seul est sufisant ( RC5 ---->
CTS terminal )
infos USBVIEW :
FT232R USB UART USB Serial Converter COM2 AH05HE84 0403 6001 6.00
Future Technology Devices International, Ltd FT232 Serial (UART)
IC FTDIBUS
Driver ftdibus.sys FTDI 90 mA 2.00 USB Serial Converter 2.12.28.0
FtdiBus.
NTamd64 oem36.inf USB\VID_0403&PID_6001\AH05HE84
03/09/2022 14:42:31
sbit CTS at LATC.B5;
sbit CTS_Dir at TRISC.B5;
sbit Affiche_Detail at PORTB.B1;
sbit Affiche_Detail_Dir at TRISB.B1;
L'échange se fait à 115200 bds.
Le PIC est maitre par rapport au terminal PC ( YAT ou VBRAY)
Definition du protocole :
Préalable :
le fichier "cestcela.wav" original de 25Ko à
22050Hz est repris via AUDACITY pour le ré-échantillonner à
11025HZ
surtout afin de reduire sa taille ..
il est exporté ensuite
..avec une taille 13Ko .. on ne peut le lire en entier
Le terminal a une fonction d'envoi de fichier .
Designation d'un fichier *.wav , puis click sur SEND (envoi)
Le programme recupere le 1er bloc de 64 bytes ,
dont 44 premiers bytes constituent l'entete du fichier WAV.
Les principaux parametres du fichier wave sont affichés, dont la
taille fichier datas et la vitesse PCM
Puis ensuite on recupere les datas , par blocs de 64 bytes
pendant la lecture , parties Datas du fichier ( UART1 interrupt )
, les 7500 premiers bytes sont copiés dans la
foulée ,
dans le Buffer1 ET en RAM -> Wave_Table
* pas assez de RAM pour contenir tout le fichier !
#define
MAX_WAVE 7500
Option :
Affiche Detail data blocs , via Pin RB1=0
Affichage de chaque bloc est affiché sur le terminal en ascii et
Hexa
pour pouvoir comparer / verifier avec wxHexEditor ( programme d'affichage
de fichier : adresse, et contenu en ascii et Hexadecimal
en fin de lecture
Activation PWM1 à 11025Hz
..
Restitution des 7500 bytes datas
via une boucle de lecture de Wave_Table
-> duty-cycle du PWM1 , et delay de boucle 90µS ( Periode PWM1=1000
000 / 11025=90,7µS , puis tourne en boucle ..
sortie RC2 --via filtre RC passe bas R=1K-- et C=1nf --> ampli
BF
ou plus simple ! commande directe RC2 --> N-MOSFET avec HP 16
ohms en serie avec L=200µH , coté Drain (alim 5V à 12V)
ou avec le meme Interface
de sortie utilisé avec PWM DDS
avec sortie sur l'entrée Micro carte son du PC
Nota :
Il s'avere qu' avec YAT terminal, on ne peut pas STOPPER l'envoi
(commencé) d'un fichier
j'ai donc utilisé à la place TERATERM terminal ..
qui peut le faire!
Les 3 phases du programme :
 |
 |
 |
| Init programme, attend le fichier | fichier en cours d'envoi | fin d'envoi , lecture et envoi PWM datas |
signal de sortie PWM ,avant filtrage , avec SQA
analyser :
la durée de boucle programme doit être ajustée à 1/F=1000000/11025
µS
et pas d'interruption validée.
Autre tests avec :
ok_11025.wav 6Ko
cestcela_oui_11025.wav
I_am_ready_11025.wav
10ko
Traçage programme :
capture_cestcela_oui_11025_8bit_2022-0901.txt
Projet MikroC Pro 7.60:
Lecture petit fichier wav en RAM :
Projet :Read_WAV_and_Play_by_PWM_18F27K42_2022_09.mcppi
Source : PIC18F27K42_Lect_WAV_by_UART_CTS_and_Play_by_PWM_RC2_2022_0901.c
Chargeur : Read_WAV_and_Play_by_PWM_18F27K42_2022_0901.hex
Config : Read_WAV_and_Play_by_PWM_18F27K42_2022_09.cfg
Résumé des Outils dispos :
* Excel voir WAV_info_2022-08.xls
* Audacity
* MediaInfo
* wxHexEdit.exe
* PIC18F27K42 :PIC18F27K42_test_UART_IVT_and_WAV_2022_0828.c
Tests sur la memoire FLASH 18F27K42
Usage de MPLABX XC8 ( mieux approprié que MikroC 7.60 !)
Test ecriture et lecture de datas ( bytes) dans l'espace d'adresse
> 32000 soit 0x7D00
La memoire Flash s'efface par bloc de 128 bytes
On peut lire 1 seul byte en Flash
Pour ecrire il faut d'abord effacer celle ci .
Test de lecture d'un bloc de 128 bytes
La memoire flash vide contient des 0xFF partout .
Usage de SMT1 pour chronometrage precis de la durée de lecture
de 128bytes en flash.
SANS afficher les datas lues!
Test 4A Re-Lecture 128 Bytes en Flash at @ 0x7D00 soit 32000
Duree relecture 128 bytes en flash :416 uS
---------------
avec AFFICHAGE data
lues
Test 4A Re-Lecture 128 Bytes en Flash at @ 0x7D00 soit 32000
32000 -> 0x00.0x01.0x02.0x03.0x04.0x05.0x06.0x07.0x08.0x09.0x0a.0x0b.0x0c.0x0d.0x0e.0x0f.
32016 -> 0x10.0x11.0x12.0x13.0x14.0x15.0x16.0x17.0x18.0x19.0x1a.0x1b.0x1c.0x1d.0x1e.0x1f.
32032 -> 0x20.0x21.0x22.0x23.0x24.0x25.0x26.0x27.0x28.0x29.0x2a.0x2b.0x2c.0x2d.0x2e.0x2f.
32048 -> 0x30.0x31.0x32.0x33.0x34.0x35.0x36.0x37.0x38.0x39.0x3a.0x3b.0x3c.0x3d.0x3e.0x3f.
32064 -> 0x40.0x41.0x42.0x43.0x44.0x45.0x46.0x47.0x48.0x49.0x4a.0x4b.0x4c.0x4d.0x4e.0x4f.
32080 -> 0x50.0x51.0x52.0x53.0x54.0x55.0x56.0x57.0x58.0x59.0x5a.0x5b.0x5c.0x5d.0x5e.0x5f.
32096 -> 0x60.0x61.0x62.0x63.0x64.0x65.0x66.0x67.0x68.0x69.0x6a.0x6b.0x6c.0x6d.0x6e.0x6f.
32112 -> 0x70.0x71.0x72.0x73.0x74.0x75.0x76.0x77.0x78.0x79.0x7a.0x7b.0x7c.0x7d.0x7e.0x7f.
Duree relecture 128 bytes en flash :64593 uS (inclus le
bavardage affiché ci dessus !)
c'est jouable ! 3µS
/ byte
à 11025Hz cycle de ~90µS
il reste donc suffisament de temps pour envoyér la data lue en
flash vers PWM output
il faudra eventuellement faire des ajustement dùs au decalage
temporelle lors du
franchissements de page de 128 bytes
CCP1 associé à Timer2
il faut privilégier l'usage d'une valeur maxi pour TMR2PR ideal=255
pour avoir le maximum de resolution = 10bits
sinon on atteint 100% PWM avec une valeur moindre
exemple:
avec F PWM désirée proche de 11050Hz (et T2CLCK=FOSC/4=16MHz)
si TM2PR= 180 Prescaler 1/8 et Postscaler 1/1 => division
globale =1/8 =>maxi 100% duty avec consigne < 720 points
.. RAPPEL : Le
postscaler n'intervient pas dans le CCP1 PWM !!!!!!!!!..............
----------------------------------------------------------------------
Bizarrerie :
Usage de TIMER2 associé à CCP1 PWM
si j'initialise Timer2 ..avec une valeur de Postscaler >0 ..
donc diviseur actif = valeur OutPSC +1
Le postscaler intervient bien ..
ex : avec Timer2 config : PR2=240 Prescaler=1 => div 1/2,
Postscaler = 2 => div 1/3
on obtient aussi une valeur proche de 11025 : ici 11065,
l'avantage est que la commande duty passe à 920 pour 100%.
mais ! si ensuite je valide CCP1 PWM ... la frequence PWM passe à 30KHz .. le POSTSCALER n'intervient plus dans Timer2 ! en mode
PWM.
=> retour à la 1ere config du timer2 (PR2=180) ..prescler 1/8
.et Postscaler=0 donc div 1/1...= pas de postscaler
 |
|
 |
----------------------------------------------------------------------------------
exemple de capture fichier : OK_11025.wav .. affichage sur terminal .
Le 1er paquet de 64 bytes sera lu en RAM , pour vérifier/
récuperer les parametres du fichier wav
Freq echantillon 11025Hz , mode
Mono , format PCM 8bits , taille des
datas contenues dans le fichier
...ensuite lecture par paquet de 128 bytes pour etre en
adequation avec les blocs en Flash 128bytes.
le dernier paquet peut eventuellement etre omis si < 128 bytes..
Une fois mis en Flash
Lecture de celui ci directe sur sortie PWM ..RC1 .. jusqu' la
taille fichier -64. ou Nb de blocs .
nota :
vu que l'amplitude du wav est sur 8 bits, on a pas besoin de la
résolution 10bits du CCP1 PWM
avec une valeur plus faible de PR2 , le 100% du cycle est ateint
pour 720 au lieu de 1023.
Je n'ai pas trouvé
comment travailler en 8bits avec ces CCP PWM ? sur ce PIC, pour avoir duty=255 => 100%
Software MPLABX XC8 V2.32
source : main_2022-0912.c
Packaged project in C:\MPLABX_Projects\18F27K42_Test_Ecr_Lec_Flash_2022-09.X\
18F27K42_Test_Ecr_Lec_Flash_2022-0912.zip
chargeur :
C:\MPLABX_Projects\18F27K42_Test_Ecr_Lec_Flash_2022-09.X\dist\default\production
18F27K42_Test_Ecr_Lec_Flash_2022-09.X.production.hex
Hardware
,utilise uniquement :
liaison UART1 RC6 Tx RC7 Rx -> interface prolific vers
terminal RealTerm (envi le fichier wav),
RC5 =CTS -> RTS interface prolific,
liaison RB1 ,
liaison RC1 PWm output + filtre passe bas -> ampli BF
ou carte SON PC
alim 3,3 à 3,6V ..
5.0V possible ... suivant l'interface TTL/USB utilisé.
Program space used 3DA4h ( 15780) of 20000h bytes ( 12.0%)
Data space used 1E0Eh ( 7694) of 2000h bytes ( 93.9%)
Lecture gros fichier WAV (106Ko) ..
déja en Flash !
et restitution audio via sortie RC1 PWM + filtre passse bas!
Le fichier WAV est lu , décomposé en paquet de datas DB 0xXX,0xXX
... capturé par Realterm dans un fichier .
On peut en profiter pour récuperer les datas du fichier wav ,
sous forme de table ,
prete à etre include soit en ASM , si on a mis DB en tete de
chaque ligne,
soit dans une table pour MikroC ou XC8 (sans l'entete DB)
Il s'avere que la taille maxi d'une table en Flash ne peut pas
depassser 65535 !
Sous mikroC , pas besoin de definir la taille ... le nb de datas
dans la liste suffit au compilateur
Par contre Problemo
avec XC8 , il veut connaitre au
prealable ,la taille de la table ! pas assez futé !
exemple avec Lecture du fichier Tou_nu_tou_bronze_9.6sec.wav
104Ko
avec MikroC
const Byte SonWav[]=
{ 0x02,0x9E,0xF0,0x49,0x40,0x33,0x33,0x3C,0x46,0x59,0x60,0x52,0x4C,0x57,0x5F,0x5A,
// ligne 38
0x58,0x65,0x7B,0x83,0x77,0x66,0x68,0x75,0x80,0x87,0x86,0x7A,0x75,0x7E,0x7C,0x75,
0x7A,0x82,0x90,0x96,0x8D,0x7E,0x77,0x7C,0x86,0x90,0x91,0x9A,0xAA,0xB1,0xA6,0x9D,
.. etc ...
0x71,0x65,0x75,0x7A,0x73,0x79,0x81,0x74,0x65,0x6D,0x82,0x97,0x96,0x7C,0x6A,0x72,
0x8A,0x9A,0x94,0x89,0x8C,0x8C,0x7C,0x6F,0x75,0x82,0x81,0x81,0x85,0x89,0x85,0x85
// ligne 4094
};
------------------------------
const Byte SonWave1[]=
{
0x8D,0x86,0x78,0x75,0x86,0x8D,0x82,0x72,0x70,0x7D,0x7D,0x6C,0x66,0x74,0x7A,0x67,
// ligne 4098
0x64,0x83,0x9D,0x96,0x75,0x61,0x71,0x8A,0x83,0x76,0x83,0x8F,0x7D,0x78,0x84,0x7F,
.....
0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x80,0x81,0x81,0x81,0x80,0x80,0x80,
0x80,0x80,0x80,0x80,0x80,0x80,0x81,0x81,0x80,0x80,0x80,0x80,0x80,0x81,0x00,0x00
//....... ligne 6683
};
avec XC8
main.c
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,
0x58,0x65,0x7B,0x83,0x77,0x66,0x68,0x75,0x80,0x87,0x86,0x7A,0x75,0x7E,0x7C,0x75,
0x84,0x8C,0x85,0x71,0x69,0x7F,0x91,0x86,0x75,0x6D,0x70,0x7C,0x84,0x81,0x81,0x85
// ligne 4142
};
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,0x80,0x80,0x80,0x80,0x81,0x81,0x81,0x80,0x80,0x80,
0x80,0x80,0x80,0x80,0x80,0x80,0x81,0x81,0x80,0x80,0x80,0x80,0x80,0x81,0x00,0x00
// ligne 6786
};
dans les 2 versions , MikroC pro 7.60 ou XC8 V2.32 ,
le code est quasiment le meme, au détails de syntaxe pres ..et
la déclaration des tables.
corps de la version MikroC
La restitution sonore via sortie RC1 PWM +
filtre passe Bas est OK
Software :
MikroC :
_18F27K42_Play_WAV_en_flash_2022-0921_MC.zip
MPLABX XC8 :
choix des datas fichier wav à la compilation :
# include "SonWav_bourrepif_datas_en_2_tables.txt"
Test_Lec_Wav_en_Flash_18F27K42_Bourrepif_.X.hex
//#include "SonWav_tou_nu_tou_bronze_datas_en_2_tables.txt"
Test_Lec_Wav_en_Flash_18F27K42_Toutnutoutbronze.X.hex
Packaged project in C:\MPLABX_Projects\Test_Lec_Wav_en_Flash_18F27K42.X\
Test_Lect_Wav_en_Flash_18F27K42_2022_0923.zip
main_Wav_en_2_tables_en_const_20220923.X_OK.c
Lecture fichier WAV envoyé par
RealTerm vers l' UART via cordon Prolific 6 pins
version MPLABX IDE 6.00 + XC8 V2.32
Usage de Realterm
protocole RTS , gestion manuelle
du flux via sortie RC5 vers CTS prolific (fil bleu),
lectures par paquet de 128 bytes., cadencés par RTS..
Sortie Son PWM sur RC1 via filtre passe-bas
lecture et restitution de bourrepif_11025_Mono_8b_4.86sec.wav.....
50Ko..OK
La taille de Flash Code est limitée via l'option suivante , à 0x2800:
le parametrage FLASH se retouve dans MCC Memory.h
#define FLASH_ROW_ADDRESS 0x2800 // 3000h->12288
#define FPAGE_SIZE 128
#define MAX_FLASH_ADRESS 0x20000................//131072 - 12288
=> 120832
#define WRITE_FLASH_BLOCKSIZE 128
#define ERASE_FLASH_BLOCKSIZE 128
#define END_FLASH 0x20000
Test by Satinas
ref: https://www.fantaspic.fr/viewtopic.php?f=10&t=1246&start=10
compilation conditionnelle avec : #define With_Satinas_Test
Au lieu de lire le fichier wav et le stocker en Flash ,
On ecrit simplement une valeur donnée (ici 0x34 = '4') dans tout
l'espace flash dispo
puis relecture via le Pickit3 pour verifier le contenu flash..
Software :
18F27K42_Test_Ecr_Lec_Flash_Satinas_test_2022-0927.X.hex
puis relecture du contenu
flach avec Pickitminus.exe
 |
 |
la valeur '4' =>0x34 est bien presente ...de 0x2800 à 01FFFF
MAIS la fin du
programme, le clignotement led
apres l'ecriture flash: CPrint("Fin test satinas\r\n");
n'est pas
exécutée correctement !
Le programme plante ..grosse
serie de '4' affichée sur le terminal , au lieu du message de fin de test ...
à croire que l'écriture en flash, a écrabouillé du code ou
des variables programme ..
malgré la limite (supposée) de ROM à 0x2800..
la compilation donnant :
Memory Summary:
Program space used 15DEh (
5598) of 2800h bytes ( 62.5%)
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%)
Extrait du fichier *.MAP, résultant de la compilation :
on a bien la limite 2800H , et une
taille de code qui est inférieure !
Si le message de fin de test est prédéfini en ROM,
const char Msg1[]="Fin
test satinas OK\r\n";
et usage de CPrint(Msg1);
même probleme !
*********************************
PROBLEME de fond
NON RESOLU !
*********************************
Par contre, si le message de fin de test est en RAM,
via
strConstRamCpy(CRam1,"Fin
test satinas ..OK\r\n");
et donc apres le remplissage flash
Print(CRam1); // ....
OK
le terminal affiche bien le texte , le
programme ne se plante pas ..OK
Configuration en cours de XC8 :
SOFTWARE :
MPLABX XC8 2.32
Source : main_20220927.c
Packaged project in C:\MPLABX_Projects\18F27K42_Test_Ecr_Lec_Flash_2022-09.X\
18F27K42_Test_Ecr_Lec_Flash_2022-0927.zip
Fichier wav utilisé : Tou_nu_tou_bronze_9.6sec.wav ( 11025Hz 8bits PCM Mono)
828 blocs de 128 bytes datas Wav sont stockés en Flash ...
105984 bytes
capture_2022-0926_2800_1CD80_Tou_nu_9.4sec.wav_presque_OK.txt
Lecture flash jusqu'au bloc 828 .. sans que le message de fin , s'affiche sur
Terminal
(cas similaire au Test Satinas)
..mais la restittution sonore se poursuit quand meme !! ... OK à
90%
nota : *.hex dans le zip
Option prévue dans le source (mais non activée)
Stockage en Eeprom d'un Flag + taille fichier data
pour pouvoir ensuite , rejouer le Wav saisi indefiniment .. reste
stoké en Flash
et joue le WAV sur Reset ou alim PIC..
option testée OK ..
Rappel : la version libre de XC8 ! volontairement bridée
!...
est-ce que ça peut expliquer le probleme rencontré ?
en lançant Compiler Advisor :
on voit bien l'incitation
à prendre la version XC8 PRO ..payante !
Version 2024
MPLABX XC8
Lecture fichier WAV < 106Ko via envoi
fichier sur UART par YAT Terminal
( liaison PIC UART via cordon Prolific TTL 6 pins/USB ( usage de
Hardware protocole CTS)
stockage en FLASH
Possibilité de recuperer les datas du fichier wav, (log du
terminal YAT) pour les mettre ensuite "en dur"
dans l'espace FLASH du PIC18F27K42, sous forme de fichier texte
à incorporer dans le code C (*.txt ou *.inc)
moyennant quelques petites manip ..
ex: remplacer \r\n\r\n par \r\n pour eliminer les sauts de ligne entre les blocs de 64
datas
Petit probleme :
avec fichier son wav
//WAV tout nu tou bronze
106Ko
const uint8_t SonWav[64000]= ... // 4000 lignes de 16 datas
et la suite
// 2em partie
const uint8_t SonWav1[42304]= ..... // 2644 lignes de 16 datas
taille de L2=0 ????
si impression sur la meme ligne !! mais OK en 2 lignes séparées
L1=sizeof(SonWav);
L2=sizeof(SonWav1);
sprintf(CRam1,"SonWav
size L1=%u , SonWav1 L2=%u \r\n",L1,L2);
Print(CRam1);
CRLF1();
L1=sizeof(SonWav);
sprintf(CRam1,"SonWav L1=%u ",L1); //
Print(CRam1);
L2=sizeof(SonWav1);
sprintf(CRam1," SonWav1 L2=%u \r\n",L2); //
Print(CRam1);
Test_Lect_Wav_en_Flash_18F27K42_2024
SonWav_tou_nu_tou_bronze_datas_en_2_tables.txt 106k
SonWav size L1=64000 , SonWav1
L2=0
SonWav L1=64000 SonWav1 L2=42304
main_Test_Lect_Wav_en_Flash_18F27K42_2024.X.c
Test_Lect_Wav_en_Flash_18F27K42_2024.zip
Pour Rejouer le fichier WAV
capturé .
en autonome , ...sortie PWM
RC2 directe sur Gate MOSFET
avec MOSFET IRLZ14
Gate --- 4,7K avec Gnd (Source)
Gate --- RC2 PIC PWM
Drain --- HP16 Ohms ---( via ampoule 12V 5W)-- +9V (en amont du
regulateur 5V)
Source --- Gnd
ou via Application
sur PC et entree Micro
Necessite d'intercaler un filtre pase Bas
2,7K + 330nF
VLC
ouvrir un flux de capture
Ouvrir un media
.....video Aucun
.....nom du peripherique audio
..........Microphone (Via HD Audio)
..............Lire
ou en différé via NCH Suite Wavepad.exe ...
usage de recorder entree micro.
 |
 |
| contenu entete wav | rejoué : en sortie RC2 PMW filtrée |
Projet
Anti-Chats ( MikroC 7.60)
Hardware :
Base 18F27K42
Projet_Antichats_2024.ods
Presentation :
Directory :C:\_MikroC\_MesProjets_MikroC\_18F27K42_Play_Wav_File_2025
MikroC pro 7.60
Projet :_18F27K42_Read_Wav_File_to_Flash_then_Play_it_2025_01.mcppi
Lecture fichier WAV (8bits PCM) via UART1
Config bit : P18F27K42_Fosc_Interne_Legacy_interrupts_16x4_PLL_64MHz.cfgsch
FOSC:64.0 MHz
Eeprom: not used ....
Source : PIC18F27K42_Lect_WAV_by_UART_CTS_and_Play_by_PWM_RC2_MC__2024-1226.c
18F27K42 UART1 1152000 bds
Protocole Hardware CTS sur output RC5 blocs
de data=64 bytes
LEGACY mode for Interrupts
RB0 interrupt PIR sensor
Affectation PIN RC2 à Sortie PWM1 par defaut !
Init PWM1 ..Start, ...set duty=50%
Surveillance PIR Sensor (Rising Edge count on RB0
Rising Edge count on RB0= 1
un detecteur PIR connecté sur pin RB0 , declenche sur la passage
d'un corps rayonnant infra rouge
une interruption => joue le fichier Wav ( aboiement de chien
!)
PIC18F27K42_Lect_WAV_by_UART_CTS_and_Play_by_PWM_RC2_MC_2024_1226.c
_18F27K42_Anti_Chats_2025-0101_MC.c
_18F27K42_Anti_Chats_2025-01.zip
Lecture fichier WAV envoyé par
RealTerm vers l' UART via cordon Prolific 6 pins
version MikroC Pro 7.60
La meme application, meme hardware,
mais fichier wav de 10sec ( 110 ko
) Taille data = 111910 bytes
avec MikroC , ne plante pas !
et charge COMPLETEMENT le fichier wav : 874 blocs
..OK
et affiche le message de fin ..OK
Software ( MikroC Pro):
projet : Put_Wav_file_in_FLASH_then_play_it_18F27K42_2022_1001_MC.zip
source : Put_Wav_file_in_FLASH_then_play_it_18F27K42_2022_1001.c
chargeur : 18F27K42_Put_Wav_in_Flash_then_Play_it_2022_10.hex
capture terminal : Capture_tout_nu_tout_bronze_10sec_874blocs_OK_avec_MikroC_2022-1001.txt
nota:
Les Statistiques montrent :
0 127 All files Compiled in 140 ms
0 1144 Used RAM (bytes): 399 (5%) Free RAM (bytes): 7771 (95%)
0 1144 Used ROM (bytes): 9711 (7%) Free ROM (bytes): 121361 (93%)
0 125 Project Linked Successfully _18F27K42_Put_Wav_in_Fash_and_play_it_2022.mcppi
0 128 Linked in 78 ms
Hex compilé en moins de 0,5sec .. on est lbien plus rapide qu'Avec
XC8 !!
Fonctions sorted by adress :
montrent que le programme occupe 9000 bytes .....
Variables triées par adresses :
..soit l'adresse maxi 0x2328
mais le tableau au dessus, montre des pointeurs dans la zone 0x3FF6 .. 0X3FF8
on est bien en Flash ?
La RAM de 8192 bytes -> maxi 0x2000
L'espace Flash dispo debuterait en 0x3000 => 20000-3000=1D000
=> 118784 bytes dispo ?
origine definie par #define
FLASH_ROW_ADDRESS 0x3000
...à
confirmer ?
-------------------------------------------------
Option :
conservation du Wav saisi en Flash
Flag en Eeprom adress 0 pour signifier qu'un *.wav a été lu
Sauvegarde en Eeprom de la taille du fichier WAV à l'adress 1,2,3,4
(32 bits)
Rajout Entrée de selection Keep_file (RB2)
RB2=0 , on garde, si déja present, le Wav precedement saisi
RB2=1 , saisie d'un nouveau fichie Wav
Le Wav est donc gardé en flash , meme sur Reset ou coupure alim.
Eeprom 0 -> Eeprom 0 -> 63
26 B5 01 00 FF FF
soit Flag=99 et taille fichier = 01B526 => 111910 bytes (File_Size)
Put_Wav_file_in_FLASH_then_play_it_18F27K42_2022_1002.c
TESTS sur fichier DTMF emis via PIC18F27K42
10/10/2022
Rappel :
les données de 16 fichiers DTMF_*.wav originaux, sont stockées dans 16 tables en Flash.
regroupées ici dans un fichier à inclure dans le programme : DTMF_16_Tables_code.inc.
Modif du programme
pour permettre
* La Verification de Fréquence et Duty value du CCP1 PWM
associé à TIMER2, pin via RA2 =0
Timer2 calé sur 88398Hz au lieu de pres de 11025hz, et delay de
boucle=85µS
* La Saisie au clavier (terminal) d'une note DTMF parmi 16, et la
jouer sur la sortie PWM
ex: Note=x avec x limité de 0 à9 ..par facilité! ex: Note=6
pour Table DTMF_6
La sortie RC2 PWM est aiguillée sur l'entree Micro carte SON PC,
via un pont diviseur 10K+2,2K
Oscilloscope connecté sur la 2,2K.= signal d'entree carte son
Le logiciel AUDACITY est utilisé ici, pour
capturer le signal PWM et en déduire le spectre FFT. (sur 1024
pts)
ainsi que l'oscilloscope , pour verifier l'efficacité d'un
filtrage passe bas avec une cellule RC
filtre = R serie de 10K ,puis C=47nF // 2,2K
Analyse SANS et AVEC filtre
sur la sortie signal PWM
 |
 |
| Analyse avec AUDACITY | filtre RC passe bas |
On voit bien le Nettoyage dû au filtre, sur le signal vu à l'Oscilloscope.
à comparer d'ailleurs avec le signal obtenu , ci dessous , avec
le fichier original DTMF_6.wav
C'est beaucoup moins flagrant sur l'analyse FFT , car la carte
SON du PC ..sert aussi de filtre !
nota : zoom appliqué sur les valeurs emergentes du spectre FFT.
Comparaison avec le fichier Wav
orginal (origine analogique)
quasiment pas de bruit sur le signal , et donc une FFT bien plus
propre
Analyse signal PWM DTMF_6 , avec TCube.exe
Outil ancien, mais sympatique et facile d'utilisation .(OK sous
Win10)
Version légerement modifiée du programme utilisé :
Projet :
_18F27K42_Play_DTMF_wav_en_flash_2022-1010.zip
PIC18F27K42_Play_DTMF_files_WAV_in_Flash_2022_1010.c
18F27K42_Play_DTMF_wav_en_flash_2022-1010.hex
Usage
de REALTERM pour envoi d'un fichier dans un PIC
(fichier Wav ou autre)
 |
 |
| configuration via le terminal | Ecrans de Configuration Realterm |
fichier d'init obtenu , doit etre dans le meme
dossier que realterm.exe !
realterm.ini
à noter qu'un fichier de type WAV contient des infos dans son
entete (44 premiers bytes), permettant ,entre autre ,
de connaitre la taille des datas à lire ...
L'usage d'un timeout permet de capturer le dernier bloc de datas
qui n'est pas un multiple exact de 128.
Usage pour l'envoi d'un WAV dans le PIC :
Verifier que Realterm est actif, que le PORT est ouvert .. voir en
bas et à droite
saisir le nom du fichier wav
Lancer l'appli PIC
à l'invite du message :
Etape 0
.. Attente pour capture fichier wav
Valider l'envoi en cliquant sur SEND
L'Uart reçoit le fichier Wav, et stocke les datas en flash par
blocs de 128 bytes ..
puis les datas sont relues de la Flash et envoyées sur la sortie
PWM CCP1
pin RC1-> filtre passe bas -> entree carte SON PC ou ampli
BF
et tourne en boucle ...
Option Listing du fichier saisi:
si RB1 est à 0 , valide l'impression du listing contenu du
fichier avec adresses et datas en hexadecimal , formatées par
blocs de 128 bytes
Activer la Capture sur Realterminal
Definir le nom du fichier recepteur dans File
exemple: D:\Realterm\capture.txt"
( decocher la case "Direct" et la case
"+LF" et click sur "Start
Overwrite"
..
en fin de capture.. clicker sur "Stop Capture"
.. et "Edit"
