[paulfjujo]

Bonjour Henri et à tous,



Au niveau du programme, on peut travailler
soit en mode pooling
on vient scruter les entrées à un rythme regulier via une tempo dans une boucle sans fin
ex: chaque mS ou 10mS à 50mS ... à 50mS on peut elaborer les differentes tempos de 500mS à 30000mS
pourquoi ces 6mS rajoutées sur le diagramme temporel ?
.. mais cela implique tout le traitement DANS le temps imparti de la boucle

Question:
Le delay des monostables sur entrées BP ,
Avec RC sera donc dans une certaine fourchette temporelle (precision du couple RC)
à voir avec la maxima de RC , < 0,5sec ?
sinon on peut avoir 60x0,6sec pour etre sur

TMR2 serait pluto basé sur 60x 0,5sec
de sorte à voir 60,59,58.. pluto que 30,29.5,29 ..
car compteurs sur entier ..
TMR1 idem basé sur 6x0,5sec 6,5,4,3,2,1,0

------------------------------------------------
sinon traitement via interruption..
2 evenements principaux à traiter sont
Push_RA7 .. on appuyé sur un BP
et RB0_DTMF OK .. on a reçu un code DTMF

question:
l'info RBO_DTMF OK apparait 0,5sec apres la reception des 4 bits DTMF
le code DTMF reçu est-il bien maintenu pendant 1 sec
de sorte à le lire sur le front montant de RB0

ton avis ?
Pooling ou Interruption ?
ou autre ?


exemple de config avec MCC

MPLABX_XC8_MCC_Pins_Config_18F27K42_DIP28_2022-0928.jpg

MPLABX_XC8_MCC_Pins_Manager_liste_18F27K42_DIP28_2022-0928.jpg

*.hex dans le zip

Portier_Audiophone_18F27K42_2022.zip

[Babar64]

Bonsoir Paul, et à tous,
Paul m'a devancé... avant que j'ai pu rectifier des erreurs, notamment de copier/coller, que j'ai relevées quand j'ai traité la 2ème partie...

Voilà le chronogramme corrigé, et complet, pour tous les contacts actionnés.

Séquences Actions Contacts (PIC).pdf

En relisant le datasheet du HT9170B, j'ai été amené à légèrement modifier le schéma (ajout potentiel de 2 composants au pin16 : EST)
De même, j'ai mis le cavalier Jp0 (Silent) au niveau de HP_Off : En l'ôtant, on pourra "entendre" les DTMF, ce qui sera pratique lors des tests.

Schéma V4.1.4 (EST) Portier Audiophone DTMF.pdf

Etape finale avant le soft : l'ordinogramme...
A+

[Babar64]

Suite aux questions posées par paulfjujo ...

Le delay des monostables sur entrées BP

Avec les valeurs choisies, c'est environ 1s.
Merci de me dire si selon vous c'est suffisant. Si non, je passe R à 220k pour environ 2s.

car compteurs sur entier ..

Est-ce à dire que la valeur affichée sera un entier, mais que l'on décomptera bien par pas d'une demi seconde? Si oui, pas de soucis.

évènements principaux à traiter sont
Push_RA7 .. on appuyé sur un BP
et RB0_DTMF OK .. on a reçu un code DTMF

Sans oublier les états des compteurs... A leur sujet, il y en a 3 :
> TMR0 : Il est déclenché par le front descendant de RA7_Push ; il gère le blocage du Bus à 0 via RB4_LockBus + le lancement de TMR1 sur la première demi seconde, puis le traitement DTMF sur la dernière demi seconde suivante.
> TMR1 : Il est déclenché par le dernier pas de TMR0 (dernière demi seconde) ; il gère les différentes activations des actions concernées, dont certaines sous condition, par pas d'une demi seconde (durée 3s)
> TMR2 : Il est déclenché par le deuxième pas de TMR1 pour certaines commandes ; il gère leur inhibition avec retour automatique au repos au bout de 30s.

l'info RBO_DTMF OK apparait 0,5sec après la réception des 4 bits DTMF

Sauf erreur de ma part, sur la datasheet, c'est 6ms après la validation donnée par la sortie RB3_DtmfEnb du PIC, à la condition bien sûr que les états en entrées D0 à D3 du HT9200B fournis par le CD40147 représentent un codage valide et soient toujours présents (avant le rebasculement RC/CD40106). Rappel : le HT9170B, lui, doit évidemment recevoir le DTMF valide fourni par le HT9200B, qu'il décode également en 6ms, si ses entrées sont OE=1, INH=0 et PWDN=0 (via RB3_DtmfEnb=0).

ton avis ? Pooling ou Interruption ?

A mons sens : Interrutions

