Skip to content

Conversation

@cparata
Copy link
Contributor

@cparata cparata commented Dec 4, 2020

Hi Frederic,
I reopened this PR referring on the new branch that I created on my fork to test it in a clean way.
Best Regards,
Carlo

@fpistm
Copy link
Member

fpistm commented Dec 4, 2020

For ref #1168

@fpistm fpistm added enhancement New feature or request New feature labels Dec 4, 2020
@fpistm fpistm requested a review from ABOSTM December 4, 2020 14:10
@ABOSTM
Copy link
Contributor

ABOSTM commented Dec 8, 2020

Hi @cparata,
I had in mind (according to #1168 discussion) that we go toward a symmetric approach, meaning that
in stm32_interrupt_disable() we should disable EXTI too (in addition to NVIC).
And instead of calling HAL_GPIO_DeInit()/HAL_GPIO_Init() to keep GPIO mode,
I suggested to use LL EXTI API (even if EXTI API was not directly used in stm32_interrupt_enable(), it is used indirectly in HAL_GPIO_Init(), thus no symmetric break).

@fpistm fpistm marked this pull request as draft December 12, 2020 07:03
@cparata
Copy link
Contributor Author

cparata commented Dec 14, 2020

Hi @ABOSTM ,
in fact, this is what I would like to test. I will update the PR asap I have the opportunity to implement the stm32_interrupt_disable() with the LL HAL.
Best Regards,
Carlo

@cparata
Copy link
Contributor Author

cparata commented Dec 14, 2020

My only concern about the usage of LL HAL is portability. It is not said that LL HAL is available for all STM32 families; this is the reason why I suggested the usage of the HAL_DeInit that instead should be available for all STM32 families.

@cparata
Copy link
Contributor Author

cparata commented Dec 14, 2020

Hi all,
I remanaged the PR, modifying only the "stm32_interrupt_disable". I implemented it using the gpio DeInit because I guess it is the simplest way to do it and it is also the most portable. Let me know if you have any comment. Unfortunately, I cannot test it with motor driver until Wednesday, when I will be in the office.
Best Regards,
Carlo

@cparata
Copy link
Contributor Author

cparata commented Dec 16, 2020

I was able to test the new PR with the motor driver and it works as expected on my side. So, for me this implementation is functional.

Copy link
Contributor

@ABOSTM ABOSTM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Carlo,
Thanks for this PR,
I feel like this is quite heavy to simply disable exti.
I wonder whether we could make that simpler:

  • either with LL, using directly LL_EXTI_DisableIT_0_31()
  • or with HAL, using HAL_EXTI_GetConfigLine(), changing EXTI mode to EXTI_MODE_NONE and HAL_EXTI_SetConfigLine()
    Note: this way we keep pin configuration (no resore of default input mode) and simply disable exti.
    What do you think ?

@cparata
Copy link
Contributor Author

cparata commented Dec 17, 2020

Hi @ABOSTM ,
I'm not really expert on LL APIs. Unfortunately, at the moment I do not have band to investigate better on this topic. Anyway, from the testing that I did, it is sure that if we are able to reset in some way the EXTI settings during the stm32_interrupt_disable(), the issue that I see on motor driver will be solved. So, if you are able to find a more efficient way to do that, it is fine for me as well.
Best Regards,
Carlo

@battosai30
Copy link

Hi guys,

I was meeting troubles with a STM32L072 just trying to use interrupt with a button generating some rebonds and I found this PR. I applied modifications but it's not enough for me. I had to add __HAL_GPIO_EXTI_CLEAR_IT() in order to get the expected behaviour.

My (working) code :

const int butPpin = PA1;
volatile byte flag = 0;
volatile byte flag2 = 0;
volatile int count = 0;


void setup() {

  Serial.begin(115200);
  while (!Serial);
  delay(500);
  pinMode(butPpin, INPUT_PULLUP);

  attachInterrupt(digitalPinToInterrupt(butPpin), intInt, FALLING);

}

void loop() {

  if (flag) {

    flag = 0;
    Serial.println("ping ! ");
    Serial.println(count);
    delay(1000);

    attachInterrupt(digitalPinToInterrupt(butPpin), intInt, FALLING);

  }

}


void intInt()
{

  detachInterrupt(digitalPinToInterrupt(butPpin));

  __HAL_GPIO_EXTI_CLEAR_IT(butPpin);
  flag = 1;
  count++;
}

If __HAL_GPIO_EXTI_CLEAR_IT(butPpin); is commented, I get an extra interrupt

@cparata
Copy link
Contributor Author

cparata commented Mar 24, 2021

Hi @battosai30 ,
actually for debouncing it is not needed to use this API. You can try something like this:

const int butPpin = PA1;
volatile byte flag = 0;
int count = 0;
int PushButtonState = 0;


void setup() {

  Serial.begin(115200);
  while (!Serial);
  delay(500);
  pinMode(butPpin, INPUT);

  /* Check what is the Push Button State when the button is not pressed. It can change across families */
  PushButtonState = (digitalRead(butPpin)) ?  0 : 1;

  attachInterrupt(digitalPinToInterrupt(butPpin), intInt, FALLING);

}

void loop() {

  if (flag) {
    /* Debouncing */
    delay(50);

    /* Wait until the button is released */
    while ((digitalRead( butPpin) == PushButtonState));

    /* Debouncing */
    delay(50);

    count++;
    /* Reset Interrupt flag */
    flag = 0;
    Serial.println("ping ! ");
    Serial.println(count);
  }

}


void intInt()
{
  flag = 1;
}

Let me know if it works on your side.
Basically, it is normal to have debouncing when the button is pushed and when the button is released. In order to filter these events, you need to put a delay just after the first interrupt trigger and just after the release event. In this way, obviously the ISR is called several times, but you should enter into the check block just once.
Best Regards,
Carlo

@battosai30
Copy link

Thanks for your reply :)

Yeah it could be a solution but as I'm designing a very low power device, spend 100ms just for debounce is a pretty big waste ... And it's not the behaviour you usually get in Arduino environnement so ...

@fpistm
Copy link
Member

fpistm commented Dec 20, 2021

I close this one as it is superseded bu #1602

@fpistm fpistm closed this Dec 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants