I think it was discuss in the “delivery” topic of the picocalc… The global conclusion was “don’t use the pico USB when picocalc is started and batteries connected”.
I’ve tried some soft-switch for the stm32 to switch to flash mode, but didn’t work on this type of stm32 without making a custom made bootloader… Probably the best way to handle this issue, is to deport the DIP switch on the side/front-cover and use it like this, far less trouble. x)
As we already have the batteries inside the case, I wanted to use them to keep the stm32 RTC/RAM alive instead of modifying the hardware. This do the job perfectly! The only constraint is that the PMIC should be always keep on. But this only power the STM32, the pico and everything else is keep unpowered until the STM32 have been requested to wake-up things up.
But indeed, using coin-cell, if you’re not too fussy about hardware modifications, remove this constraint and allowing the PMIC to be fully shutoff.
I didn’t have the proper measuring instrument for the power consumption as it’s way too weak to see… (<10mA) So I can’t tell with precise numbers for now.
I see your point about the “SuperIO” feature! In the absolute, it’s possible. At least to drive the UART or getting an USB interface. But in the case of USB, goodbye to the drastic reduction of power! (having some macro to enable/disable this feature when building the firmware can be an option for who choose to have USB interface and the others who focus on a more low-power aspect.)
The good news by removing stm32duino is we recover between a half and a third of the flash memory, so yes, that gives us “a lot” of memory to work with. But the bad news is this “a lot” is only about ~30 KB.
I’ve seen some port of micropython on stm32f1 like this one (GitHub - morris13579/micropython-stm32f1: MicroPython board definition for the STM32F103ZET6 board) or this another one (GitHub - lupyuen/bluepill-micropython: STM32 Blue Pill libopencm3 port of MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems. Integrates with https://github.com/lupyuen/send_altitude_cocoos/tree/micropython).
I can’t see the binary size but I’ve the feeling it don’t fit in less than 30 KB.
And as you say, the STM32 only has one core, so using MicroPython will seriously impact the keyboard’s performance.
In the end, the co-processor idea will probably be so inefficient that there will be little point in having it do anything other than manage I/O.
If I may go into detail, the way in which the registers are managed internally means that the further we go in addressing, the more RAM/Flash we consume unnecessarily. That was what I primarily wanted to focus on.
But you right, keeping the official address untouch seem a good practice. In my case/firmware, some official registers have been rendered obsolete by the improvement/removal of features, the address of these registers may still exist, but will have no effect.
I’ve added a “TYPE-ID” register @0x00 address, value 0 in default on the official register, we can implement our value in it for the middleware on pico to know if it use the official firmware or not.
Thanks for helping the global direction!