En espérant que je sois clair... et que mon chronogramme le soit aussi.
A+

[paulfjujo]

bonjour à tous ,

y a pas foule .... pour discuter sur ce sujet

Merci de me dire si selon vous c'est suffisant.

.. me parait largement suffisant .. MCU : 16 000 000 cycles / seconde

.

car compteurs sur entier .....Est-ce à dire que la valeur affichée sera un entier
..., mais que l'on décomptera bien par pas d'une demi seconde?

Sans oublier les états des compteurs...

En Entier:
Gerer un flottant 3.0 , 2.5... est trop dispendieux pour un MCU
et les comparaisons peuvent être difficiles 2.4999999 n'est pas égal à 2.500000
vu qu'un flottant n'est pas une valeur finie (mantisse , exposant)
c'est pourquoi on raisonne plutot en entier .( ici 16 bits non signes 0 à 65535 )

2 compteurs suffisent
1 timer principal 16 bits ( TMR0 ou TMR1] basé sur 100mS
( voir 10mS si necessite une precision temporelle plus grande ?? le maxima possible etant 655 sec )
on passe dans l'interruption toutes les 100 mS
dans l'interrupt on peut gérer plusieurs compteurs ou decompteurs
ex : décompteur de 300 à 0 pour décompte de 30sec à 0 par pas de 100mS
La valeur du décompteur servant de branchement conditionnel dans le corps du programme

eventuellemet un 2em compteur Timer4 basé sur 500mS
pour des tempos de 0,5 à 3sec (comptage 0 à 6 )
* mais on pourrait aussi se servir du timer principal avec un autre compteur dédié pour.

évènements principaux à traiter via interruptions :

* Push_RA7 .. on appuyé sur un BP

genere une interruption INT1 (sur RA7), dans l'interrupt on peut Armer un flag
pour gerer les differents etapes en fonction de la valeur du compteur

* interruption sur RB0 .INT0 ....si on a reçu un code DTMF OK
Traitement de la valeur reçue dans l'interrupt
et aiguillage programme dans la bonne etape.

*Interruption Timer1
Decompteur_30s

*interruption Timer4
Decompteur_3s
pourquoi ce choix sur le timer4 .. et pas Timer2 ?
parce que le Timer2 est souvent associé, par défaut , à d'autres fonctionnalités du PIC
ex: PWM, timeout UART ....

