Some people are using m5stack for their projects, one question that I had since the beginning was how to dim my lcd brightness. For micropython you can use:
from machine import Pin, PWM
pwm2 = PWM(Pin(32), duty=40)
You can use a value other than 40.
Hope this is usefull to someone!
PS: use at you own risk
As far as I can tell, M5 is using the exact same technique for ther lobo-derived micropython fork. Their display class actually has a brightness method that uses PWM on the light pin.
I just checked the schematics, applying a PWM signal from pin 32 will dim the backlight leds. The circuit seems to be designed to be used that way.
One thing though: I found that when soft resetting the M5Stack, one has small issues with PWM. I actually have to do this:
backlightPwm = PWM(Pin(32))
backlightPwm.init(duty=128) # or any other duty
It seems that (like many other hardware things) PWM persists across soft-resets and the simple creation of a PWM object is insufficient to restart/reset the pulsation. This is quite logical, since a soft reset only resets microPython (and very few other ancilary items, like lvgl’s ILI9341). Thus the
init sequence. Since this seems to work, I did not investigate further…
I frequently see this MicroPython feature being brought up. Do you happen to know the reason for doing it this way? Is it for performance reasons?
- Soft-reset (ctrl-D in a REPL): restarts the microPython virual machine. Some cleanup can be done before that restart (the lvgl ili9341 driver does so). The chip is not restarted. Near instantaneous.
- Hard reset: reboots the microcontroller. On my machine with 4Mb PSRam that can take quite a few seconds.
When toying/developping, it is enough to restart the microPython engine in order to be able to import modules anew. My work cycle is:
- Import the test module I am working with from the REPL
- If there is an issue, edit, ctrl-D on the console and back to 1.
The biggest time consumer being the initial compilation when modules are imported. MicroPython does not save the bytecode. If I am satisfied with a module, I either cross-compile to create the bytecode or even freeze it in the firmware.
Thanks for the explanation. I can see why soft reset is valuable when hard reset takes so long in comparison (which is somewhat strange to me, coming from the STM32 world where I can reset the processor and be running an application in 0.5 seconds).
Here, the thing is that pesky PSRam that seems to be checked at every restart… Furthermore the RTOS takes time to start up…