Interesting. Thanks for finding that! I apparently didn’t wait long enough between queries. This delay may not be something that can be fixed though. The code I added to PicoMite is based on the example code from the Clockwork repo. And it’s using i2c to query the keyboard hardware (stm32) directly. There’s no configurable delay, or any other parameters that could be adjusted. We can ask, and then we just get back an answer. I haven’t looked at the Arduino code in detail, but my guess is it’s polling for those values periodically on its own, and just returning the last saved value when asked. That sort of delay wouldn’t be much of a problem for reporting battery percentage (since it might be off by one percent), but it’s more obviously wrong with the charging indicator!
There’s at least one project (probably several) mentioned here in the forums that is working on the keyboard firmware, so maybe it will be improved in time. For now, I guess the charging indicator is more of a guess than a fact.
Your questions point out a problem that has plagued most Clockwork releases – the new user experience in terms of software and documentation is… not good. The company makes excellent hardware, but most of the software development ends up being done by the community, after each new device ships with a sort of bare bones, proof of concept software that is functional but minimal. And documentation tends to suffer the most, unless someone from the community takes that on as a challenge.
Weirdly, some of the confusion this creates seems almost by design. Clockwork has always targeted tinkerers, and while their devices could be even more popular and sell far more than they do, they always struggle to get devices out to the few people determined enough to buy them. It’s a weird situation, with a weird company who make weird devices, but it can be worth the effort.
Hopefully someone from the community will help on the documentation for the PicoCalc at some point. As you pointed out, things have been chaotic since the release, with lots of people working on lots of sometimes competing software solutions (like the MicroPython ports). The Clockwork github is a mess, old files and incorrect pointers to files, and little to no organization. And as with most Clockwork devices, the new user experience either requires reading months worth of posts on the forum (which is itself an organic mess of ideas, active experiments, and dusty forgotten stuff), hours of research and wasted time trying partial solutions that have been already replaced, asking questions (made more difficult when even understanding what to ask for can be out of reach), building your own new solution, or just giving up and either putting the device in a drawer or selling it.
I’ve seen this same story play out for the Gameshell, the DevTerm, the uConsole, and now the PicoCalc. It not all bad, but it’s unfortunate to see everyone go through the same struggles again each time. The good news is, you found the forums, and you’re asking questions and doing the right things. So welcome! And apologies.
After trying a build of RC22 and realizing i2c broke with new fixes made for the Wiimote on another PicoMite platform, I discovered it was our old friend again – timing settings got changed, so I #fidef’d the working version out for the PicoCalc. It appears it was already mentioned, but hopefully Peter won’t make more changes as this is a PicoCalc specifc thing and now fixed. All the more reason to be selective when messing with the latest RCs.
I’m thinking the best plan might be for me to keep the code in the PicoCalc repo updated periodically, but not bother doing release builds unless the main release stabilizes, or some truly major feature/fix comes along. Otherwise it’s just a waste of time and a lot of unnecessary noise.
It contains a minor change involving line continuation from upstream PicoMite, and includes some major keyboard input fixes thank to @thwill that should take care of the annoying keyboard issues that have been around since the initial Clockwork build.
I still haven’t received mine (ordered 24 Apr,) yet, but I’ve been collecting the latest firmware .UF2 files, and will install whichever is latest when I get my PicoCalcs. Thanks for the work you are doing on these updates.
The old problem is back where a program will incorrectly include header info '#A:/myprog.bas
at the beginning of the first line. It’s not a problem with the PicoCalc changes, it’s a general PicoMite problem.
Another coffee on it’s way Sir Michael . Working fine so far… Got the old ‘flash list’ issue back for now though, remember it dissapeared last time after a few reboots ?
@adcockm, it just occurred to me that at some point you are going to try adding a new PicoCalc specific MMBasic internal function (e.g. ASC()) and it might appear to work but then things will start going wrong in “unexpected” ways. This is because most implementations of MMBasic (the under development version of MMB4L excepted) have an architectural limitation of 128 (possibly 127) internal functions and the PicoMite firmware is either already at or very near that limit. Peter has used various “tricks” to appear to support more functions (e.g. pre-processing so that multiple functions get mapped to the same internal function implementation with a parameter indicating the specific “sub-function” desired) but there is no generally applicable method. Beware here be Dragons
I noticed when I added the OPTION and MM.INFO commands that there were comments in that area that looked like an attempt was made (but maybe outdated?) to keep track of how many different options/info there were. I figured I’d see if adding something new worked, and when it did and nothing else seemed to break I was relieved, but I knew I was venturing into uncharted territory. I’m also not sure what the usual procedure is for such things on TheBackShed, and I hoped I wasn’t stepping on any toes, which is why I tried to keep those things isolated and specific to PicoCalc hardware features.
I actually did start looking at what it might take to add some Bluetooth commands, but that’s a much bigger deal and would require more planning and thought, and some better defined usage scenarios. Similarly, there may be some extra wifi functionality not present in WebMite that may be useful, but again, I wouldn’t want to add anything unless it seemed useful.
It’s kind of funny the PicoCalc has the formfactor of a graphing calculator, but doesn’t have any built-in “calculator” interface (whether like the RPL from HP’s or stuff from TI and others), but that feels to me like something where a dedicated “calculator” firmware would be appropriate if someone wanted to make one. The MicroPython folks have already been adding extended math functionality to their stuff, and it’s certainly possible to use MMBasic to do calculations and graph functions and so on, but regardless of the language used anyone wanting to use this thing as a calculator is probably not looking to build the calculator interface from scratch. The PicoCalc is kind of the reverse of what I remember the HP48GX being – rather than a calculator with some programming potential, it’s a programming environment with calculator potential.
As far as adding commands though, I’m curious to see how people decide to use it, as I think that might better dictate what could be added. I’m hoping some clever uses appear that go beyond just porting all the regular stuff like emulators, games, and so on. It seems like the portability, battery life, keyboard, and minimal but decent processing power could be good for something, but I’m not sure I’ve seen an example yet, especially one not involving adding new hardware or modifying the existing hardware (not counting simple module swaps.)
This may cause some existing BASIC code to break, if it was testing key codes that have changed.
While the upstream changes from mainline PicoMite contain some bug fixes, this includes a complete cleanup for key handling on the PicoCalc. Please read the release notes, and their linked documentation for PicoMite keycodes. I describe the differences there between expected PicoMite keyboards and the PicoCalc keyboard.
The short version is, all the keys have been mapped to their PicoMite counterparts. But the PicoCalc is missing the ability to send some keys. Sometimes that’s because the key simply doesn’t exist (like F11 and F12), and sometimes it’s because the key combination already has a different meaning (like Shift + Tab which on the PicoCalc is how you send the Home key, so it’s impossible to send Shift + Tab). All of those anomalies are mentioned in the release notes, and also as comments in the code.
There are even a few bonus keys mentioned that you might not know you had on the PicoCalc. For instance, did you know you can send Page Up and Page Down? Or did you know there’s another way besides Alt + I to send Insert? (Please check the release notes! )
Nice! I didn’t know about those. Ctrl + Up and Ctrl + Down are the ones I stumbled onto. And Alt + Enter sends Insert. Those are all baked into the PicoCalc keyboard code.
Hmmmm just flashed your RC23 from RC22 and surprised it hadn’t initialized my flash as usual. Came back on with autorun on and flash slots 1 and 2 still populated. How can I test that its RC23 ?
I’m not sure there is a way to get the startup info banner (not sure what it’s called) with the version number through code.
But just to confirm on my own, I did: OPTION LIST (just to remind myself what it was set at, in my case OPTION AUTORUN 1)
then OPTION AUTORUN OFF
and power cycled.
The info came up as RC23.
And then I did OPTION AUTORUN 1
to set things back to the way they were.
There’s been mention on TheBackShed for some of these releases that people who had weird behavior should flash the flash_nuke.uf2 file to clear everything out properly before flashing a new release. I’m not sure when that’s necessary though. It will completely erase the flash though, for a fresh start, but I’ve only done it once as a test.
I tried to clean up the original code earlier in the week and get it working properly, but didn’t have success. Then I looked at the way others (like MicroPython) were doing it and essentially the same code was being used for both keyboard backlight and display backlight, with one slight difference (just the target register address). The original code in the PicoCalc PicoMite port was different though, with changes in timing and I suspect it never worked. I’m planning to go back and try it using something similar to the keyboard backlight code since that works (and probably clean that up a little in the progress – I had included the entire keyboard header and a few routines from the PicoCalc example, but very little of that is actually needed. Just haven’t had time, but hopefuilly soon! (It’s also been nice to have a bit of a break since Peter has seemingly paused RC updates on TheBackShed as he is near releasing a new version. )
Finger is on the coffee button . In general the display backlight comes on too low for me so have to adjust at every switch on grrrr. Note there is a backlight command in MMBasic but its not set up.
. Working fine so far… Got the old ‘flash list’ issue back for now though, remember it dissapeared last time after a few reboots ? 
