Since I installed the rp2350, I have experienced some *** HARD FAULT ***. Actually a lot…
And it happens when zeptoed is in use. Do not know if it is related. Both on picocalc console and serial console.
installed graphical term and all the picocalc stuff
zeptocom.js uploaded setup_blocks_fat32.fs
uploaded zeptoed
uploaded transfer_all
It seems it is getting worse somehow.
At first I was thinking I did something in my ds3231.fs code that caused it, but now it seem to happen after a little while after starting zeptoed, without loading the ds3231 code. I haven’t compiled the ds3231 code to flash, it lives in a file on the fat filesystem…
When it happens I have to restart the picocalc, a ctrl-brk or ctrl-c does not work. One time I had to remove batteries to get it to turn off…
I have done too many things to being able to pinpoint fault, but will try a reinstall with text only terminal to see if I get the same issue.
Do not think the upgrade of bios should mess up, but me playing with the i2c might upset the communication? though it’s not the same i2c pripherial…
I really have not seen this ─ this is quite strange to me. This might have something to do with the fact that you manually installed everything on top of a full build rather than using utils/build_picocalc.sh with a kernel build, which I have been using without a problem perhaps? Or if it is not that, maybe it is a hardware problem stemming from the connection with the DS3231 module?
Why don’t you try removing the DS3231 module and rebuilding with utils/build_picocalc.sh on top of a kernel build and see how it works after that?
I am sure that it isn’t the BIOS upgrade, because I have been using the BIOS upgrade all along without a problem. (Actually, some things may be broken by not having the BIOS upgrade.)
I was bored so I created a simple Asteroids ™-style game that I have named Rocks (the name change being in part due to trademark on the name Asteroids ™ by Atari Interactive, Inc.). Note that it requires an RP2350 because it uses hardware single-precision floating-point. You can get it from:
Note that it currently has no flying saucers or score, but rather just waves, where each wave an extra asteroid is added at the start (with the first wave beginning with three asteroids), and after beating five waves (and ten waves, and so on) you get an extra life.
Reinstalled from scratch with flash nuke, a kernel.uf2 and build_picocalc.sh
did have to rerun since it stopped at setup-simple-fat32.fs, got 16_mib on this card
Realized the sd card was not in, install halted…
did a erase-all, insert sd-card. system installed nicely
could the SD-card being not inserted be a issue? I havent ran it long enough to say if it is stable now. did disconnect ds3231 while installing, had no issues when I connected it again. Tried my code, and it seems to not cause trouble for now, that is.
Have been running similar ds3231 code on a rp2040 with 16mib for a while, without issues. But I did not use the internal RTC on this one. I will upload the internal RTC version to that board to see if it messes up the rp2040…
strangely, that board did not stop the build_picocalc.sh because of nonexisting sd-card, btw.
Can there be a difference between the rp2040 and rp2350?
Can you recommand a forth tutorial for starting playing with it on picocalc? I am a total beginner. I have successfully installed zeptoforth but I don’t know what to do with it.
If no SD card is inserted it should raise an exception during boot once extra/rp_common/picocalc_fat32.fs is installed (whether with utils/build_picocalc.sh or manually). Of course, it may boot up to that point, which may result in the PicoCalc support initializing but everything after FAT32 initialization not occurring. After this happens, if you attempt to use the SD card it is likely to crash, and certainly will not function properly, as the SD card FAT32 filesystem support will not be initialized.
This should not be a difference between the RP2040 and RP2350 – attempting to use an SD card without an SD card inserted will fail equally on both of them.
The docs in the tarball aside from the .md files at the root level are really API references. I would begin with ‘Getting Started with zeptoforth’ and read ‘Starting Forth’ by Leo Brodie as mentioned by @genHatton myself. I would also read all of USING_THE_PICOCALC.md.
Additionally, the picocalc_*.fs examples under test/rp_common and test/rp2350, e.g. test/rp_common/picocalc_hello_display.fs and the game test/rp2350/picocalc_rocks.fs (note that this one is not in a release yet but is in the master branch), should provide good tips as to how to program for zeptoforth on the PicoCalc in particular.
But in my opinion it is better to print out some of the documentation and use it alongside the device, at least for me. And it allways seem to be easier to find the passage I need when I have some pages to turn. But then again It may be different for you.
Having a notebook also helps, or a text editor open to take notes, while reading documentation.
Reading the documentation on the device I am trying to make code on, makes a ugly mess. Documentation and code side by side on screen, on a larger screen than the picocalc, also makes it easier, at least for me.
If you convert the docs to text or simply use the raw Markdown files you can view them in zeptoed at the same time as you edit your source code therein. Note that you may need to increase your heap size for zeptoed, depending on the size of the documentation files. Also note that you cannot literally view the docs and your code simultaneously, as zeptoed only displays one buffer (excluding the minibuffer) at a time.
Apologies if this has already been discussed (didn’t see it), or is somewhere in a guide, but I’m trying to get wifi working on my PicoCalc running zeptoforth.
So far I have managed to clone zeptoforth, switch to the picocalc development branch, build myself a Pico2W (rp2350) minimal forth image. I have flashed that image and I so far everything is peachy. However, then I want to initialize the wifi and connect to an access point.
I think the BUILDING_AND_USING_ZEPTOIP.md doc might be out of date (at least I get errors trying the initialization sequence there). So instead I’ve tried:
\ Step 1: Import all necessary networking modules
oo import
simple-cyw43-net-ipv4 import
pico-w-cyw43-net-ipv4 import
cyw43-control import
net import
net-ipv4 import
endpoint-process import
\ Step 2: Create the network object instances
<pico-w-cyw43-net-ipv4> class-size buffer: my-cyw43-net
0 value my-cyw43-control
0 value my-interface
\ Step 3: Initialize the object using the simplified constructor
\ This no longer takes the sm-index and pio-instance arguments
<pico-w-cyw43-net-ipv4> my-cyw43-net init-object
\ Step 4: Populate the helper words from the now-initialized object
my-cyw43-net cyw43-control@ to my-cyw43-control
my-cyw43-net net-interface@ to my-interface
\ Step 5: Define the connection word
: connect-wpa2-ap { D: ssid D: pass -- }
begin ssid pass my-cyw43-control join-cyw43-wpa2 nip until
my-cyw43-control disable-all-cyw43-events
my-cyw43-control clear-cyw43-events
my-cyw43-net run-net-process ;
The problem is with “my-cyw43-net init-object”, which says “PIO out of range”
I feel like I might be close to getting the interface initialized with a chance at connecting to my access point, but so far no dice.
Does anyone have the magic incantation for the zeptoforth picocalc development branch system?
The PIO instance and state machine index still need to be specified; you are getting PIO out of range because garbage is being pulled off an empty stack by the constructor for <pico-w-cyw43-net-ipv4>. What had been removed was the need to specify a PIO code address, as that is now automatically generated.
The cursor just sits at the end of the line and things look very much locked-up.
Again, the flashing of the basic kernel seemed to go well, followed by the ‘build’ script.
I used: utils/build_picocalc_zeptoip.sh rp2350 “$TTY” ipv4 firmware/cyw43/43439A0.bin firmware/cyw43/43439A0_clm.bin 7x8 text not_pico_plus core_1
(btw, I have tried “graphics” and “core_0” variations here, but I read somewhere that text might be better for memory headroom. I think core_1 is the recommended core).
As noted the sequence with your fixes certainly seemed to go without a hitch (no errors anyway).
It’s only when I try to actually join my wifi that things hang.
I may just be trying this while everything is still a little too much on the bleeding edge, but I was looking forward to telnet’ing in to a little forth machine on my network
It will apppear to hang until it acquires a WiFi AP. (I should have put code in my example for it to provide feedback in the process but I did not. You could modify connect-wpa2-ap to include [char] . emit after each connection attempt.)
Note that the CYW43439 in the Pico W, Pico 2 W, and Pimoroni Pico Plus 2 W out of all the WiFi standards only supports 802.11n, so if your WiFi router attempts to use a different WiFi standard this will not work.
core_0 is recommended when using zeptoIP because zeptoIP monopolizes core 1; note that with utils/build_picocalc_zeptoip.sh it defaults to core 0 not core 1.
As a sanity check, just in case I accidentally broke something in that test, could you try any of the other zeptoIPv4 tests, such as the example where it downloads the front page of google.com? (A warning – the test to download the front page of google.com with zeptoIPv6 was kind of broken last time I tried it due to changes on the Google side, and if you have AT&T fiber the zeptoIPv6 NTP demo may appear to be broken due to throttling by AT&T fiber.)
Have you tried my suggestion of adding [char] . emit to the loop in connect-wpa2-ap, and if so, what happened? I am interested in finding out if something has truly gone wrong with the CYW43439 driver or if it is just having trouble connecting to your AP.
I have put together a “snakes” game for zeptoforth on the PicoCalc. The source code is at:
It requires the graphical terminal emulator and uses the arrow keys for control, along with q for those cowardly sorts who want to exit early and are unwilling to run into themselves.
As it won’t let me create another comment in this thread…
zeptoforth 1.14.2.1 is out
This release can be gotten from:
This release:
fixes utils/codeload3.py so loading extra/common/setup_blocks_fat32.fs will not timeout if a new FAT32 filesystem in on-board flash needs to be initialized on a rp2350_16mib build; rather, a (lengthy) delay will be experienced.
updates extra/common/setup_blocks_fat32.fs so there is a clear comment that will be visible from the terminal at the point where it may delay for an extended period of time.
fixes a number of cosmetic issues with the v2 5x8-pixel font in extra/common/simple_font_5x8_v2.fs.
adds an alternate key combo Meta-T to unindent text in zeptoed because Shift-Tab is not usable on the PicoCalc.
adds two games that can be played on the PicoCalc, Rocks (a simple Asteroids-like game ─ note that this requires an RP2350), at extra/rp2350/picocalc_rocks.fs, and Snake (an implementation of the classic Snake game, of course), at extra/rp_common/picocalc_snake.fs.
Note that no changes have been made to the zeptoforth binaries themselves, so they will still report the version 1.14.2 in the welcome message even though the version numbers in the binaries’ paths have been updated.
Another Edit:
I still cannot make a new comment, so this is being added to this previous comment.
zeptoforth 1.14.2.2 is out
Yes, it has only been a day since zeptoforth 1.14.2.1 was released, but a couple bug fixes have been made that could not wait.
You can get this release from:
This release:
attempts to fix an issue where in some cases file/directory dates could generate exceptions in FAT32 filesystems.
fixes rchan::init-rchan so it does not leave a single cell of garbage on the data stack.
Thank you Travis for your continuous inspiring work on zeptoforth. After patiently waiting I received my PicoCalc this afternoon and will try to get it up and running with zeptoforth on a pimoroni pico plus 2w.
Yes, I do have a way of finding bugs in zeptoforth right after I have made a release. Sigh…
You can get this release from:
This release:
fixes bugs in interrupt::vector!, clocks::set-sysclk, and clocks::set-sysclk-overclock caused by inappropriately using internal::hold-core instead of internal::force-core-wait which caused the other core to lock up when both cores of the RP2040 or RP2350 were active.
