Please note that this is a pre-release version, so I haven’t tested it much yet. There may be hidden bugs…
But if you want to try it and give me a feedback, it’s always appreciated!
The settings of the backlight are saved inside the STM32 chip 1.5s after the last value change. Saved settings are keep between restart and further firmware upgrade. The only way to clear it is by erasing the full flash.
The brightness curve has also been revised.
A new TYPE register (addr = 0x00) have been added to identify custom firmware, as the official firmware will always answer 0x00 when accessed.
This custom firmware use the TYPE-ID 0xCA.
I made some change in the backlight value range, this only change from raw 8-bit value to 10 steps [0-9]. This only impact from you if you drive the backlight from the pico.
Normally, all official registers are operational. With the exception of the management of external interrupts, which is currently being written… WIP
I haven’t finished implementing RTC stuff either… WIP
It’s forked from the 1.2 official firmware.
I’ve used the STM32 HAL and CMSIS lib to reduce the firmware size and allow more features in the futures. That’s for me like an “alternative”, not a replacement!
But still free to pick some parts or all the stuff for your projects.
Hack’n Play!
I didn’t read the source, but we need to come up with a way of probing the stm32 firmware version from the pico in order to adjust behavior. Maybe someone could come up with a scheme which includes a vendor id and version number (like usb?)
Hi, great and clean rewrite, here some suggestions
Feature requests:
Power button
send 0x74 send via FIFO for power button should be availabel from PMU
IRQ for keyboard events instead of i2c constant polling, will save a lot of CPU(power) we can use pins from spare second UART already connected to stm32 and pico. Second pin fro rtc?
i2c command for pico reset via pins (kinda power reset for pico)
Yes, I planned to implement it when I’ve finished polishing the registers that already exist but are not implemented on the logic side (such as keyboard config, debounce time, etc.).
For that point, I wanted to use the REG_ID_VER… However, it’s only 8-bit long and I don’t want to “lock” 2 or 3 bits just to separate the custom versions between them.
I was thinking of adding a new REG_ID_TYP register, by default it would return 0 on the original firmware and another value for all other custom versions. In this way, the REG_ID_VER register will continue to serve as the version register, without any interference from ‘firmware provenance’.
And this is more or less in line with your USB ID idea…
Thanks for the feedback too!
Somethink to reset the pico with power button you mean? I saw @pkr implement something like this too.
Yes… I’ve lost some hairs showing this I2C protocol, not so bad but definitely not the most effective… I want to add this kind of IRQ-request logic as an overlay to keep the old polling method available for compatibility.
And 4. Like “reset-me” and “shutdown” command? Sound good! Normally, there is a REG_ID_RST register for the reset, but I suppose I’m going to separate the reset of the stm32 from the pico, because a “full” reset of the STM32 also results in a reset of the pico…
Power button attached to the PMU can trigger event like long press for default poweroff and poweron, but also for short press on power button, the idea to send this event as usual keyboard key to the fifo with 0x74 code(power button code on linux) so software on the pico can for example handle it and go to sleep/ switch screen turn on or turn off.
Yes it’s already present in protocol, there is a FIFO count cmd in i2c and southbridge can trigger interrupt on the pico pin, then pico will ask i2c for fifo count and read the amount of fifo messages and drain the FIFO, then just read fifo as usual for key codes.
So there are will be 3 resets and 1 poweroff command:
Reset the Pico enable pin (power cycle the Pico)
Reset the STM32 without losing power on Pico if it’s possible (software or power cycle)
Power cycle reset for STM32 and the Pico (remember old reset button on PC )
Power shutdown for all power lines(via PMU shutdown) (Like long press power button)
In this case we can issue this commands to fully control the power sequence of the PicoCalc device. Instead of just soft reset the pico in the code.
Also since we use 1 bit for read write access, we left with 7 bits for commands so we can have 128 general commands
For example reset command second byte can address what device should be reset so we can do any of 3 resets via one write command and bits set for the cmd param
I could also help with RTC cmd, to set alarms for wakeup if we put Pico in sleep mode.
As for the 2 pins connected between pico and stm32, first pin just to trigger keyboard interrupt and the second pin attach to interrupts for all other southbridge events. So if pico triggered by the second pin it issue the i2c command to ask for event, end events could be done via the FIFO or just one event stored in register to read.
PS I know it’s looks a little bit complicated but it gives so much flexibility and power for the pico firmware.
For the 1. point, I’ll probably call this mode “stand-by” from now, as it’s very similar to pressing the power button on a PC to put it to sleep.
The pico pin to be used seem to be the issue for me right now, the only connections between the pico board and the stm32 are the I2C and the UART bus.
As I didn’t plan to use this UART, I was thinking of reconditioning it as IRQ_pin… And can only be de-asserted by reading the IRQ registers/FIFO. (I’d better start documenting these things or I’ll end up getting lost in thought :P)
Btw, the official firmware have a draft for that feature, but not implemented in final (probably because there is no program space left…).
The power commands seem good for me, except for this one:
“Reset the STM32 without losing power on Pico if it’s possible (software or power cycle)”.
Because of the electronic design, I cannot carry out a complete reset of the stm32 core without resetting the pico by domino effect. The best I can do in this context is to reset the registers, re-init the I2C and clean the FIFO.
And the power shutdown (actually the only mode implemented), look for the long press power button, and trig the PMU/PMIC shutdown directly, without waiting ACK from the pico (because this require a software implementation of that on the pico firmware).
But to this last point, we can add a configuration option in the correct register (REG_ID_CFG), by default it isn’t enabled, to wait for an ACK from a compliant pico software.
If the pico software support this feature, at the boot step, it configure the stm32 with this configuration option. In case of long press trigger, the STM32 send the IRQ, wait for ACK from the pico, and do the shutdown request to the PMIC.
For the moment, my current roadmap is as follows:
Missing official registers
RTC (+docs)
I2C IRQ mode (+docs)
Power modes (+docs)
EDIT: I made a misstake maybe, it should be possible to reset the STM32 without interfering with pico, need testing…
ST is unclear about the flash size, after crossing every datas (expecially the Ordering information scheme in the datasheet) and testing on the chip (STM32F103R8T6), I’m sure it’s a 64KB version.
I’m just starting to play around with picocalc development, and having to unplug the usb cable, hold down BOOTSEL, and plug it back in again is getting old (and I only get to do it so many times before something breaks).
Is it possible for the keyboard driver to put the machine in BOOTSEL mode with some particular keypress? That would be really handy if it was done by the stm32 so that it’s always available.
Technically yes, but only with hardware mods. It’s better/easier to to put it into flashing mode from the pico itself via software, such as with machine.bootloader() in micropython
I had wanted to implement a switch to the bootloader in software, but this option doesn’t seem to be possible on this family of chips (F10xxx)…
The only others solutions would be a hardware modification, or to implement our own bootloader in SW.
I believe he was talking about the bootloader of the pico…
But anyways, I do think the STM32F1 can reach the bootloader from software… even though we may have to do something extreme like wiping a portion of the flash
Oh! Maybe you right… I had a similar issue with the stm32 reflashing step, so I easily made the confusion!
I’ve used “bootloader<=>app” switch mechanisms on ARM architecture a lot in my professional work. I’m not sure to understand why this doesn’t properly work on memory of the F10xxx serie…
Maybe something related to the relative addressing who mess up with the linking of the ST bootloader.
Fortunatly (or not…) this memory part is a ROM, it can’t be overriden by misstake.
I’ll probably do some more testing later. The RTC registers need a release first!
