Page 2 of 2

Re: Stack Overflow issue in GPIO Callback for Interrupt

Posted: Thu Jan 05, 2017 6:26 pm
by kolban
At a high level, I would probably suggest a FreeRTOS task that is blocked waiting for a message to arrive on a FreeRTOS queue. The messages that would arrive on the queue are going to be:

o button down event ... including the timestamp of when the button went down
o button up event ... including the timestamp of when the button went up

This task would be spawned and would be running asynchronously to your other tasks but normally it is blocked waiting on a queue and hence consuming minimal resources.

Your ISR associated with your GPIO will be triggered when the GPIO signal changes state. Within your ISR, you will post a new event to the message queue indicating the new button state and the time when the state transitioned ... and that is ALL that will be in the ISR.

Your button handling task will wake up when the events arrive and can process them in sequence ... for example ... if it sees a button down event, it records the time of that event. When it sees a button up event, it subtracts the last button down event time from the time of the current button up event ... and now we know the duration that the button was down and can perform activities as desired.

Re: Stack Overflow issue in GPIO Callback for Interrupt

Posted: Fri Jan 06, 2017 1:06 am
by WiFive
Ritesh wrote:
WiFive wrote:
Ritesh wrote:So, I can not use ESP_LOGI into interrupt callback function for any GPIO. Correct?
Yes, for any isr including gpio and other. Yes, try ets_printf
I have commented all debug print statements but still facing same issue.

Do you have any other idea or clue for this type of issue?
Calling xTaskCreate or any freertos function not ending in "fromISR" inside isr also not possible.

Using a queue is shown in example 21.