Plusieurs PIC et une mémoire

[verbalinsurection]

Bonjour tous le monde !

J'ai cherché sur le net mais je vous avouerais que j'ai eu du mal à comprendre les résultats que j'ai eu.

Petite explication de mon montage. J'ai, pour l'instant, 2 pic qui font office de fréquence-mètre, 1 pic de mesure de résistivité, 1 pic destiné à l'envoi RF du résultat de tout ça.

Déjà, cela m’ennuie d'utiliser 2 pic pour lire 2 fréquence, je pensais pouvoir en utiliser un seul mais vu que j'utilise les interruptions pour la mesure, je n'arrive pas à en compter 2.

Bref, mon problème est l'envoi des différentes valeurs. J'avais pensé que chaque PIC pouvait stocker la valeur qu'il mesure à une adresse spécifique d'une EEPROM externe (type 24C04) puis le PIC qui doit envoyer en RF lit chacune des ses valeurs et les envoi tout ceci en I2C. Donc en gros mes PIC serait en maitre et l'EEPROM en esclave si j'ai bien tout compris.

Qu'en pensez-vous ? si une écriture survient lorsque le pic qui envoie en RF veut lire que se passe t-il ? C'est une bonne idée de procéder comme ça ?

Merci d'avance
-----

[alainav1]

bonjour,
une pste
un 4066 pourrait faire office du choix de la mesure à prendre en compte
cordialement
Alain

[bobflux]

Y a pas 2 timer avec un mode capture sur ton pic ?

A priori je ne vois pas trop pourquoi tu as besoin de plus d'un uC...

[verbalinsurection]

Si il y a 2 timer, mais pour la prise de fréquence j'ai voulu utilisé l'interruption sur le port RB0. Je compte les front montant dessus pendant une seconde et j'en sort une fréquence.

Le code (compilo hi-tech)

interrupt isr(void)
{
    if ((INTF))
    {
        cntr++;
        INTF=0;
    }
    else if(T0IF==1)
    {
        ovrflw++;
        T0IF=0;
    }
    if (ovrflw > 3906)
    {        // 4000000/ 4/ 256 = 3906.25
       GIE=0;
       x=cntr;
       cntr=0;
       ovrflw=0;
       INTCON=0b10110000;
   }
}

Quand j'ai voulu rajouté une interruption sur le port RB7 par exemple, il y avait trop d'interruption et mon pic ne pouvait plus rien faire d'autre (affichage sur LCD par exemple)

[A voir en vidéo sur Futura]

[bobflux]

Tu ne peux pas utiliser un timer en mode compteur ?

[verbalinsurection]

Heu si pourquoi pas... tu peux m'en dire un peu plus ?

[RISC]

Salut ,

Quel PIC utilises-tu ?
Quelle est la fréquence de ton quartz ?
Quelle version du compilateur HiTech utilises-tu ?

a+

[verbalinsurection]

Je ne suis pas encore fixé pour le PIC, pour les tests j'utilise un 16F877A mais je compte en prendre un un peu plus "petit" au final.
Le quartz est celui du pic à 4Hz. Le compilo est en version 9.70 lite (la version gratuite).

[bobflux]

Heu si pourquoi pas... tu peux m'en dire un peu plus ?

Je ne connais pas les PIC mais tout uc normalement constitué a plusieurs "timer/counter".

Donc si tu mesures une fréquence relativement élevée tu utilises un timer en mode compteur pour compter les impulsions qui arrivent sur une broche, et tu as une interruption qui va regarder la valeur du compteur (mettons toutes les secondes).

Si tu mesures une fréquence relativement basse tu utilises un timer en mode capture qui lance une interruption par impulsion et le uC regarde la valeur capturée pour avoir la période.

> 2 pic qui font office de fréquence-mètre

donc 2 timers (ou 3)

> 1 pic de mesure de résistivité

1 ADC

> 1 pic destiné à l'envoi RF du résultat de tout ça.

1 UART

total 1 uC

[verbalinsurection]

Merci pour ces précisions

Donc si tu mesures une fréquence relativement élevée tu utilises un timer en mode compteur pour compter les impulsions qui arrivent sur une broche, et tu as une interruption qui va regarder la valeur du compteur (mettons toutes les secondes).

Donc ça ne générera pas d'interruption à chaque impulsion ? Comment le comptage va se faire ?

[bobflux]

Le compteur... il compte, c'est tout !

Après soit le uC regarde périodiquement le nombre d'impulsions comptées, soit tu mets une interruption sur l'overflow du compteur (quand il atteint 65536 et reboucle à 0) et le uC regarde combien de temps ça a pris.

