LoRa Reception Blocking Button Detection #57
-
I am currently using a heltec wireless stick V3 and a heltec wifi 32 V3 to create a basic system that takes measurements of humidity and temperature via a DHT22 temp/hum sensor connected to the wireless stick, and sends the measurements to the wifi32 board via LoRa transmission. The receiving board then displays the measurements on the OLED along with a battery % and indicator and a Bluetooth connection indicator. I am trying to use the PRG button to allow the display to switch between Fahrenheit and Celsius measurements on the OLED. I am facing an issue of LoRa reception process blocking the reading of the button presses. I have tried implementing the Lora reception on the wifi32 board in a "non-blocking" way but I have had little success here. Initially it was only registering 1 out of 100 button clicks. I then implemented the heltec_delay() function for 5 seconds at the end of the main loop and had some success with it then being detected 7 out of 10 times which is better but isn't good enough. Plus, due to the delay implementation in the loop, it allows for the detection of the presses but the change from Fahrenheit to Celsius is delayed until the loop runs again after the full delay. If I have no delay the button presses really dont read at all. I can share my code if need be but has anyone had any experience with this board and the issue I have described? The one thing I haven't tried but I believe may work would be using a process interruption on the button pin but with this I would need to write my own handling of the PRG button instead of using the Hot Button library which is great and already ready to use. I was hoping someone know something I don`t. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Running in a single task and not using interrupts, there's nothing my code can do until RadioLib returns. Here's some ideas and pointers to solve your problem. Note that I haven't tried any of this, this is just off the top of my head, based on things that have broadly worked for me in other projects on the ESP32. Multiple tasks In the same source file, you could create one task, in one function, to do the screen and button, and another task in another function, to do the rest. These tasks can communicate via global variables, which you would want to define as Here is a tutorial that describes how to implement multiple tasks. You can run both tasks on the same core as they're both not generating heavy load. As you can see it's not completely trivial, but this should work. Interrupts Here is a tutorial about GPIO interrupts, and you could have a bit of code run when the button is pressed. Note that you do not want to do IO or anything tht might take a moment in the ISR (Interrupt Service Routine), as that will cause the system to crash. So that means you can't write to the screen, all you could do is set a variable that you then read when RadioLib returns to change the unit. You won't miss clicks, but it's not going to feel responsive either. So my gut feeling is you'll be happier with two tasks.
Please post here with minimal code example if you work it out, might help other people. |
Beta Was this translation helpful? Give feedback.
Running in a single task and not using interrupts, there's nothing my code can do until RadioLib returns. Here's some ideas and pointers to solve your problem. Note that I haven't tried any of this, this is just off the top of my head, based on things that have broadly worked for me in other projects on the ESP32.
Multiple tasks
In the same source file, you could create one task, in one function, to do the screen and button, and another task in another function, to do the rest. These tasks can communicate via global variables, which you would want to define as
volatile
to make sure the compiler understands that the value might change outside of the current code flow. (Otherwise, a loop th…