New Keyboard BIOS 1.4

[CWPete]

Thanks for your reply. I’ve tried being a bit more careful and it has improved the situation slightly. The problem is still evident however and some of the missed key presses occur when a clear audible click can be heard from the key. Maybe I’m just going to have to live with this.

I now have a far greater problem with the keyboard - when I’m editing a basic program in PicoMite’s Basic editor the message “I2C Keyboard not responding” appears continuously on the screen (fills the whole screen then scrolls until the picocalc is switched off). This has happened several times now. Anybody know what’s happening here ? I should mention that I’m using GP4 and GP5 on the expansion connector for serial comms but I can’t see how those pins could affect the keyboard’s operation.

[ChrisJournoud]

Hi,

I have installed once the bios 1.4; then with micopython and ulisp when powering up, the screen began to flash infinitely.

I went back to bios 1.2

Best wishes

[guu]

The restarting bug has fixed for mpy and uLisp under v1.4 kbd firmware

use the updated version of mpy and uLisp to test
UF2 versions:

• PicoCalc/Bin/MicroPython/micropython_pico.uf2 at master · clockworkpi/PicoCalc · GitHub

• PicoCalc/Bin/PicoCalc SD/firmware/PicoCalc_uLisp_v1.1.uf2 at master · clockworkpi/PicoCalc · GitHub

Multi boot versions:

• https://github.com/clockworkpi/PicoCalc/releases/download/multi_booter_v0.5/MicroPython_fa8b24c.bin

• https://github.com/clockworkpi/PicoCalc/releases/download/multi_booter_v0.5/uLisp_4.8f.bin

[ChrisJournoud]

Hi,

I reinstall the bios 1.4 and the uf2s from your links ; it’s OK for Micropython but not for ulisp

Best wishes

[guu]

Thanks for the testing reply

I re-downloaded the uLisp v1.1 uf2 from link above and tested

it worked here

it shows a prompt console with version : uLisp 4.8f

so what is the situation when you ran this v1.1 uLisp ? still rebooting like endess?

[ChrisJournoud]

Yes, it shows uLisp 4.8f and then start flashing continuously as it did before the new version you put on Github

[johnsondavies]

Hi @guu, please could you message me the source of uLisp that you’ve fixed to work with BIOS 1.4 so I can update the official release. Thanks! David

[guu]

Hi @johnsondavies

there is no need to update uLisp source.
the restarting bug is because uLisp used GitHub - cuu/arduino_picocalc_kbd: Arduino library for interfacing the PicoCalc Keyboard over I2C
and there was a calling of reset() caused this bug

I didn’t actually implement the reset function until version 1.4, that is why v1.2 works without problem. sorry about that

here is the issue log

Initialisation calls reset, causing bootloop on keyboard firmware 1.4

so I just re-compiled uLisp with latest of GitHub - technoblogy/ulisp-picocalc: A version of uLisp to convert the Clockwork Pi PicoCalc into a self-contained handheld Lisp computer. and everything should work.

[johnsondavies]

Thanks for the reply. So the source doesn’t need to change. I also provide a .uf2 image of uLisp; I assume I need to rebuild this?

[guu]

yeah,just rebuild a new .uf2 image will be ok
I already updated GitHub - cuu/arduino_picocalc_kbd: Arduino library for interfacing the PicoCalc Keyboard over I2C

so you may need to sync the locale copy of GitHub - cuu/arduino_picocalc_kbd: Arduino library for interfacing the PicoCalc Keyboard over I2C first

[terekgabor]

Since the same code (91h) is related for F1 and power button it is hard to program separate functions for them.

[JackCarterSmith]

I’m not sure where you found that F1 is linked to 91h instead of 81h?

Code/picocalc_keyboard/keyboard.h

I remembered someone have made the same remark, something related to PicoMite maybe? Like PicoMite do some translation and give a 0x91 for F1…

From the keyboard driver PoV, F1 = 0x81 and PWR_BTN = 0x91… Unless some middleware do some translation

[terekgabor]

Yes 91h in Picomite for F1 and Power button, but I think F buttons can reprogram.

[BrianO]

Here is a suggestion for a future BIOS update.

I’d like to see an optional PIN which if set, must be entered before the pico will boot. Nothing fancy, no encryption, but a 4 digit PIN to discourage someone from playing with the device. If the PIN isn’t known, it could be bypassed by refreshing the BIOS.

Is that doable?

[Codiator]

I would be even more tempted to play with the device.

[ernst]

@BrianO

Is that doable?

It depends. According to the documentation PicoMite has this as an option.

PIN Security

Sometimes it is important to keep the data and program in an embedded controller confidential. In the PicoMite firmware this can be done by using the OPTION PIN command. This command will set a pin number
(which is stored in flash) and whenever the PicoMite firmware returns to the command prompt (for whatever reason) the user at the console will be prompted to enter the PIN number. Without the correct PIN the user
cannot get to the command prompt and their only option is to enter the correct PIN or reboot the PicoMite firmware. When it is rebooted the user will still need the correct PIN to access the command prompt.

For the BIOS this would be a significant change but should be doable, I don ‘t know if the effort would be worthwhile.

[Codiator]

To prevent non-technicians from tampering with the device, it should be sufficient to create a mini autostart function that requests a PIN.

[BrianO]

I like that idea! Thanks @Codiator