[verbalinsurection]

Ok, je vois pas trop comment faire mais je vais fouiner dans le datasheet, merci encore pour tes réponses

[RISC]

Salut,

Si tu n'as pas encore fait ton choix concernant le PIC, pourquoi vouloir se polariser sur des PICs non adaptés alors qu'il en existe 700 autres ;=) dont certains avec plein de timers ?

Si ton cahier des charge est clair, utilises le logiciel de choix paramétrique MAPS (version offline installable) tu pourras entrer tes besoins et il filtrera les PICs qui conviennent.

Je te recommande de regarder du coté des PIC16F1xxx qui sont bien plus riches en timers ;=) comme les PIC16F1936/37

Ils fonctionnent avec le même compilateur

a+

[bobflux]

MAPS est le passage obligé si tu veux un PIC...

Sans parler des autres fabricants et familles (XXX, XXX, etc)

Sur un XXX à 3$ tu as 12 timers, lol.

[verbalinsurection]

je ne connaissais pas Maps, merci pour l'info
Je vais rester sur les pic, j'apprend et je ne voudrais pas trop me disperser tant que je maîtrise pas correctement le sujet.
Je vais donc voir avec maps, merci encore mais le projet et voue a évoluer, ajout de frequence mètre, d'affichage etc. Je vais voir tout ça et essayer de faire le max avec un seul pic mais correctement choisi
Faudra quand même que je m'essaye a i2c

[verbalinsurection]

histoire de pas créer un nouveau topic,si par exemple je me retrouve a devoir récupérer 30 frequences et 30 resistivite, je vais devoir passer par plusieurs pic, quel est le meilleur moyen pour transmettre tout ça via rf ? Sachant que j'aurais une mesure de chaque par 0.5 seconde. Passer par une eeprom ? Ça fait pas trop de lecture ecriture pour une eeprom ? Tout ça via i2c ? Ou alors il y a quelque chose d'autre pour gerere ce genre de chose ?
J'espere être assez clair

[bobflux]

> si par exemple je me retrouve a devoir récupérer 30 frequences et 30 resistivite

Alors là il faut utiliser un truc modulaire. Tu fais un module avec un certain nombre d'entrées "fréquence" et "résistivité" (ou 2 modules différents, un pour chaque...) et tu le(s) dupliques autant de fois que nécessaire. L'intérêt étant que c'est évolutif (tu peux en rajouter).

Il te faudra un module "maître" qui s'adresse à ces modules "esclave" qui font les mesures.

Pour faire communiquer le tout, tu peux utiliser des liaisons point à point (SPI ou RS232) mais dans ton cas puisque les mesures ne sont pas à très haut débit il vaut mieux utiliser un bus type I²C ou CAN.

Dans ce cas les modules sont des périphériques sur le bus, et le maître les interroge tour à tour pour avoir les valeurs mesurées, puis formate un paquet et l'envoie par RF.

Si ton protocole RF le supporte (genre pas un RF-RS232), tu peux aussi simplement faire une carte avec X entrées et module RF dessus, et dupliquer le tout, chaque carte envoyant ses mesures.

[verbalinsurection]

Merci beaucoup pour l'info, c'est exactement ça, je souhaite avoir un truc évolutif.
L'histoire des maitres / esclave j'ai vu ça au sujet de I2C, faut que je bouquine encore beaucoup à ce sujet.
Merci bien

