wav player avec pic16F84a et 24C256

[invite03481543]

...mais j'ai bien dit qu'il fonctionne correctement.....

Post#1:

mais j'ai pas reuissi a reproduire le message sonnore;toujour un bruit de Tic tac...

Tu te fous de moi ou quoi?
-----

[invite03481543]

l'operation read ou write revient a l'etat de bit 0 du variable unsigned char blocSel_rw:
blocSel_rw=0b10100000 operation d'ecriture.
blocSel_rw=0b10100001 operation de lecture.

Dans ce cas tu dois t'habituer à donner des appellations qui veulent dire quelque chose, pourquoi blocSel....?
Soit tu déclares en dur comme je te l'ai indiqué en #26 soit tu peux faire encore:

EEPROM_add = 0xA0; // en écriture
EEPROM_add = 0xA0 | 1; // en lecture

Ensuite ce genre d'EEPROM s'adresse de la façon suivante pour écrire un octet:

1/bit de start
2/octet de contrôle (en écriture donc 0xA0)
3/envoi de l'adresse sur 16 bits, byte High puis byte Low
4/envoi de la data sur 1 octet
5/bit de stop

pour écrire une page (64 octets):

1/bit de start
2/octet de contrôle (en écriture donc 0xA0)
3/envoi de l'adresse sur 16 bits, byte High puis byte Low
4/envoi des 64 octets
5/bit de stop

A cela il faut ajouter la gestion de l'acknowledge (ACK) en I2C, l'EEPROM génère un ACK pour permettre au maître (le µC) de poursuivre en temps voulu, vu que le temps d'écriture est variable et relativement long.

voici comment tu pourrais faire plus subtilement:

// prototype des fonctions à déclarer en tête de programme
void i2c_EEPROM_write(char addrH, char addrL, char data);
void i2c_EEPROM_write_string(char addrH, char addrL, char* data);

...............
void i2c_EEPROM_write(char addrH, char addrL, char data) // pour écrire une simple data (1 octet)
{
        i2c_start();
        i2c_write(0xA0);   // adresse en écriture             
        i2c_write(addrH); // adresse haute              
        i2c_write(addrL); // adresse basse              
        i2c_write(data);   // data -> la donnée à écrire             
        i2c_stop();
        delay_ms(5);
}

void i2c_EEPROM_write_string(char addrH, char addrL, char* data) // écriture d'une chaine de datas
{
        while(*data) // on utilise un pointeur qui contient l'adresse de la 1ere data à envoyer
        {
                i2c_start();
                i2c_write(0xA0);                
                i2c_write(addrH);              
                i2c_write(addrL);         
                i2c_write(*data++);                
                i2c_stop();

                addrL++;
                if(addrL==0x00) addrH++;

                delay_ms(5);
        }
}

Reste à peaufiner avec ton application.

[freepicbasic]

Sur le schéma du post #29 pas de quartz et condos, pas de résistance de reset !

Je me demande ce que fait la simule avec ça ... ?

Et les bits de config ?

Je croyais que le but était de lire l'eeprom, apparemment les routines décritent sont en écriture.


Notez que pour lire une première salve d'écriture vide est nécessaire qui permet de programmer l'adresse.
(voir image du datasheet ci-joint)

[amitech82]

post#1:


Tu te fous de moi ou quoi?

excusez-moi...je repete...le pic16f84a lire les donnees sans aucun probleme avec ce routine...le pic16f84a lire les donnees sans aucun probleme avec ce routine...le pic16f84a lire les donnees sans aucun probleme avec ce routine...le probleme est dans la restitution du message sonnore...je crois que c'est claire!
Et merci.

[amitech82]

Sur le schéma du post #29 pas de quartz et condos, pas de résistance de reset !

Je me demande ce que fait la simule avec ça ... ?

Et les bits de config ?

Je croyais que le but était de lire l'eeprom, apparemment les routines décritent sont en écriture.


Notez que pour lire une première salve d'écriture vide est nécessaire qui permet de programmer l'adresse.
(voir image du datasheet ci-joint)

Merci cher ami pour votre aide...le PIC peut lire les octets de l'eeprom sans probleme..et avec la frequence de 8000hz...c'est verifier...
Sur ISIS on peut négliger l'emploi du quartz et ces condos pour les PICs...

Si quelqu'un peut reproduire le montage du Mr Alain Reboux(Electronique Pratique n°277) sur ISIS...je serai reconnaissant.

[invite03481543]

