Thanks for the feedback!
I’m still not sure why the official firmware have I2C glitches, maybe the frequency, the handler structure…
Glad I didn’t experience this issue since using my version!
Please feel free to share if you are also experiencing problems with IRQs and power management; I haven’t been able to test them as thoroughly as the rest.
Yes, IRQ and power management are on my todo list for the driver implementation.
Also, I have a quick idea about the backlight: So we have steps for backlight (keyboard, screen) or values from 0 to 255, as I understand it. What if the requested step/value didn’t apply instantly but gradually reached the requested level from the current one in cycles - for example, over a 200ms period or faster - so it would have a smoothing effect. What do you think?
cut the direct feedback with inconspicuously changing，I think is bad idea（especially we don’t have a OSD when adjusting key/screen backlights）
It will be direct, but smooth, currently if you change the screen backlight it’s flashing like hell, very irritating in night time.
When in doubt, I prefer to keep the backlight as simple as possible (value=value) on the southbridge side. If you want to add a “smooth” effect, you can do so on the pico side without too much trouble.
What do you mean by “flashling”, like a stroboscopic effect? Or just too bright backlight?
Yes, like a stroboscopic effect
Mmm, the PWM frequency is set to 7 kHz (10 on the official). Normally it shouldn’t be noticed by human eyes (above 100 Hz). But this depends of the people, ambiant brightness, etc.
I’m always in the low brightness during night, didn’t notice the flicker, I’ll try with other values.
In any case, smoothing can’t help this issue… Flickering is the result of PWM itself.
The flicker occur during day time too? On specific range of brightness? Do you have the same effect on the official firmware?
I’m confused, it is strobing all the time or just when you change the brightness setting?
Only when fast changing the display backlight.
Feedback on power button:
Batteries not installed, power via usb-c.
After I press-hold power PicoCalc goes to sleep, next I press power one time, backlight comes on but pico failed to start, I see no activity on the pico led. Disconnecting cable(power reset) and press-hold power works as expected.
I didn’t tried to change quickly the value of the backlight through the I2C, I’ll try adding some ramp test to the test program. Maybe I can reproduce this behavior.
What range did you use for the PWM value?
From 0 to 9, it’s the LUT value and only from 10 to 255 you drive it directly.
(using this formula: (pwm - 10) * 511 / 255)
If you can build the firmware yourself, try to add `HAL_Delay(500);` after line 312 in main.c.
I removed it as I didn’t noticed breaking in the pico starting. Maybe that’s the cause of the power button fail to recover from sleep.
Minor comment since this affected uf2loader:
Often in the BIOS tasks are run on a periodic timer. Those timers are currently implemented something like the following:
int last_process_time = 0;
if (uptime_ms() - last_process_time < period_ms) return;
last_process_time = uptime_ms();
This is fine, except on startup, where the task has to wait a full period_ms delay before executing for the first time. Guess why my bootloader (which asks for keypresses immediately on startup) wasn’t seeing anything 
A slight modification flips the order around to “execute-delay-execute” instead of “delay-execute-delay”, removing the initial wait.
int next_process_time = 0;
if (uptime_ms() - next_process_time < 0) return;
next_process_time = uptime_ms() + period_ms;
But do put the update for next_process_time immediately after the check, because in the current keyboard task it’s at the end - which means the task runs slightly slower than the requested rate.
Thanks to notify this point!
I’ve rewrote this part in the past to handle the counter overflow/reset without disturbing the behavior. The default polling frequency value is 16 ms, but…
I see an another issue with the pico launch delay at the start: in the main.c line 219, the pico is set on but there is 500 ms delay (and some PMIC configuration after that). An order I’ve keep from the official firmware… But this can be related to your boot key pressing issue too!
I’ve pushed a new start-up sequence and applied a modification of the periodic timer check (to execute-delay-execute) on the git. With that, the SB should be fully initialized (keyboard start polling scan) before starting the pico.
Hope that fix your issue!
(if you can try building/flashing the firmware, I’m not home for few days to test it on my picocalc)
I had a quick look at your commit and I think you misunderstood the change I was recommending. You’re still saving the time of the last execution and comparing against the period, instead of storing the time of the next execution and comparing against zero. All you ended up doing is swapping the sense of the if statement and the order of the blocks - effectively a no-op.
Reducing the startup delay doesn’t hurt, though. I suspect the only reason it is there is to give the Pico time to write to the LCD and clear the random noise in the frame buffer (although that’s only there because PicoMite isn’t initialising the LCD properly!) As such, the lcd_backlight_on() call should move along with sys_start_pico().
No, no, I totally get it. The target goal of your recommendation is to avoid an initial delay on the keyboard scan (because uf2loader need a button-boot check).
But I’m really sure this isn’t help your issue with the bootloader. For my PoV, the current implementation already handle the case “execute-delay-execute” because of the uptime() already have reached 200 when the keyboard_process() method is called the first time. And the issue you’ve got it’s because of the pico_on() occurs before the 500 ms delay and the first keyboard_process() call. I’m not sure you get this point.
Except you’ve right about the counter refresh which need to be closer from the check to have a more accurate period.
If I can go into the details: with the previous code, you should have a delay of ~700 ms between the pico start and the keyboard fetching the value.
And what I’ve “moved” in the fix, will reduce this delay to none, as the keyboard_process() is called before the pico_start and not +500 ms after. And the uptime() - 0 > 16 should be already valid at this time of execution (because of init delay, the one of 500 that I’ve reduced to 200)
That’s why I’m confident about the patch I proposed.
Still you’ve right about the lcd_on I should put next pico_on function, I’ll change that in a new push.
because of the uptime() already have reached 200 when the keyboard_process() method is called the first time.
I try to avoid “works only due to some external state” code, because you forget about it and then change that external state later on. Especially since I’m mostly convinced that that initial delay is entirely unnecessary 
Honestly it doesn’t really matter as I’ve made changes on my end to work well regardless of what’s running on the stm32.
Without the delay it’s worked fine, I agree. Somebody have noticed some glitchs (maybe picomite and the screen) so I put it back just in case (500 ms aren’t the end of the world).
Afterwards, it’s not a bad idea to point out that the SB should have been ready BEFORE starting the pico. This was not the case, since the pico started before the PMIC configuration (apart from the delay issue)…
It’s almost inconceivable that I didn’t notice this before. 
So thanks again for that!
@pelrun Just to notify I’ve tried the boot key detection with the last version I’ve pushed on the git and look good!
Here the code I used to test it, I tried to detect the press at the most early time in the pico.
If this can help you avoid using “external state code correction” 
i’ve been using this as my keyboard firmware for a while, the backlight level being persistent is great
however, is Alt-B (which on the keyboard has a battery icon) supposed to make the picocalc reboot?
Alt+B perform a “battery check” (The power indicator light flashes a specific number of times according to the battery level) as the default firmware
yes, it did on the stock firmware, but on the one i flashed from this thread, which i can only assume is otherwise working correctly since all other functions including persistent backlight (which the stock firmware does not have), Alt-B causes the picocalc to reboot
