What's involved in porting zeptoforth to other ARM microcontroller boards?

[znmeb]

I have some Teensy 4.1 boards and some Electro-Smith Daisy modules. Both have ARM Cortex M7 microcontrollers. What would I need to do to port zeptoforth to these devices?

https://www.pjrc.com/store/teensy41.html
https://www.electro-smith.com/daisy/daisy

[tabemann]

For the Teensy 4.1, I would look at the rp2040 port of zeptoforth for the flash support, because this too uses external flash in XIP mode, and the stm32f746 (which is Cortex-M7) port of zeptoforth for everything else. For the Daisy Seed their datasheet seems unclear as to what kind of flash they are using, which would determine the particular design needed. Anyways, basically, you will need to write flash and UART drivers, including support for interrupt-driven serial IO, and clock and other hardware initialization code. If you want binaries to be built as part of each release, mail me examples of the platforms in question; otherwise, I will consider them contrib ports, i.e. without binaries being built as part of each release, because building binaries currently requires having physical examples of the target platform on hand.

[znmeb]

Thanks!! Both of them can use the Arduino 1.8 toolchain if that helps with the flash and UART code. I'll probably focus on the Teensy; I have four them (without the header pins). For the Daisy, I have a simpler Forth in C I can use that will integrate with their existing tools and examples.

[znmeb]

Thanks!! I'm probably going to start off buying a Raspberry Pi Pico if I can find a decent audio adapter / breadboard.

[tabemann]

For starters a Raspberry Pi Pico is probably a good starting point, especially because it will allow one to test the multicore functionality of zeptoforth. Word to the wise - if you want to get a $4 Raspberry Pi Pico it won't come with header pins, and at least when I bought mine for $5 on Adafruit it came with header pins but I had to manually solder them on. Expect to spend more money than that if you want to buy a Raspberry Pi Pico with pre-soldered header pins or a board that the Raspberry Pi Pico will plug into using its castellations.

[znmeb]

It's been a while but I'm getting back to this. I have a few Raspberry Pi Picos now, including some with the WiFi, and two of the Pimoroni audio packs. They all have headers. I was planning to write my own Forth but it looks like Zeptoforth will do everything I was going to write and more.

Is there an easy way to not build in the parts I won't be using, like the object system? I want to reserve as much RAM as possible for audio buffers.

This is my project: https://github.com/AlgoCompSynth/CLAMS. From the README and the GitHub project you can probably see I was planning to write my own Forth, using Stephen Smith's book on Pico assembly programming and some combination of C. H. Ting's eForth and Brad Rodriguez' "Moving Forth". But Zeptoforth has all the optimizations I was planning to use, so if I can minimize the RAM space occupied by compiling code into flash it will save me a few weeks of Forthwrighting.

[tabemann]

To not build code when building Forth first copy src/rp2040/forth/setup_full.fs to another location and, in your copy, copy the contents of src/common/forth/full_default.fs and src/common/forth/full_extra.fs in the places of #include src/common/forth/full_default.fs and #include src/common/forth/full_extra.fs, respectively, in your copy. Then remove everything you will not use.

Note, however, that there are dependencies between different portions of the code. E.g. if you remove #include src/common/forth/oo.fs you need to exclude everything that was in src/common/forth/full_extra.fs as it relies upon it. One thing I should note is that object system, by itself, does not use much RAM, but the SDHC/SDXC card and FAT32 layers, which rely upon it, do by default use some extra RAM.

If conserving RAM is your major concern, I would suggest removing #include src/common/forth/line.fs, #include src/common/forth/block.fs, and #include src/common/forth/edit.fs. Note that removing these will remove the line editor (which, if you are using zeptocom.js, is superfluous), blocks, and the block editor (which cannot be used under zeptocom.js anyways). There probably are other things you could remove, but it is time for me to go off to work, so I will have to look into them later.

After you have done all this, use the following to upload your code to the Pico:

utils/codeload3.py -B 115200 -p <your tty device> serial <your modified copy of setup_full.fs>

To get a copy of your code from flash once you are done, use the following:

utils/download_uf2_image.sh <your tty device> <your destination path except for .ihex, .bin, and .uf2 extensions>

Note that utils/download_uf2_image.fs is not in a build at the moment but is in the master branch in GitHub.

[tabemann]

Note that before you upload your modified setup_full.fs you will need to flash your Pico with bin/<version>/rp2040/zeptoforth_kernel-<version>.uf2. Also note that utils/codeload3.py requires Python 3 and pySerial, and utils/dowload_uf2_image.sh requires those (as it uses utils/codeload3.py) as well as GNU screen.

[znmeb]

Thanks! I'll probably load the whole build first to see how much RAM I have left before I start pruning, at least until I get the digital signal processing code done. And I can probably put large-ish data like wavetables into flash.

[tabemann]

I would recommend putting heavily used data, especially larger data, in RAM while it is in active use, because on the Pico the flash is constrained by the 16 KB XIP flash cache, and XIP flash cache misses can be expensive.

Also note that when I wrote "Python 3 and material" above I meant to write "Python 3 and pySerial" but my phone auto-"corrected" 'pySerial'.

[znmeb]

I've added code to my fork to build the documentation in epub format if you want it. It requires sphinx and myst-parser, but you probably already knew that.

[tabemann]

If you want to submit your code to be included with zeptoforth I would highly suggest you submit a pull request so I can merge in your functionality. Thanks!

[tabemann]

If you want to contribute your jammy build script and the associated doc file, when you create a new pull request, could you make a contrib directory at the base of the zeptoforth repository and put it in there?

Thanks,

Travis

[tabemann]

Actually, don't make a new pull request - I just reopened the one you created earlier.

[znmeb]

New pull request is submitted.