excusez-moi...je repete...le pic16f84a lire les donnees sans aucun probleme avec ce routine...le pic16f84a lire les donnees sans aucun probleme avec ce routine...le pic16f84a lire les donnees sans aucun probleme avec ce routine...le probleme est dans la restitution du message sonnore...je crois que c'est claire!
Et merci.

En effet, on dirait même que le disque est rayé!

[freepicbasic]

Le simulateur est trop lent !!!!!!!
et ne peut pas faire du temps réel !

L'eeprom est lu en réel en 4 secondes

J'ai essayé la simulation.

Sur le simulateur la lecture dure une éternité et le son qui sort ressemble au bruit d'une balle de ping pong qui rebondit par terre.

il faut faire le montage en réel !

Sur les options de simulation, il est écrit 20 trames par seconde , ça risque pas de faire du 8khz...

[amitech82]

Le simulateur est trop lent !!!!!!!
et ne peut pas faire du temps réel !

L'eeprom est lu en réel en 4 secondes

J'ai essayé la simulation.

Sur le simulateur la lecture dure une éternité et le son qui sort ressemble au bruit d'une balle de ping pong qui rebondit par terre.

il faut faire le montage en réel !

Sur les options de simulation, il est écrit 20 trames par seconde , ça risque pas de faire du 8khz...

merci pour votre aide mon ami...je vais essayer le montage en réel...et a propos vous ne connaissez pas un simulateur efficace autre que celui d'ISIS.?

[Antoane]

Bonjour,

merci pour votre aide mon ami...je vais essayer le montage en réel...et a propos vous ne connaissez pas un simulateur efficace autre que celui d'ISIS.?

D'une manière générale, et tu le vois ici, il faut préférer la simulation par graphiques à la simulation en temps-réel.

Tu as du reçevoir des messages d'erreur (ou plutôt des warning) indiquant que la simulation ne fonctionnait pas en temps-réel, de même que ce devait être écrit en bas de la fênetre (près du gestionnaire de simu, avec les boutons play/pause/stop).

[amitech82]

Bonjour,

D'une manière générale, et tu le vois ici, il faut préférer la simulation par graphiques à la simulation en temps-réel.

Tu as du reçevoir des messages d'erreur (ou plutôt des warning) indiquant que la simulation ne fonctionnait pas en temps-réel, de même que ce devait être écrit en bas de la fênetre (près du gestionnaire de simu, avec les boutons play/pause/stop).

je vous remercie pour cette clarification.

[amitech82]

....Très bonne novelle les amis ...j'ai essyé le montage sur une plaque d'essai...et...ça a marché!...oui ça a marché ...le message enregistrer sur le 24LC256 a été restitué correctement...j'ai essayé en premier lieu avec le code de Mr Alain Reboux...ensuite avec mon code écrit sur MikroC...est aussi....ça a fonctionné a merveille...exactement comme celui de Mr Reboux pour la mag.Electronique Pratique n°277...alors...conclusion; il ne faut pas se fier au simulateur ...oh Proteus je te hais...
merci a tous pour votre aide ...off, je passe maintenant a quelque choses de sérieux...si je ferais un vidéo du montage...je le mettrai ici.

[invite03481543]

J'ai hâte de voir ça.
Tu es bien sur que le code de M. Reboux est pas celui qui est resté coincé dans ton PIC? Parce que son code assembleur est correct.
Alors que celui que tu as posté à l'origine, ne peut pas fonctionner...

[amitech82]

J'ai hâte de voir ça.
Tu es bien sur que le code de M. Reboux est pas celui qui est resté coincé dans ton PIC? Parce que son code assembleur est correct.
Alors que celui que tu as posté à l'origine, ne peut pas fonctionner...

je te le jure devant dieu que c'est mon code cher ami !!!

[invite03481543]

Tu sais je suis comme St Thomas...

[amitech82]

Tu sais je suis comme St Thomas...

hahaha

[freepicbasic]

Sur le prog C du post#1
la boucle est de 2048 qui correspond à une 24C16

ça fait 1/4 de seconde à 8khz

Et chose étrange la commande adresse est sur 2 bytes comme pour une mémoire de taille supérieure.

[amitech82]

Sur le prog C du post#1
la boucle est de 2048 qui correspond à une 24C16

ça fait 1/4 de seconde à 8khz

Et chose étrange la commande adresse est sur 2 bytes comme pour une mémoire de taille supérieure.

oui j'ai oublié de modifier la boucle a 32768, lorsque je l'ai mis au poste 1 ...mais il n'y a pas de problème c'est la même routine...j'ai testé avec plusieurs message de 4s personnalisés...est ça fonctionne...maintenant je vais apprendre le protocole spi et la carte sd...merci