I am gonna calculate so many things

TL;DR micropython go brrr

I got the email notifying me of the PicoCalc’s existence on March 12. There was a brief period where I waffled, but I’d ordered one by the end of the day. It arrived on March 31.

What I’d envisioned from the marketing material was essentially a gameboy with a keyboard running a micropython repl. After fiddling with the stock picomite for a bit, and reading about other folks efforts to port micropython and circuitpython, I figured it was time to take a stab at getting some python running. At this point I’d been working with python since the pandemic started, and micropython on pico w for 3ish years.

The first attempt was based on a post here announcing the user had successfully ported micropython to an esp32 on the picocalc. I was able to remap the pin assignments to the pico w and load micropython, but it was pretty janky. Most of the keyboard worked, so I could type and hit enter, but the arrow keys were inoperative so I couldn’t move the cursor left/right along the line I was typing and I couldn’t scroll through command history via up/down in the repl. The CTRL key also didn’t seem to do anything, so the repl’s functionality was pretty severely limited. There was also an issue where if a line wrapped in the console, it would lose a character where it split the line. This was worked out by futzing with some parameters in the driver that had to do with calculating the number of characters that would fit in the console width. I did figure out changing the colours, and changing the font, but I wasn’t really getting anywhere on the keyboard. Later on I circled back to investigate a little more, and found that keypresses were all being recognized, with the appropriate keycodes being transmitted, but for reasons I didn’t determine many keys did not evoke any kind of response from the repl.

This is where I started with micropython:
https://github.com/jd3096-mpy/PICOCALC-micropython

Next I attempted to run circuitpython. I’ve tinkered with circuitpython a little in the past, but everything I’ve actually succeded in making work has been in micropython. Circuitpython has a thing in I think displayio called CIRCUITPYTHONTERMINAL or something to that effect, and it seemed like it should simplify the process for me. Based on another user’s work adapting an ST7789 driver to work with the PicoCalc display (I want to say ILI9488?) in circuitpython, I was soon able to display a repl. At this point the repl presented with black text on a white background, and I set about trying to adjust the colours. Eventually I constructed and applied a ‘palette’, but found the colours displayed were completely different from what had been set, though all of the elements had changed colour. Continuing to hack on the colour setup, I found that the displayed console had 3 distinct ‘TileGrid’ elements, and after some dicking around I got the background to be black and the text to be green. This exercise made it clear that all displayed colours were being inverted. I managed to get the elements’ colours reverted, but there is a small amount of padding between the console and the elements along the top of the screen that remained white. I tried briefly to place a black TileGrid in a layer under the others, but abandoned that in favour of trying to correct the issue in the display driver. Earlier on I’d found a datasheet for this model of display and thought I’d seen something about setting invert mode while skimming through. Prior to this I had zero experience talking to devices of this sort, so it took a bit to figure out how to use the information from the datasheet. I’d eventually hypothesized there must be an invert command somewhere in the init sequence, but didn’t find one, or anything else that seemed related. Through a little trial and error I got the invert mode on command (21h) working in the init sequence. Clearly for whatever reason this display using this driver had its colours inverted when invert mode was set to off. The display had been a journey, but it was sorted and I figured I was nearly done. By now I should probably recognize that as an indication I’m nowhere close. I spent many hours trying to get any response from the keyboard mcu via i2c, and just could not get it to respond. This might have had something to do with being connected to the microusb on the pico, but I couldn’t get the usbc port to work. According to tio I was connected, but there was no repl and no response to any keys. On the microusb port I could connect and see the same repl on picocalc as in my terminal, which worked fine, with the glaring exception of the picocalc keyboard still did nothing and I couldn’t get a rise out of the controller. This is about where I’ve typically arrived with circuitpython, it seems slick and like it’s going to make my life easier, but it gets me like 80-90% of the way before I find myself at an impasse and go back to micropython.

This was the basis of my circuitpython attempt:
https://forum.clockworkpi.com/t/circuitpython-with-pico-2-w/16394

After letting the picocalc languish for a spell, I happened to see a mention of another project based on micropython that seemed complete, and targeted the pico. Of course it had been built and tested on the pico, pico2, and pico2w, and all my picos are picow. I’m not tremendously familiar with building firmware or working with c, but I’d previously worked out building micropython with the repl on uart0 (so I could connect over the usbc port). Unfortunately my initial attempts to follow the instructions precisely did not yield the result the author described, something was missing. Searching around I encountered an individual who had taken the build steps and worked them into a script. Now, I am uncertain if they had tested their script, or if there is something different about my environment, but still no joy. The script clearly assumed by the final steps that a firmware file would have been generated, but I am at a loss as to how that would have come to be. I added a step in the script to issue make in the appropriate directory after the other build steps were complete, and before trying to copy the nonexistant firmware image. Additionally I incorporated a script to find the line relevant to making uart0 available and change the value from 0 to 1. Finally, it worked.