(je risque revenir tout de même, je pense que j'aurais encore besoin de vos lumières )

[bobflux]

Tu prévois quoi comme longueur de fil pour ton bus ? (tous les modules dans une boîte, ou à 100m ?)

Tu as quoi comme protocole RF ?

[verbalinsurection]

Tous les modules dans une boite
Pour l'instant RF je en sais pas, je ne sais même pas comment ça se met en place ni rien, je préfère d'abord m'occuper de tout ce qui est module de prise de données puis après je m'occuperais de la partie RF, mais étant donné que j'apprends (oui tu as du le remarquer je suis pas un expert du PIC, ni de l’électronique en général) je pense qu'il vaut mieux que je fasse tranquilement étape par étape. Sauf bien sur si la parte RF va conditionner ce qui se trouve avant ?

[bobflux]

> Tous les modules dans une boite

OK donc pas besoin de bus "longue portée" style CAN, un I²C standard est très bien.

Il te faudra un uC qui gère l'I²C et peut devenir périphérique (donc esclave) I²C, pas juste maître, à toi de trouver le bon. Regarde le chapitre I²C dans les datasheets. Te prends pas la tête à faire de l'I²C en manipulant les IO en software... car combiné à des interruptions de timers etc, c'est pas l'idéal...

Le XXXX (comme dirait Tropique) qui est sur mon bureau dit ça : "Standard I2C-compliant bus interfaces may be configured as Master, Slave, or
Master/Slave."

> Sauf bien sur si la parte RF va conditionner ce qui se trouve avant ?

Ben disons qu'entre une liaison RS232 ou un Wifi, c'est pas le même niveau de complexité !

[verbalinsurection]

Oui je me doute pour la compléxité, moi je veux uste un simple RF qui va envoyer toute les 0.5 seconde mes différentes valeures avec une porté d'un km à peu près.

Ok, je vais regarder dans les datasheets
Le µc qui gère I2C peut être le même qui gère la partie RF ou il vaut mieux distinguer les 2 ?

[verbalinsurection]

Grrrr je n'arrive pas à utiliser correctement le mode compteur avec le timer0.
Pour les essais j'utilise un 16F690, les tests sont fait sous simulateur mais j'ai choisi ce µc car je l'ai sous le coude quand je passerais aux test grandeur nature.

Bref, j'initialise mon timer0 en compteur, et ça marche, il compte bien mais ma fréquence varie de 20 Hz à plus de 3000 Hz. Et là ça pose problème, dans les petites valeurs ça passe très bien mais dès que j'augmente un peu paf ! c'est le drame. Vu que le compteur boucle à 256, avec une fréquence trop elevé il y monte trop vite et en une seconde par exemple, il a déjà fait le tour. Mais si j'augmente trop le prescale, quand j'ai une petite fréquence, ce n'est pas assez précis. Alors qu'avec une interruption par front montant sur RA2 ça marche tip top (le code posté en première page). Mais j'aurais bien voulu utilisé le mode comptage, si j'ai bien pigé j'aurais pu :

Timer0 compte sur front montant une fréquence
Timer1 compte sur front montant une seconde fréquence
Timer2 compte une demi seconde et génère une interruption avec laquelle je récupère mes valeurs de compteur des 2 timer que je stock.

[bobflux]

2 solutions :

1- réalise qu'on est en 2011 et choisis un uC plus récent avec des timers 32 bits (ou au moins 16 bits)
2- mets une interruption sur l'overflow de ton compteur qui incrémente un autre compteur (en soft)

Mais bon, si ta fréquence ne dépasse pas les 3 kHz (chose que tu aurais dû préciser), tu n'as même pas besoin d'utiliser un compteur hardware, ni d'une interruption par signal, tu peux mettre un timer exécuté 10000 fois par seconde qui va vérifier l'état des entrées et compter les changements. Comme ça tu peux faire tes 30 mesures de fréquence avec un seul uC...

Si tu veux avoir une bonne précision dans les basses fréquences par contre, il vaut mieux mesurer la période plutôt que compter les impulsions.

[verbalinsurection]

Yep, désolé, j'avais pas précisé quelles étaient mes ordres de grandeur
Ok pour la mesure de période, je vais tester ça.
Merci encore

[verbalinsurection]

Juste une chose, pour mesurer la période, il faut utiliser le CCP en mode capture et lire au déclenchement la valeur du timer en utilisant ou non un prédiviseur sur le CCP. Je suis à l'ouest ou c'est ça ?

[bobflux]

Oui c'est ça (enfin normalement un mode capture stocke automatiquement la valeur capturée dans un registre à part pour pas mesurer la latence des interruptions avec).

[verbalinsurection]

Ok, je vais me lancer là dedans alors, à ce moemtn là, par exemple mon 16F690 pourra capturer 2 fréquence CCP1 et CCP2.
Je vais essayer de me faire à l'idée qu'on est en 2011 histoire d'avoir un pic un peu plus récent, mais déjà que je me perd avec les vieux...

En tout cas merci pour ton aide et ta patience

[RISC]

Salut,

Les unités CCP sont les plus adaptées à la mesure de période ou de largeur d'impulsion. Leur principal avantage est de fonctionner sans l'aide du micro (pour la capture) et d'être donc plus précis.
Si tu dois mesurer 2 fréquences (/périodes) 2 unités CCP feront très facilement le job, surtout pour les fréquences basses que tu utilises.

a+

[verbalinsurection]

Merci RISC
Juste une question, c'est quoi pour vous une frequence basse ? jusqu'à quel niveau on peut appeler ça une fréquence basse ?