-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Soft Reset, Reading Power Button Presses, LCD Power Off, Processor Sleep, Touch Interrupt, Dual Core Support. #129
Comments
One change I made just after posting this, was to turn on the pull up on the interrupt pin for the touch controller. `#define TOUCH_PANEL_INTERRUPT_PIN 39 void setup() void loop() |
@JasonPittenger Hello Jason! Thank you for your contributions !! This last one didn't work well for me: whenever the second core is operating, the keys of the screen stop responding. I even tried it with interrupts (FALLING and CHANGE modes) but this same issue persists. If anyone would like to test it with ISR:
|
It got a bit better after I configured the priority of the second core task to 0 instead of 2. |
I have not tried it using interrupts and I've always used core 0 task at priority 1. |
@JasonPittenger @Tinyu-Zhao |
@capedra when using dual core, you have to make sure not to share an interface across the cores. M5.update(); uses I2C to read from the touch controller. You must not use the same I2C bus on the other core, unless you have some sort of global variable to ensure exclusive access to the I2C bus. Otherwise what can happen is you could be in the middle of an I2C transaction on core 1 when core 0 starts reading from I2C. This will interrupt the core 1 read and corrupt the data. For my program, I make sure all I2C transactions are done on core 1. This is true for other interfaces as well, so all my UART transactions are done on core 0 and all SPI transactions are on core 1 as well. But if you want to use both cores, use something like this around every I2C transaction. It will wait for the bus to be available before reading. Then it will lock it out during the read so the other core has to wait. The timeout is there in case the variable gets out of sync and both cores are waiting on each other.
As for the power button, the datasheet says the time length can be changed, but I didn't see any way to disable it. I was working with a Google Translated version of the datasheet, so I might have missed it. Personally I wouldn't want to disable it, as it provides a hard power down if the software locks up. I do wish I could disable the physical reset button. |
Maybe this is a general feature request? You can file it in M5Unified. |
I wrote a few features that I thought might be useful to incorporate into this library.
Of course, modify the names and code as you see fit.
Soft Reset:
This allows a reset based on software rather than the physical reset button
Read Power Button Presses:
The chip that reads the power button has built in interrupts for detecting pressing or holding the power button.
I have used this to put the m5 to sleep with a short press, or soft power down with a long press.
The short press is anything less than 3 seconds.
The long press is 3+ seconds.
Of course, holding the button for ~7 seconds forces a hard power down.
LCD Power Off:
This completely turns off the LCD to reduce power usage.
The screen must be redrawn on power up.
LCD Power On:
The screen must be redrawn on power up.
Processor Sleep:
The sleep mode does not effect what's displayed on the LCD.
Touch Interrupt:
By default, the touch controller uses an interrupt whenever there is a touch detected.
I found the touch screen to be much more responsive if the interrupt pin is polled.
This goes it pin 39.
Whenever the pin is low, there is an unread touch.
Dual-Core Support:
Here is all that is needed to set up a main task loop on the 2nd core.
You need to set "Tools->Arduino Runs On: Core 1" and "Tools->Events Run On: Core 0" for this to work.
Also, interfaces like I2C cannot be accessed by both loops or there will be data corruption on the bus.
The text was updated successfully, but these errors were encountered: