I2C / Keyboard Speed

PicoCalc
1

Does anyone understand the i2c / sb / keyboard communication well enough to help me understand what I’m doing and whether it’s “safe” or not?

I have written a simple raycaster with Blair’s starter as the basis. My FPS should be steady standing still, but it’s jumping up and down. I eventually realized most frames were rendered and sent in 0.0125 seconds but every so often one took 0.0180 seconds. Thinking more I realized the long frames matched the 0.10 second keyboard polling rate used by Blair. Trying to figure out why this took so long I eventually found the i2c baud rate is being set to 10 kHz.

I can see why Blair used this value since it’s used in the PicoCalc’s main GitHub page. I can also see discussions on this board wondering why it’s sooo slow. It’s only a number in a file and the worst that could happen is my program wouldn’t read the keyboard properly so I upped this to 100 kHz. My long frames are now only 0.0135 seconds, which is certainly good enough for me. I’m also able to navigate without problem.

My raycaster only uses the 4 arrows to navigate, so is poor reading of the keyboard being hidden from me? I tried the speed bump on a text based program and didn’t notice any more typing issues than normal.

Is there a reason I should stick to 10 kHz and accept the jumpy frame rate?

I’ve never updated the PicoCalc so I assume I’m running the stock 1.4 BIOS.

2

The BIOS has no influence on the clockspeed.
PicoMite/Webmite has been using 100Khz for some time already, the latest V6.02.01RC9 defaults to 100Khz but can be configured to 400Khz.

3

If you’re stuck on this 10kHz setting

Try this https://drive.google.com/file/d/1nPon0Xe50Ldr24agatrafc0qxFr9fsKS/view?usp=drive_link

in this PicoCalc_BIOS_v1.5.bin

there is no i2c 10khz speed setup by default and more stable because in this version code

picocalc’s keyboard will reset i2c if no events happened in 2.5 secs

could kill the the potential issue of the I2C long time hanging.

Here is the wiki how to flash picocalc keyboard firmware

Here is the code of this firmware:

1 Like
4

I tried 400 kHz, and it also seems to work, and now I can’t differentiate which frames are longer.

I wonder why Clockwork seemed to show that 10 kHz is to be used?

5

It is very difficult to understand why this has happened, but I have my suspicions. Once upon a time there were problems with PicoMite on the PicoCalc and somebody found that the problems were reduced with a lower speed. But the root cause was something completely different, the PicoCalc keyboard routine was implemented poorly causing packets to get lost or received in the wrong sequence. The original routine was using about 100 msecs pause between transmitting a read request and the receive request, this made it possible for other requests to be send before receiving. In addition there is a problem with the I2C slave routine in the bios causing the slave to get locked up. I implemented a monitor in the bios to catch this situation and to force a reset of the slave routine. In PicoMite there was another problem that I2C failures were not being ignored causing error messages, sometimes a sequence of IIIII… on the display because the message “I2C not responding” was unable to complete, this error message has been removed. Currently BIOS 1.6 and PicoMite/WebMite V6.02.01 are recommended, BIOS 1.2 and 1.4 should also work but do not have the lockup monitor function implemented.

2 Likes
6

Thanks @ernst for that explanation.

I rarely use Picomite/WebMite/MMBasic. Mainly I used C.

When I first got the PicoCalc I tried to upgrade to 1.4, but then realized it came with 1.4. By then I’d installed the STM programmer, but was VERY unhappy with the way it installed itself all over my drive without a good uninstall routine. Lots of manual cleanup. I would need to run a VM before I’d touch STM software again.

7

You do not need to use the STM 32 programmer as stm32flash can do the job.