Bienvenue aux nouveaux arrivants sur FantasPic !
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
- Pensez à lire les règles durant votre visite, il n'y en a pas beaucoup, mais encore faut-il les respecter .
- N’hésitez pas à faire des remarques et/ou suggestions sur le Forum, dans le but de l'améliorer et de rendre vos prochaines visites plus agréables.
- Vous pouvez regarder votre "panneau de l'utilisateur" afin de configurer vos préférences.
- Un passage par "l'utilisation du forum" est recommandé pour connaître les fonctionnalités du forum.
--- L’équipe FantasPic ---
Modérateur : Jérémy
Boucle pour compter les rebonds
Jérémy a écrit :En effet l'ASM est un langage très particulier . Loin de moi l'idée de dire qu'il est bon ou mauvais, c'est un langage de haut niveau très peu convivial et réservé et des personnes expérimentées.
Non et non et non.
On aura un résultat faux :
- les tensions inférieures au Vih ne seront pas prises en compte
- les pics durant 1 Tcy seront confondus en 1 seul
Boucle pour compter les rebonds
Le problème avec le C c'est qu'il existe plusieurs compilateurs pour Microchip avec des syntaxes différentes.
Il faudra donc que chacun maitrise son propre compilateur si le source vient d'un autre.
De plus le C est basé sur des datas sur une pile, ce que n'a pas la série 16f 18f etc...
Comme les data et le prog sont séparés certaines habitude de programmation deviennent impossibles...
La pile sera donc soft , et vu la taille minimum de la RAM, ça va être dur...
Le C génère normalement systématiquement un fichier minimum sur le TurboC il s'appelait C0.asm qui va prendre beaucoup de place pour un pic qui n'a que 1k de prog.
D'autre fonctions comme le printf sont assez gourmandes et un Pic16F84 risque de n'avoir 1 seule et unique ligne de programme printf qui prend son 1k de prog.
évidemment ça dépend du compilateur donc il faut tester.
Il faudra donc que chacun maitrise son propre compilateur si le source vient d'un autre.
De plus le C est basé sur des datas sur une pile, ce que n'a pas la série 16f 18f etc...
Comme les data et le prog sont séparés certaines habitude de programmation deviennent impossibles...
La pile sera donc soft , et vu la taille minimum de la RAM, ça va être dur...
Le C génère normalement systématiquement un fichier minimum sur le TurboC il s'appelait C0.asm qui va prendre beaucoup de place pour un pic qui n'a que 1k de prog.
D'autre fonctions comme le printf sont assez gourmandes et un Pic16F84 risque de n'avoir 1 seule et unique ligne de programme printf qui prend son 1k de prog.
évidemment ça dépend du compilateur donc il faut tester.
Boucle pour compter les rebonds
On aura un résultat faux :
oui , donc celles ci on s'en fou.
Si elles ne déclenchent rien.
oui et même plus , entre 2 tests dans mon exemple , il y a au moins 8 cycles pour un front.
et même avec l'interruption ça prendra le temps du traitement surement plus de 8 cycles
En C je n'ose pas y songer...
D'ailleurs le nombre de cycles ne pourra se compter qu'avec l'asm généré.
- les tensions inférieures au Vih ne seront pas prises en compte
oui , donc celles ci on s'en fou.
Si elles ne déclenchent rien.
- les pics durant 1 Tcy seront confondus en 1 seul
oui et même plus , entre 2 tests dans mon exemple , il y a au moins 8 cycles pour un front.
et même avec l'interruption ça prendra le temps du traitement surement plus de 8 cycles
En C je n'ose pas y songer...
D'ailleurs le nombre de cycles ne pourra se compter qu'avec l'asm généré.
Boucle pour compter les rebonds
-
Jérémy
Administrateur du site- Messages : 2723
- Âge : 45
- Enregistré en : juillet 2015
- Localisation : Dans le sud
- Contact :
En C je n'ose pas y songer...
D'ailleurs le nombre de cycles ne pourra se compter qu'avec l'asm généré.
Ok , donc d’après ce que j'ai cru comprendre , ce ne serait pas possible de comptabilisé cela .
Pas grave un oscillogramme fait tout aussi bien l'affaire . Merci d'avoir jeté un oeil en tout cas
Boucle pour compter les rebonds
Difficile de faire un comptage précis d'un phénomène aléatoire rapide.
En temps réel on est limité à la vitesse maximum de la boucle qui traite.
Ou si le phénomène est rapide avec un long temps d'attente à la vitesse de transition de l’interruption, sur un pic16F84 environ 50Mhz (voire l'application fréquencemètre)
Mais on peut le mettre en évidence.
Un prog mal conçu peut tout aussi faire l'affaire en prenant en compte plusieurs impulsions au lieu d'une, ça sera pas systématique , à moins d'avoir un bouton vraiment mauvais...
En temps réel on est limité à la vitesse maximum de la boucle qui traite.
Ou si le phénomène est rapide avec un long temps d'attente à la vitesse de transition de l’interruption, sur un pic16F84 environ 50Mhz (voire l'application fréquencemètre)
Mais on peut le mettre en évidence.
Un prog mal conçu peut tout aussi faire l'affaire en prenant en compte plusieurs impulsions au lieu d'une, ça sera pas systématique , à moins d'avoir un bouton vraiment mauvais...
Boucle pour compter les rebonds
Bonjour,
la gestion des appuis bouton est importante à comprendre, il y a plein de façons de considérer la chose.
Voici une liste non exhaustive mais qui rassemble les principales problématiques rencontrées:
-> l'appui est validé au relâchement du bouton
-> l'appui est validé dès l'appui du bouton (sur front montant ou descendant)
-> l'appui est validé après une durée prédéterminée
-> l'appui est mémorisé et sera utilisé ultérieurement lorsque la tâche principale sera disponible
-> l'appui est mémorisé et sera utilisé si un autre évènement survient, sinon il sera annulé
Tous ces cas peuvent être gérés par le software.
Lors d'un appui il survient une multitude de rebonds générés par plusieurs phénomènes, il n'y a pas de profil type, ces rebonds répondent et dépendent toujours des mêmes causes, leur nombres et leur durée varient selon :
-> souplesse/dureté du rappel mécanique
-> type de rappel mécanique (lamelle élastique ou ressort)
-> humidité relative
-> intensité du courant circulant (coupé/ouvert)
-> impédance de la ligne
-> la forme du contact (circulaire ou autres)
-> la résistance du contact
-> durée de vie du contact (la variation dans le temps de sa qualité)
-> profil du modèle de l'appui (force et manière dont l'appui est exercé)
Le choix doit se faire selon le résultat attendu, il n'y a pas une seule bonne méthode.
On peut avoir besoin d'une réactivité (type manette de jeu) ou que l'appui soit pris en compte lorsque l'utilisateur le décide au jugé, ou encore que l'appui soit enregistré (par exemple si une séquence est en cours et que l'on connait la prochaine question que l'on veut passer aussitôt le processus fini), ou encore faire un choix qui sera mémorisé et pris en compte si et seulement si le résultat qui est en cours peut présenter un résultat aléatoire ou de nature variable (par exemple si le résultat est VRAI alors l'appui sera pris en compte, si il est FAUX il sera ignoré)
la gestion des appuis bouton est importante à comprendre, il y a plein de façons de considérer la chose.
Voici une liste non exhaustive mais qui rassemble les principales problématiques rencontrées:
-> l'appui est validé au relâchement du bouton
-> l'appui est validé dès l'appui du bouton (sur front montant ou descendant)
-> l'appui est validé après une durée prédéterminée
-> l'appui est mémorisé et sera utilisé ultérieurement lorsque la tâche principale sera disponible
-> l'appui est mémorisé et sera utilisé si un autre évènement survient, sinon il sera annulé
Tous ces cas peuvent être gérés par le software.
Lors d'un appui il survient une multitude de rebonds générés par plusieurs phénomènes, il n'y a pas de profil type, ces rebonds répondent et dépendent toujours des mêmes causes, leur nombres et leur durée varient selon :
-> souplesse/dureté du rappel mécanique
-> type de rappel mécanique (lamelle élastique ou ressort)
-> humidité relative
-> intensité du courant circulant (coupé/ouvert)
-> impédance de la ligne
-> la forme du contact (circulaire ou autres)
-> la résistance du contact
-> durée de vie du contact (la variation dans le temps de sa qualité)
-> profil du modèle de l'appui (force et manière dont l'appui est exercé)
Le choix doit se faire selon le résultat attendu, il n'y a pas une seule bonne méthode.
On peut avoir besoin d'une réactivité (type manette de jeu) ou que l'appui soit pris en compte lorsque l'utilisateur le décide au jugé, ou encore que l'appui soit enregistré (par exemple si une séquence est en cours et que l'on connait la prochaine question que l'on veut passer aussitôt le processus fini), ou encore faire un choix qui sera mémorisé et pris en compte si et seulement si le résultat qui est en cours peut présenter un résultat aléatoire ou de nature variable (par exemple si le résultat est VRAI alors l'appui sera pris en compte, si il est FAUX il sera ignoré)
Boucle pour compter les rebonds
Un premier exemple:
appui sur front descendant, dès que le niveau bas est détecté l'appui est pris en compte immédiatement.
Pour éviter une nouvelle prise en compte l'interruption suivante est ignorée, ce temps de réactivation est paramétrable par une seule variable temps dans la fonction delay_ms().
Le code suivant est pour un PIC18F66K80, il peut être utilisé sur des PIC ayant les mêmes registres ou adapté facilement.
On peut améliorer ce programme en évitant le Delay_ms() et en utilisant un timer programmable.
Je n'ai pas testé ce code, si vous y voyez une coquille n'hésitez pas
appui sur front descendant, dès que le niveau bas est détecté l'appui est pris en compte immédiatement.
Pour éviter une nouvelle prise en compte l'interruption suivante est ignorée, ce temps de réactivation est paramétrable par une seule variable temps dans la fonction delay_ms().
Le code suivant est pour un PIC18F66K80, il peut être utilisé sur des PIC ayant les mêmes registres ou adapté facilement.
Code : Tout sélectionner
volatile char appui_bp = 0;
void interrupt(void)
{
if((INTCON3.INT1IF == 1 && INTCON3.INT1IE == 1) // Si un appui sur front descendant est détecté
{
INTCON3.INT1IE = 0; // On stoppe l'autorisation d'interruption
INTCON3.INT1IF = 0; // On efface le drapeau qui a été activé
appui_bp = !appui_bp; // On prend en compte l'appui pour libérer le processus qui sera traité dans la tache de fond (toggle 0 ou 1)
}
}
void main()
{
INTCON2.B7 = 0; // pull-up portB activé
WPUB.B1 = 1; // B.P. (Pull-up du bouton TEST activé -> RB1)
INTCON3.INT1IF = 0; // le drapeau d'interruption est initialisé à 0 prêt à détecter l'évènement d'appui
INTCON3.INT1IE = 1; // Interruption sur BP activée
PEIE_bit = 1; // Interruptions périphériques activés
GIE_bit = 1; // Interruptions globale activées
while(1)
{
if(appui_bp == 0) // On passe de ON à OFF
{
LATC0_bit = 0; // Led sur port C0 désactivée
led_RC0_active = 0;
asm sleep; // on passe en sleep par exemple si on ne veut plus rien faire, pour ne plus consommer, le compteur de programme s'arrête ici
// Si une nouvelle interruption survient on réveille le PIC et le compteur de programme reprend ici
while(appui_bp == 0); // Si une autre interruption BP survient on quittera cette condition, si c'est une interruption d'une autre nature on restera là
}
else if(appui_bp == 1 && led_RC0_active == 0) // On passe de OFF à ON
{
LATC0_bit = 1; // Led sur port C0 activée
led_RC0_active = 1;
}
Delay_ms(200); // On fixera ici la durée de la tempo souhaitée, durant 200ms par exemple ici aucune action BP ne sera validée
INTCON3.INT1IE = 1; // on autorise l'interruption BP de nouveau
} // end while
} // end main
On peut améliorer ce programme en évitant le Delay_ms() et en utilisant un timer programmable.
Je n'ai pas testé ce code, si vous y voyez une coquille n'hésitez pas
Qui est en ligne
Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 82 invités