* interrupt UART RX ( provisoire)
La saisie Clavier , pour simuler des conditions ...
exemple simuler un code DTMF ( ex: remplacer les entrees PIC RC0..RC3)
La sortie UART sera utilisée pour le suivi/traçage programme ,surtout pendant la phase de test
et etre inhibée par la suite via une programmation conditionnelle ( #ifdef With_UART ...#endif .

Le principe de base est de gérer les évenements par interruption
mais faire le traitement de celle ci, en dehors de l'interruption .
surtout si la durée du traitement peut masquer une autre interrupt
ou decaler un autre evenement qausi simultané dans le temps..

En espérant que je sois clair... et que mon chronogramme le soit aussi.

pas encore vu ...à cet instant


A+[/quote]

[Babar64]

Bonsoir à tous,

Merci paulfjujo pour ces remarques, et ... pour le logiciel que tu utilises pour tes "ordinogrammes" : cala m'a fait gagner beaucoup de temps

Le voici, au format A3 (portrait) :

Ordinogramme.pdf

Je remets ici le Chronogramme déjà donné (Séquences) :

Chronogramme.xls

...Car vous aurez certainement des commentaires sur ces 2 fichiers, sur la base desquels le code va (enfin) pouvoir être entrepris.

A+

[paulfjujo]

bonjour,



Hardware :
Preampli micro t11 r57=100k ,sur cellule RC filtrage alim, est trop grande ,
la tension VCE risque d'etre trop faible, R57 -> 1k à 3.3k

l'info RB1 etat bus, notée RB4 etat bus sur le chronogramme xls


EVENEMENTS sur Entrées PIC
RB0 .. interrupt pour valider la lecture DTMF
deroute la boucle principale du programme du PIC Recepteur
pour lecture etat RC0..RC3 code DTMF
verifier si le code est valide
agir en consequence
RB0 .. interrupt coté PIC Emetteur qui s'auto ecoute
a part verifier si c'est un code valide
que faire .. HP mute,Micro Mute

RC5 choix H ou S.. lue 1 seule fois, en debut de programme => indirection d'application
permet de differencier les actions programmées coté HOME ou coté STREET

RA7 .. interrupt : detection appui sur un des BP
... deroute la boucle principale du PIC emeteur de code DTMF

RB1 Etat bus .. en principe reflete l'etat d'une commande RB4 Lock Bus
de la part de Home ou STREET
la commande RB4 lock etant issue de l'interruption sur RA7 ..
qui declenche le cycle d'envoi code DTMF ( et autoecoute)
On peut savoir quel est le PIC iniateur: si l'initiation (appui BP)
vient de son coté ou du coté distant en comparant RB4 et RB1
Rappel : car Aucun BP n'est directement relié aux entrees PIC



Timer2 Timeout de 30 sec -> repos
Q:
Est-ce que toute commande DTMF ,reçue et validée OK
ne doit pouvoir s'executer qu'une seule fois dans un gap temporel de 30sec maxi ?
Apres Tempo de 3 sec ( Tempo 30,29,28,27..) la commande DTMF acceptée par le PIC doit etre exécutée.
...2,1,0 => REPOS (boucle principale)

Q:
je pense qu'on met alors le BUS à ZERO ..jusqu'à la fin de Timer2
ou est-ce qu'on suspend / inhibe simplement l'interrupt jusqu'à la fin du Timer2 ?

Q:
Une commande DTMF est unilaterale ..
pas de commande dans l'autre sens ,tant que le timeout 30sec n'est pas atteint ?

Le programme principal ,qui est la plupart du temps dans une boucle d'attente
ne peut donc reagir que sur un des 2 evenements interrupts
Le PIC n'ayant pas grand chose à faire
-> REPOS = boucle d'attente ?

remarque :
il n'y a pas de led "bit de vie" montrant que le programme PIC est actif ( tourne)..
si rajout d'une led sur RC6 avec pull up de 4,7K
par defaut, L'UART pourrait envoyer un message (toutes les 1 à 10sec) contenant
aussi une serie de 0xFF histoire de faire briller cette led. ( data 11111111 donne 00000000 sur RC6 ..)
sans avoir à connecter un terminal ou un HC06
L'UART pourra etre utilisé de toute façon au demarrage pour donner un minimum d'indications
HOME ou STREET, version de programme..etc..
et pendant la phase de deverminage programme.

dans ton Ordinogramme, on ne voit pas la notion de bouclage ou branchement vers ..
chaque action terminée doit revenir ensuite dans une boucle d'attente du programme principal

Je pense que le chronogramme est suffisant pour "connaitre" le deroulement de chaque action.
Le plus delicat est de pouvoir représenter l'enchainement de ces sequences d'actions
pour pouvoir les transposer en programme.
A verifier aussi , si il y a des notions de priorité à respecter.

à suivre...

[Babar64]

Bonsoir à tous,
Paulfjujo est toujours aussi vigilant!

R57 -> 1k à 3.3k

OK, je croyais l'avoir déjà corrigé (3.3k)

l'info RB1_EtatBus, notée RB4_EtatBus sur le chronogramme xls

C'est rectifié

RB1_Etat bus .. en principe reflète l'état d'une commande RB4_LockBus

Oui et non: le niveau en RB1_EtatBus reflète l'état DU BUS, provoqué par RB4_LockBus (émetteur), mais aussi VU par le PIC opposé.
RB4_LockBus sert donc à "transcrire" l'action sur un poussoir (RA7_Push) en mettant le Bus à zéro via T0 (pendant une demi seconde).Le niveau en RB1_EtatBus, lui, est commun au 2 Pics, puisque directement issu du Bus via D12

RB0 .. interrupt coté PIC Emetteur qui s'auto écoute, à part vérifier si c'est un code valide, que faire...

Tout dépend de la commande correspondante au code : Si c'est "RING" (STREET) le Pic STREET devra aussi gérer le DingDong via "son" RB2_Ring (T12/M8031) ; si c'est "Décroché" (HOME), le Pic HOME devra aussi gérer le relais via "son" RB5_RLcmb (T13/RL). En "s'auto-écoutant" chaque PIC gère aussi certaines actions associées à TMR2.

Est-ce que toute commande DTMF ,reçue et validée OK, ne doit pouvoir s'exécuter qu'une seule fois dans un gap temporel de 30sec maxi ?

Non, pas toutes : seulement RING, Open1, Open2 avec un gap de 30s MINI. Rappel : l'anti-rebond est de facto assuré par les cellules RC des contacts sur 1s.

on met alors le BUS à ZERO ..jusqu'à la fin de Timer2

Non. Le Bus à zéro est géré uniquement par le Timer0 : il est à zéro uniquement sur la première demi seconde (RB1_LockBus=1)

pas de commande dans l'autre sens ,tant que le timeout 30sec n'est pas atteint ?

Ben si... sinon, il faudrait attendre 30s pour entrer en conversation avec un appelant. Là tu as mis le doigt dans la crème... Je vais revoir ma cuisine plus en détail.

-> REPOS = boucle d'attente ?

Oui.

rajout d'une led sur RC6 avec pull up de 4,7K

ça marche

on ne voit pas la notion de bouclage.

Effectivement, il reste des "impasses" et des "boucles ouvertes"... que je n'ai pas traitées "au propre". Et hop! Je replonge dans mes brouillons.

Le plus délicat est de pouvoir représenter l'enchainement des séquences d'actions pour pouvoir les transposer en programme.

.A+

[paulfjujo]

Hello Fantaspiciens !

Generation signaux DTMF :
A priori 9 tables DTMF seraient suffisantes pour l'application Portier... ce qui laisse la place pour suffisament de code ...
Le PIC pourrait donc gérer ces frequences DTMF
en fonction des Entrees 4x B.P.et des 2 etats :combiné,lettre

la problematique se porte alors sur le Hardware , plus assez d'entrees PIC
les 6 infos commandes devant alors etre connectée directement sur le PIC
l'info RA7 devient inutile.. remplacée par sortie DTMF emission vers le Bus audio
mais il en manquera encore !
une solution alternative : un MCP23017 extenseur d'entree sortie sur le bus I2C RC3 RC4
on perd 2 pins (I2C) on en gagne 16 ....
le PCF8754 en DIP16 pourrait aussi suffire .. 8E supplementaires - 2 => gain de 6 entrees
en resumé: remplacement de 3 circuits CD41016,CD41017,HT9200B...diodes, resist.. condos par un PCF8754 (si avéré suffisant)

une autre solution, sans rajouter un extenseur .. PIC18F47K42 ..le meme, mais en DIP40 .. rajout du port D (8 pins) + 3 pin Port E

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

DECODAGE DTMF
Reste aussi à (pouvoir) faire la partie Decodage ...
on trouve certains morceaux de code asm ou C sur le Web
mais le plus difficile est de comprendre l'alogorithm Gortzel generalement utilisé..

http://www.t-es-t.hu/download/microchip/an257a.pdf
DTMF Detection Using PIC18 Microcontrollers
AN257
Frequency Requirements
The DTMF frequency requirements are specified as:
• Maximum accepted frequency offset: 3.5%
• Minimum rejected frequency offset: 1.5%
If one or both of the DTMF frequencies are outside the
±3.5% range of the nominal frequency, then the detector should reject it. If both of the DTMF frequencies are
within the ±1.5% range of the nominal frequency, then
the detector should accept them.

beaucoup d'exemples utilisent des PIC24 ou TMS32 bits
mais aussi, à contrario
des petits PIC ( je ne pense pas qu'ils puissent faire autre chose en plus !)

https://pe1grl.khds.nl/dtmf/dtmf.htm
DTMF Decoding Software with a PIC 12F629 ou 675
dtmflock.png
dtmflock.asm
Include: tables.asm
Hex file: dtmflock.hex
----
8 Channel DMTF Remote Control Unit
Source: dmtf_8c.asm
Include: rxtables.asm

je n'ai pas ces 2 pic pour faire des tests ...
à moins de le transposer directement en 18F27K42 ..
car en ASM , on a notre Joker TempsX .

l'asm , pas pour moi ... j'ai suffisament à faire entre MikroC et XC8
(et on peut toujours encapsuler de l'ASM dans le C ..mais pas le contraire )

Sinon ,en dernier recours ,il restera le DECODER Hardware.

Qu'en pense la communauté Fantaspic ?

A+

[Temps-x]

Bonsoir paulfjujo, Babar64, et tout le forum,

Source du message PIC18F47K42 ..le meme, mais en DIP4

Il y a aussi le PIC18F57K42, qui est le même, mais en 48 pattes, en version TQFP ou UQFN

Source du message l'asm , pas pour moi ... j'ai suffisament à faire entre MikroC et XC8
(et on peut toujours encapsuler de l'ASM dans le C ..mais pas le contraire )

C'est normal car MikroC et XC8 son déjà encapsulé dans de l'asm

J'ai trouvé en Visual Basic une routine pour décodage de 2 fréquences, et même plus, bref ça m'intéresser beaucoup, j'ai récupéré pas mal de documentation dessus, donc il y a une grande possibilité que je fasse une routine pour décodage Dmtf

Pour l'instant je finis ma routine pour faire un cercle avec l'algorithme de Bresenham, après je reviens sur Dtmf (j'en ai pas fini avec lui)

Source du message mais le plus difficile est de comprendre l'alogorithm Gortzel generalement utilisé..

A+

[paulfjujo]

Bonjour,

juste pour 'remember it '
version generateur DTMF tres simplifiée et light en taille de code ,surautre fil
allez, maintenant passons à la reception Decodage DTMF...
A+