FORTH on the PicoCalc

When did you last pull the picocalc-devel branch? I ask because there is a bug in an older version that definitely would have made the screen come up white that I made a fix for (and then I changed the default foregrpund color from white to green).

I nuked my old repo and fetched a clean copy after you posted about the fixes. If you can point me at a particular line number in a file I can make sure I have the fix. Is it possible you didn’t push the fix to the remote?

Does line 97 of extra/rp_common/picocalc_term.fs read?:

    ansi-term::b-green constant default-fg-color
1 Like

And I am sure that I pushed my changes as that was my most recent change and I checked GitHub for it using its web UI.

1 Like

It seems that the issue was that I wasn’t inverting the display (and colors were already inverted by default), and I mistakenly made a change that turned the cursor black, which was then turned white because of display inversion. Please pull again, and reflash your Pico with the ILI9488 driver this time because I had to change the ILI9488 driver to support display inversion.

Thanks in advance,

Travis

1 Like

Okay, I felt lucky so I compiled all of it to flash (I had to invoke restore-state first so I could send the driver down again).

I get a green block cursor in the upper left-hand corner. Keyboard doesn’t work.

I’m on 1.2 of the keyboard driver if that matters.

Do I have to cycle power to get the serial terminal back? I did NOT run the initializer step fortunately.

Okay, there was a stupid bug in the keyboard interface implementation due to my misreading pin numbers in the schematic as GPIO numbers. This has been fixed, so please pull and try again.

How do I delete an ā€œincludeā€ I already compiled to flash? Or is it easier to just restore-state and download again?

Yes, if the PicoCalc terminal emulator isn’t responding you have to reboot to get the serial terminal back. However, it is still listening to the serial connection (via USB on the PicoCalc) for control-C, which will reboot without having to physically cycle power.

1 Like

Okay, I recompiled all three to flash. Still the same issue.

-Dave

If you want to wipe out code you have already compiled to flash, the simplest approach available is to execute restore-state at the console, yes. If you have code you want to retain in flash but want to wipe out other code after it, you have to plan ahead and use either marker ( ā€œnameā€ – ) or cornerstone ( ā€œnameā€ – ) while compiling to flash, which you can then invoke at the console (restore-state actually is a cornerstone) which will wipe out code subsequently compiled to flash and then reboot. (The difference between a marker and a cornerstone is that a marker erases itself when invoked, whereas a cornerstone is preserved and may be invoked multiple times.)

1 Like

Are there some words I can invoke from the console to see if it’s talking to the keyboard or not? Difficulty: Most of my experience with FORTH is GraFORTH from the 80’s.

-Dave

If you want to see if it’s talking, you can add breadcrumbs to the keyboard code, e.g.:

[: ." *A* " flush-console ;] console::with-serial-output

BTW, it turned out that there was yet another stupid bug in the keyboard code! I was using I2C0 instead of the correct I2C1, and I had forgotten to enable pull-ups! So pull and try again…

Thanks,

Travis

TX: \ Initialize the PicoCalc terminal
TX: : init-shared-term ( -- )
TX: <picocalc-term> shared-term init-object
TX: shared-term init-term
TX: ;
TX: initializer init-shared-term
error initializer init-shared-term I2C target address not acknowledged

I get that now after I try to upload term. I put only the LCD driver in flash this time and have rebooted a few times trying to upload keys then term. Term isn’t finishing for some reason.

I checked git diff and I have no local modifications.

I cycled power a few more times and then got it to upload both picocalc_keys and picocalc_term. However, when I init the terminal I still just get a green cursor and a dead keyboard.

-Dave

1 Like

I just made a change to the I2C handling, so could you try again now? Thanks

Travis

(I posted this before, but I wanted to post it again but as a reply to your post, but it would not allow me to repost it because it was ā€œtoo similar to a recent postā€.)

Sorry, still no difference in behavior I can see. Can you do something like toggle the LED on the pico if you think you’re getting any traffic, and/or print some sort of sign-on message when the terminal is initialized so we can tell if that’s working?

Also, I’m seeing traces of some exception handler running

address: 1001FAF2
                     200414E0: 2001D553 <no name> 2001D526 +0000002C

so the pico seems to be crashing sometimes.

Also, is the picocalc-term::term-console step still necessary? Right after picocalc_term finishes uploading, I see some garbage on the screen briefly that’s cleared to black with the green cursor that makes it look like it’s already starting something.

-Dave

I’ve been spamming git show and git pull so I picked up your LED tester. If I’m understanding it correctly, holding down Ctrl should blink an LED. It does not, unfortunately

I tried loading just picocalc_keys and fussing with the keyboard. Couldn’t get the LED on the PICO itself to toggle. Then when I loaded picocalc_term I did notice that the LED would come on and stay on, if that means anything.

-Dave

I just added code to toggle the LED at GPIO 25 when a keypress is detected, just as a sign that it is doing something. (Edit: you obvious noticed this given your comment while I was writing this comment.)

I also made it display a welcome message when picocalc-term::term-console is called.

Note that picocalc-term::term-console is currently necessary because it disables the serial and USB consoles for the current task, so there would be no way to use the system once picocalc_term.fs was loaded if it did not function properly. Eventually I may make it automatically called on boot, but for the time being I think it is a good idea to require it to be explicitly called unless the user specifically chooses for it to be called.

The fact that the LED is lighting up indicates that it is doing something with the keyboard, but it might be breaking in the process.

Okay just picked up your latest changes. Now every time I press a key, the LED on the PICO itself toggles.

I don’t see any welcome message after running term-console.

I also tried blind-typing reboot and enter but it did nothing.

Also, for anybody else following along, the LED wouldn’t toggle on every key press when I only loaded picocalc_keys. So I’m guessing nothing in there is actually active until picocalc_term runs. Well, actually, the LED starts to toggle as soon as picocalc_term runs, and before I’ve done init-term.

And to be really clear — is it expected that the screen clears to a small green cursor as soon as the picocalc_term file has finished loading?

-Dave

I just fixed a bug in the input handling that definitely would have completely broken things, so try again now.

Note that loading picocalc_keys.fs by itself does nothing; it only works when then initialized by picocalc_term.fs.

And yes, the screen clears to a small green cursor on initialization ─ this means that at least the initialization of the graphics portion of things is functioning correctly.