Interruption de front montant se déclenchant plusieurs fois sur STM32 Nucleo

Le rebond mécanique des commutateurs est une caractéristique de tous les commutateurs mécaniques dans une moindre ou plus grande mesure. Il est souvent nécessaire de mettre en œuvre un «anti-rebond» dans le logiciel surtout si le commutateur pilote directement une interruption comme dans ce cas.

Une recherche rapide sur Google des techniques de dénonciation des logiciels donne des techniques plutôt médiocres de l'OMI. Je l'ai vu mal plus que bien malheureusement.

Je suggère que dans le commutateur ISR vous démarrez (ou redémarrez en cas de "rebond") une minuterie matérielle pendant une période de disons 20 ms environ (plus longue que le temps de rebond du commutateur, mais plus courte que le temps que vous pourriez peut-être réellement relâchez l'interrupteur). Ensuite, dans la minuterie ISR, vous testez l'état du commutateur et changez la fréquence en conséquence:

Pseudocode:

void debounceTimerISR()
{
    debounceTimerStop() ;

    static tDirection previous_dir = CENTRE ;
    tDirection dir = getJoystickDir() ;

    // If the state changed...
    if( previous_dir != dir )
    {
        previous_dir = dir ;

        switch( dir )
        {
            case UP :
            {
                increaseFrquency() ;
            }
            break ;

            case DN :
            {
                decreaseFrquency() ;
            }
            break ;
        }
    }
}

Ce que cela fait, c'est déclencher une interruption de la minuterie peu de temps ("temps anti-rebond") après que le commutateur cesse de rebondir. Notez que le chronomètre n'est pas périodique.

Ci-dessous, je présente une amélioration à la suggestion de @ BenVoigt (dans les commentaires). Je le garde séparément pour qu'il soit clair que c'était son travail. Ce qui précède fonctionnera généralement, mais si vous avez un commutateur particulièrement médiocre, ce qui suit résoudra les problèmes, et à peu de frais, vous pouvez donc aussi:

void upISR()
{
    debounceTimerRestart() ;
}

void downISR()
{
    debounceTimerRestart() ;
}

void debounceTimerISR()
{
    debounceTimerStop() ;

    tDirection dir = getJoystickDir() ;
    swithc( dir )
    {
        case UP :
        {
            increaseFrquency() ;
        }
        break ;

        case DN :
        {
            decreaseFrquency() ;
        }
        break ;
    }
}

Nous pensons clairement que c'est le rebond normal et attendu du commutateur. Mécaniquement, un interrupteur est un morceau de métal qui, lorsqu'il est actionné, déplace ce métal d'un pôle à un autre, même s'il ne ressemble pas à un essuie-glace et à deux pôles. Le métal qui bouge va entrer en collision et rebondir, la connexion électrique le montrera. Le rebond est souvent assez lent pour qu'un processeur reçoive plusieurs interruptions, bien que cela puisse être un sous-échantillonnage de tous les rebonds éventuellement vus électriquement. Si vous essayez de le regarder sur une lunette, la lunette elle-même peut ne pas en filtrer intentionnellement une partie (mais votre puce aussi).

Une façon de voir le problème est, comme pour tout, de rechercher d'abord, puis d'écrire l'application plus tard. Ce n'est pas une solution mais un moyen de caractériser le problème de votre système

switch_isr ( void )
{
    ...
    some_global_variable <<= 1;
    some_global_variable |= (pin_state_register>>pin_number)&1;
    ...
}

main ( void )
{
...
some_local_variable = 0;
while(1)
{
   if(some_local_variable != some_global_variable)
   {
       some_local_variable = some_global_variable;
       primitive_hex_print(some_local_variable);
   }
}
}

Aucune raison de vous attendre à voir chaque changement d'état dans la variable décalée, mais vous devriez en voir quelques-uns et avoir une idée du problème. Une autre façon consiste simplement à avoir un incrément de compteur à chaque interruption, à imprimer périodiquement au premier plan et vous verrez qu'une pression sur un bouton peut entraîner plusieurs comptes. Et à partir du temps qu'il faut aux impressions pour arrêter de changer approximativement en temps humain, le temps de stabilisation.

Le filtrage concerne les changements d'état par unité de temps et vous devez avoir une certaine idée du temps, que ce soit une boucle au premier plan qui interroge certaines informations définies par l'interruption (compteurs haut / bas, etc.), ou des changements d'état par rapport à un minuterie / horloge.

Je ne sais pas quelles sont les règles complètes de votre affectation, si vous ne pouvez avoir qu'une interruption pour chaque commutateur et non une minuterie, ou de préférence une minuterie à la place, je ne vois pas de solution propre qui fonctionnera réellement. Vous auriez à filtrer au premier plan, mais tout ce que vous faites est d'interroger une copie de l'état de la broche collecté par l'interruption et est-ce différent de ne pas utiliser l'interruption? Vous ne pouvez pas utiliser la réponse de Clifford si vous ne pouvez pas définir une interruption de minuterie, si vous pouvez utiliser une minuterie et une interruption, vous pouvez simplement échantillonner périodiquement les états du commutateur avec cette interruption ou une copie de l'état de la broche collectée par les interruptions de changement d'état de la broche et le filtre. dans l'interruption de la minuterie. Pas la même chose que celle de Clifford, mais dans tous les cas, vous avez besoin d'un historique des changements d'état par rapport au temps pour voir quand la chose s'installe.

Sans une référence de temps et des états qui ne changent pas par rapport au temps (qu'une interruption de broche ne peut pas afficher puisque l'état n'a pas changé), vous ne pouvez pas filtrer les rebonds. Au lieu de cela, travaillez sur votre dextérité et la façon dont vous actionnez le joystick de haut en bas.

Simple, n'utilisez pas EXTI pour les touches et les boutons mécaniques.

Utilisez une interruption régulière (par exemple systick) pour interroger l'état des broches.