Fresh 0.8, with the PicoMite you provided (6.01.00RC27e). Powering from USB-C directly, no batteries available too…
First boot ok, simple press on pwr button write a ‘f’ on console. Long press put it off. Press again, load back fine.
Tried 5 times in row, still “good” like first boot…
I did the same with Picoware too, can’t reach the bug.
Maybe if you try with only USB-C and no batteries? Pretty sure that will doesn’t make a difference, but if you want to try…
Sorry, I can’t have a definitive answer yet
I’ve eared some issue with the stm32 programmer months ago… Something about incorrect erasing behavior. If you’re version of stm32flash is less than the last june, it should be OK. (I’m using v2.20)
Hello, first post here, but I think I have an idea about the issue BrianO might be having.
With the stock firmware I have to hold down the ON/OFF button to power it on or off, but I noticed when I held it down to power-on with this firmware the power indicator would flash but the device wouldn’t respond… But when I simply tapped the power button it would actually turn on, hence I think the bug might actually just be an unexpected behavioural difference between the stock/clockworkpi firmware and the JackCarterSmith one.
So I’d suggest seeing what happens if you only hold the ON/OFF button to power it down instead of when you want to power it on.
Indeed, a long press when the PicoCalc is sleeping will trigger the wake-up… and the power-off a quick time after it.
I’ll add a patch to ignore the start long press on the power button. Until then, for power-up, only do a short press, and if it’s really offline, do the long one.
I made the mistake to make two changes in parallel. I updated the keyboard firmware to yours and I replaced the Pico by a Luckfox Lyra with Calculinux.
Your firmware seems to be working, because I can switch the device on and off, change the brightness of the display and keyboard, and the settings persist. But I can’t log in to Calculinux because it doesn’t accept/recognise any keystrokes.
I couldn’t say 100%, but mostly 99%. Because of some corners case created due to the change of the power-off/sleep/etc. handling, and the review of the backlights settings (compatible but with limitation).
For your issue with the keyboard, I can say that it work for the official hello_world program and PicoMite too.
But since the 0.8, I removed the I2C frequency limitation but I noticed some instability resulting in keyboard strokes not fetched by the pico…
Just in case, I recommend to keep the 10 kHz for the I2C between pico and stm32 if unstable.
I installed 0.8 again. A fast-press power up the pico now! But….when picomite starts up, the version header is displayed one,…character…at…a…time very slowly (it did the same during all my previous tests when the device actually powered on) Also, the battery level shows as -129%! (After going back to 1.4 the same batteries show 90%)
I changed the battery refresh from 20s to 2s, should help for the “-129%” I suppose…
But for the slow character printing… The version header is from the PicoMite? Maybe something goes wrong with timer on the pico board.
Does this happen all times you “wake-up” by short press?
I added a patch for the “long-press” case on the power button… I can’t still fully manage the case of keeping press or not, because of hardware design, but 2s sound large.
It will be available in next release if you can’t/won’t build the firmware yourself.
Sorry, I just read again my notes about the I2C clocking… Reducing the main clock frequency (to gain in power consumption) have the side effect to only allow 100 kHz as max frequency for the I2C peripheral.
So indeed, you can include in the 1% corner the usage of the 400 kHz I2C. But unless you really need this freq, 100 kHz is fair for a keyboard interface (or if you can type more than 10 keys per second in average :P).
And if you really need the 400 kHz, you need to update the clock configuration file in the source to have at least 8 MHz as main clock (instead of 4). However, you’ll have more current consumption (~10 mA). It’s up to you!
From what I could reproduce for now:
short press => got the picoware graphic running fine
long press => got the green on and off quick after (like you said).
It’s because the firmware receive the long-press signal from the button too early in start-up, I’ve added a delay (2s) before allowing long-press signal to have effect.
Should work but not tested (only pushed on the git).
Looking at the code related to hal_interface.h, I wonder if after the #ifdef UART_PICO_INTERFACE section, specifically in #else section where you wrote #define PICO_IRQ_Pin LL_GPIO_PIN_10 for the experimental wake-up feature, I wonder if Pin 11 could be set as a second IRQ, perhaps one that could be held high if there is currently any keystrokes within the FIFO buffer?
It would still allow the existing polling methods to work, but could also be used by new or updated firmwares to instead use interrupt handling to know when a keypress has occurred.
I might as well give it the ol’ college try as they say, see what I can come up with for either a Keypress IRQ or even FIFO IRQ, since I’ve already started modifying the JCS firmware code to implement using the unused UART_RX pin for a non-waking IRQ…
Update
I did a bit of editing to your original source code and added a separate IRQ for non-waking events, and set it up to have it be pulled high when something is added to the FIFO for key events, and when it’s flushed or when dequeued completely it should bring it back low.
Just need to do some testing and if it works I’d be more than happy to give you the modified source.
@NeroVance in others words, if I understand properly, you wanted the second unused pin to act as mirror of the bit status “FIFO not empty”?
Actually I keep the “simple” approach of the original firmware, triggering the global IRQ at each key stroke. But indeed, you need to poll the IRQ status, check if it’s a keyboard related interrupt, and fetch the FIFO…
I agree, sound inconvenient to me too.
I suppose I could add your modifications as-is, or enhancing the idea by adding a user programmable second IRQ pin, by default on the key interrupt, to allow specific and only one IRQ on that pin (instead of a global IRQ)?
Can’t be sure of “when” I can give some times to test it however.
@Codiator Calculinux hasn’tt really been tested (by me) with this firrmware yet. @johnlaur and I have every intention of supporting it, but have had other more basic things to iron out first. I’m hoping testing and debugging with this firmware is one of the next things we can tackle
the release pushed out today / yesterday includes nettworking over the lyra’s USB port, so you might be able to ssh in and check things out that way if needed
