Capslock toggle logic: PicoCalc/Code/picocalc_keyboard/keyboard.ino at f305e6def68bea588666abba399b0014ff96eed2 · yatli/PicoCalc · GitHub
However, Shift is implemented without checking capslock first:
So, if Capslock is on, and shift is pressed and later released, Capslock is cancelled.
Makes programming on the calc itself a pain in the butt. I use vscode when its anything more than 20-25 lines due to that.
Hopefully this can be fixed and a new keyboard firmware made available. Pretty sure I saw a post from guu that he’s moved on “to other things”, so I’m guessing any updates to PicoCalc firmware of any sort will be coming as “unofficial” updates from the community.
I’m still hopeful this work will lead to something better than what we have now. It definitely has some nice planned features. Might even be useful now, with the cleanup, power efficiency, internal RTC support (without requiring additonal hardware), etc. But I haven’t had the courage to try it yet and was planning to let it progress a little farther before I do. 
Honestly might be a good idea to take some of everyones suggestions from here & make a version with all the fixes people have made so far vs a bunch of releases none fixing all.
My wishlist (top-down from pragmatic to fantasy):
Thanks for noticing the bug! I didn’t seen it when looking on this part of the firmware.
I’ve mainly needed of the RTC/wake-up and low-power, but the default firmware use stm32duino which is really not efficient for this specific task (and use the half of the flash just for the C++ overhead). I would like to be able to complete a final, streamlined version 0.6-rc in the coming weeks, and finally decide how I should manage the I2C registers…
I don’t plan to adds others features/maintening the code often after that.
But if you plan to make a keyboard firmware “CE”, don’t hesitate to give a touch!
As I mentioned on the original post, you can use it as new a base for a community edition firmware! I cleaned everything to work/compile with the bare minimum on both windows and linux, using only the arm-toolchain (or stm32 optimized one) and gnu make.
This will provide a solid foundation and more freedom for embedded devs.
In the points order:
)I thinking… It isn’t the way the old typewriter/computer doing?
I remember I needed to press shift to remove the capslock…
That is what I thought as well RE: shift/Caps lock with old typewriters. It did surprise me, but I accepted it.
I don’t believe modern computers do that, at least the MacBook I am typing at right now doesn’t. The caps lock only affects the characters and not the numbers, and when I press shift, I still get capitals and I get the symbols above the numbers. When I release the shift key, the caps lock stays activated.
Indeed, depending on the keyboard layout, the behaviour you describe regarding caps numbers may change. Sometime you need to hold shift and sometime capslock will suffice!
Dont know if this will be even needed seeing 32gb is more than enough for basic but id like to see the ability to use more than 32gb for the sd card. I got a load of 64gb sd cards and im tired of reformatting them. Id also like to see the abandonment of fat16-32 and full adaption of ntfs or ext4. Every time i plug the calcs sd card into my laptop it pops up with “This drive needs to be formatted in order to be used”
- The pico BOOTSEL or the BOOTSEL from DIP switchs on the mainboard you mean?
The mainboard. The goal is to be able to put keyboard into flashing mode without opening the case and flip the DIP switches
Since the version 0.5, the internal RTC have the time and date exposed on the I2C bus
Superb. Also wondering, if we could hack the mainboard and connect VBAT to a coin battery – no external RTC module needed then!
GPIOs
Yeah I’m afraid those are all we’ve got, but nevertheless, the amount exposed via header equals those exposed from pico so I guess they will become useful, right?
… and, southbridge SuperIO, right? 
- Not sure to understand what do you want to do with programs and I2C registers…
This is pure fantasy, but if we first solve the progmem space issues (by switching to baremetal sdk), we can embed a micropython/basic interpreter in stm32, and transmit a program from pico to stm32.
It will then function as a coproc and run the program in the background, parallel to what pico is doing. Nothing compute-heavy should be done there since we will lose keyboard responsiveness, but I think it can handle some background logic, like maintaining persistent variables that can survive RESET and POWEROFF (with VBAT connected, stm32 has persistent ram).
A two-way fifo can be established with i2c registers.
If you mean “put the pico into BOOTSEL mode from code”, that is already possible from the pico-sdk, it doesn’t require external help. The function is reset_usb_boot/rom_reset_usb_boot in the pico_bootrom lib. It’s already used in multibooter/my uf2 loader. The issue there is actually the problematic power path (plugging in the pico usb port sends 5v to the batteries, yikes!) which I’m still thinking about hardware solutions for.
The biggest problem I have with the rewrite is the incompatibility of the i2c registers. The existing registers and their semantics should stay identical to the official bios, and any new functionality (even if it’s changing the semantics of an existing register) should live in a new register. It’s highly unlikely that the official bios is going to have any more significant development, but putting the new registers somewhere higher in the address space (like 0x40 or 0x80 onwards) should leave more than enough room for something unexpected.
I’m quite happy to help put that code into shape, just didn’t want the efforts to go in wildly different directions.
If you mean “put the pico into BOOTSEL mode from code”, that is already possible from the pico-sdk, it doesn’t require external help. The function is
reset_usb_boot/rom_reset_usb_bootin the pico_bootrom lib. It’s already used in multibooter/my uf2 loader.
I wrote that.
And I mean BOOTSEL of stm32 here
plugging in the pico usb port sends 5v to the batteries, yikes
really?? Isn’t there an axp pmic sitting in between? The 5V rail should be coming out from one of the LDO/buck rails and should NOT be connected to battery IPS.
Unfortunately the bios can’t help with that; every application has it’s own filesystem implementation and each one would need to be changed separately. That said, there isn’t a real 32G limitation on fat32, and it’s only the windows gui that refuses to format larger drives with it (but FORMAT on the command prompt will still do it.)
If windows is throwing an error on the calculator SD card, it’s almost certainly not because of the main partition, but the second 32Mb partition on it for Fusix.
Nope. The PMIC powers the stm32, but the pico VSYS is connected directly from the batteries via a high-side switch (WS4603 on the schematic) that the stm32 controls. A single diode, or the zero-drop diode equivalent circuit, really should have been included in there.
If the picocalc is off, then the batteries are also disconnected and you can plug in the pico while physically holding the bootsel button. But to do it from code requires the stm32 to be active (otherwise you have no screen or keyboard to actually trigger the mode) and so the safest way to do it is to take the batteries out and power the system separately from the usb c port.
I’m lucky in that I have a usb-c to micro-b cable that doesn’t have the power wire connected (it’s a very odd duck) which is perfect for this situation, but I couldn’t tell you how to actually buy one.
I haven’t been game to test it under low-impedance conditions, but I’ve proven locally that 5V is present on the battery +ve terminal in this state. I’ll try putting a resistor in place of the battery and seeing if there’s actually any current flow. It’d be really nice if it was doing reverse current blocking!
Ok, looks like it actually is safe - I’ve confirmed zero current flows when IN is pulled lower than OUT. It just happens to float in the high-impedance state. Which means I can now avoid taking these batteries out - already had one instance of putting a cell in backwards, and I don’t want to repeat it (something let out the burning smell, but I’ve not been able to identify what it was - everything still works!)
Great! Thanks for confirming that!
backwards
I did that once for devterm, the coil starts screaming like it’s a loudspeaker