This is what I based my picow firmware on:
https://github.com/zenodante/PicoCalc-micropython-driver

And this is the script:
https://github.com/seanbutler/PCMP-SCRIPT/blob/main/scripts/runme.sh

At this time I have micropython running on a picow in my PicoCalc. The keyboard and display are fully functional, I can access the repl via usbc, and the repl takes inputs as expected. Wifi was connected without issue, but I have not tested the webrepl. I’m planning to see if I can work out sending and receiving scripts via tftp, but for now I’m mostly playing with the exposed gpio. The last couple weeks have sucked for other reasons, and having the PicoCalc without being able to make use of it was really bumming me out. But now it works as I had hoped, and I am loving it. In retrospect, without all the time I invested in micropython and circuitpython on the picow the last few years, and a collection of other bits and pieces I picked up working other projects, this process would have been substantially longer. There are a number of points where I’m pretty sure I’d have hit a wall without a path forward.

I’ll find links to the projects I mentioned and edit them in (EDIT: done), hopefully my experience will be of use to someone. Please understand, if my account seems critical of any of the projects I cribbed from, that is not my intent. Thank you to everyone working on this, I could not have done it without your work to build on.

4 Likes

Thanks for your story, it definitely resonates with me. The delicate balance between frustration on one side, and fulfillment on the other. I think that the whole point of those devices is to pushes you into exploring unknown territory, where documentation is lacking, where hardware interactions are nonsensical… But yeah, that’s what we love.

1 Like

the runme.sh seems outdated.

-DUSER_C_MODULES="$project_dir/PicoCalc-micropython-driver/micropython.cmake

in repo of PicoCalc-micropython-driver there is no single file called micropython.cmake

and I followed the whole docs to reproduce , I met some problems:

In GitHub - zenodante/PicoCalc-micropython-driver , the pre-compiled uf2 seems miss module vtterminal
So I compiled firmware followed the docs in PicoCalc-micropython-driver ,successfully created firmware uf2 file, after I flash the compiled firmware uf2 into pico/pico2

  • try to run main.py from pico_files. thonny report
MPY: soft reboot
Traceback (most recent call last):
  File "<stdin>", line 15, in <module>
AttributeError: 'module' object has no attribute 'pc_display'

Don’t know how to do

and the whole project can not auto run when there is only type-c plugged into PicoCalc ??

Wait a while longer. VT100 style terminal is being put in at the moment and not everything is matching up yet.

now it works. With editor also.

3 Likes

I pulled your github repo

then I compiled the firmware uf2 file

then I upload main.py into Pico2

I clicked main.py in left , main.py showed up in thonny

then I clicked run , thonny report errors

MPY: soft reboot
Traceback (most recent call last):
  File "<stdin>", line 12, in <module>
  File "picocalc.py", line 78, in __init__
  File "picocalc.py", line 129, in reset
  File "picocalc.py", line 87, in write_cmd
OSError: [Errno 5] EIO

and If I unplug micro usb , only get type c plugged into PicoCalc ,then Power on ,nothing showed up.

How to run it correctly?

thanks

Looks like keyboard is not showing up (the EIO error).

You might want to try recompiling the keyboard firmware with my delay fix.

1 Like

well
even with your delay fixed keyboard firmware, still got the same errors

Did you deleted the old py files in lib?
When you upload the uf2 and ONLY main.py, unplug the usb on rp (if you don’t use battery, you could leave the power usbc there) and click the power button, it should work.

Or you may try my uf2 first before you try to compile your own

Try also delete last line in main.py: os.dupterm(pc_terminal)
Then save to pico
Keep usb with thonny,
Tune on power,
CTRL+d reboot
What error message it shows in Thonny?
It should show a cursor blinking on the top left on the screen. You could run edit from thonny repl interface and see it on lcd.

Thanks very much

after your very detail guidance, It worked on my pico2

I finally can see the python terminal

Now I included your work into PicoCalc official github repo as a git submodule, hope you will like it too.

For anyone who interested to try micropython on PicoCalc

I also made quick try pre-compiled uf2 ,just download them from

micropython_pico2.uf2
micropython_pico2w.uf2
micropython_pico.uf2

these uf2 already included main.py
so no need thonny, just download and put into PicoCalc, you will get a running python terminal right away.

4 Likes

Great! And which tool did you use to package the main.py into the uf2?

Has anyone tried the pico2w version? Did it run successfully?
I copied to the 2350a just fine, but micropython would not start The Picocalc just reverted to the previous install of MMBasic.

I tried it. It works fine for me.

Not a tool

just put main.py into micropython/ports/rp2/modules when compiling firmware