Ok so, who wants to make the repo for this? I have no problem throwing it on my github but I’m very very new at kernal / bios programming. I threw the suggestion in another post here to make a list of things to add & work on them elsewhere etc.. I can start a spreadsheet / google doc & open it to the public for adding suggestions for ease on whoever or whomever decides to take on this project.
@JackCarterSmith already has his code up on his personal git server, and there’s a github mirror (both linked in the third post in this thread). Just fork the github repo and work from there; all the issues and pull-requests can be handled from there too, although discussion is probably best kept here.
2 Likes
Noted. Just forked it, will mess around with it in the following days.
Ok, it is safe? Awesome! How can we advertise this to the community? It is buried here.
2 Likes
I’d like to gather here for easier chatting to be frank with you. M57 Discord-Dev Server
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!
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.
If we only hook up VBAT but leave stm32 unpowered, I think the current draw should be uA level.
… It’s tempting to directly hook VBAT to 18650 cells as @pkr did for uConsole.
I needed the PMIC up to do the wake-up feature I forgot to precise!
If the PMIC is off, yes the RTC should work but can’t wake the pico as the stm32 can’t drive the ON pin of the PMIC.
2 Likes
Assume 3000x2=6000mAh battery and 10mA (3.3V) current draw, we will get over 600 hours standby time, which is.. not bad, right?
Further, if stm32 is in deep sleep (even with RTC powered), the current draw should be <= 1mA if we’ve done everything right!
FYI: STM32 Deep Sleep (Low Power Sleep) Mode & Wakeup
Edit: wait… the low power run mode is already <1 mA now. stm32 continues to run, only with a clock rate lower than 2Mhz.
– Isn’t that enough for a keyboard??
1 Like
In running mode, I’ve got 3.5 mA from the simulation from the ST tool.
And in the STOP mode (the one I used) I should got something around 25 µA…So ~300 000 hours if we doesn’t take in consideration self-discharge, temperature, cells balancing/quality, etc.
With informations of the AXP2101 datasheet, add ~50 µA, so something less than 100 µA in total for my configuration (pico off, PMIC on, RTC alive).
2 MHz clock mess-up with the PWM signal for the backlight, I need 4 MHz at least to fully use the timer range. But 2 MHz should work too, just the backlight can have a visible “blink” or a larger step between brightness.
And 3.5 mA at 4 MHz is already a big deal compared to 50 mA from the default 16 MHz.
Also notice that for using the USB interface of the STM32, you need at least 8 MHz and the PLL (who should add some mA).
1 Like
The proper way to handle the power path for the RTC is to connect either the main batteries or a coin cell to Vbackup on the PMIC, and then connect Vrtc from the PMIC to VBAT on the STM32. That provides constant power to the stm32 rtc, either from main system power or from the coin cell if the main power is missing.
Unfortunately it’s really not feasible to do that mod. The PMIC is a QFN so getting to Vbackup/Vrtc is basically impossible, and VBAT on the STM32 was incorrectly tied to MCU_3v3, requiring lifting that pin. Boo. You can ignore the PMIC and connect a coin cell directly to VBAT (or to the main battery, but a coin cell is safer), but you’re still stuck having to lift that pin.
At worst the register cache can only take up 256 bytes (if the entire register space is used), which is a pretty trifling amount of RAM these days, even on the F103. But it’s not the only way to handle the i2c comms; you don’t actually need a register cache at all. But it’s easier if I provide a patch 
Unfortunately it’s really not feasible to do that mod. The PMIC is a QFN so getting to Vbackup/Vrtc is basically impossible, and VBAT on the STM32 was incorrectly tied to MCU_3v3, requiring lifting that pin. Boo. You can ignore the PMIC and connect a coin cell directly to VBAT (or to the main battery, but a coin cell is safer), but you’re still stuck having to lift that pin.
Nope. Just scratch through the pcb and expose the copper layer.
rtc doesn’t consume that much so we’ll be fine with “OK wire”
I didn’t noticed the Vbackup and Vrtc… Or maybe yes, but trashed out the idea as this implies “torture” on the board. x)
In final, we probably need to centralise every modifications on the motherboard I saw in the forum and make a v3 of the board.
I’m just an embedded developper, not wasting resources is our motto. 
In fact, you use 256 bytes with size optimization in RAM, but it cost the same amount of flash (due to the bss). But yes, it’s can be nitpicking.
Anyway, you got me a clear idea of how to handle this point for the registers, thanks!
Sure, if the track is accessible and isn’t connected under the chip or on an internal layer. It’s already extremely suspect that C201 (which is supposed to be it’s decoupling cap) is on the opposite side of the chip from the pin.
It doesn’t! BSS takes zero flash space beyond the tiny bit of code that clears it during crt0. It’s a start address and a size and nothing more for the entire section. Are you perhaps thinking of the string duplication issue on arduino? (that’s .data for one, and on the atmega which is harvard arch and requires jumping through hoops to read values out of flash. Not an issue on an ARM chip!)
Also, this is one of those things that falls under the “premature optimisation” chestnut. 
I’m afraid the schematic has wrong labels:
VBAT actually connects to C202 not C201, and the trace is clean, no via
1 Like
Oh yes, my apologies, I got lost in my thoughts. Yes, only RAM, BSS increases but does NOT take up space in flash memory.
The functionality is already there, so I am already at the optimisation step, no more so “premature”.
But I see your point.
Also, be aware of that warning about Vbat in chapter 5.1.2 of the STM32 ref. manual (RM0008).
There is some current leak during the power on/reset sequence of the STM32.
This can be an issue if you still use 3V3 to power Vdd with a 3V non-rechargeable cell and its voltage drop below 2V7.
1 Like
it’s not too bad…
@JackCarterSmith thanks for the reminder! Didn’t realize the internal switch would leak.
1 Like