Close
0%
0%

zeptoforth

A full-featured Forth-based RTOS for ARM Cortex-M

Public Chat
Similar projects worth following
zeptoforth is a bare-metal Cortex-M Forth which includes an preemptively-multitasking, priority-scheduled RTOS. It currently supports the Raspberry Pi Pico and Raspberry Pi Pico W (and other RP2040-based boards), the Raspberry Pi Pico 2 and Pimoroni Pico Plus 2 (and other RP2350-based boards), STM32L476, STM32F407, and STM32F746 DISCOVERY boards, and STM32F411 "Black Pill" boards, but work is planned on porting it to other boards in the near future.

zeptoforth is a portable subroutine-threaded / native code inlining Forth for Cortex-M0+/M4/M7/M33 microcontrollers which includes a preemptively multitasking RTOS designed to be able to compile to and run from both flash and RAM (the kernel of course exists in flash).

The library of code coming with zeptoforth includes support for the following:

  • Lambda expressions
  • VALUEs, 2VALUEs, and lexically-scoped local variables compatible with DO LOOPs
  • Implicit compilation, where conditional/looping constructs are temporarily compiled during intepretation mode, executed, and then forgotten
  • Closures
  • Dynamically-scoped, task-local variables
  • Double-cell and S31.32 fixed-point arithmetic, including the usual mathematical functions
  • SysTick
  • Interrupt-driven serial IO drivers
  • A simple GPIO abstraction layer that is maximally uniform across supported platforms
  • GPIO and, where applicable, EXTI drivers
  • Arbitrary UART support, beyond the console alone
  • ADC support
  • SPI support
  • SDHC/SDXC card support
  • FAT32 filesystem and MBR partition table on SDHC/SDXC cards support
  • Support for loading code from files in FAT32 filesystems
  • Rebooting via Control-C at the console, or Reboot in zeptocom.js
  • Attention key commands via Control-T at the console, or Attention in zeptocom.js; currently the only attention key commands are 'z', which sends an exception to the main task, and 't', which, when the task monitor is active, displays information on all running task
  • An optional task monitor (note that starting creates a task dedicated to it)
  • Preemptive multitasking
  • Action scheduling including synchronous messaging between actions on single tasks
  • A disassembler
  • Moving the exception vector table into RAM so it can be arbitrarily set
  • Task notifications
  • Semaphores
  • Locks
  • Signalling exceptions on other tasks
  • Message-oriented channels
  • Message-oriented rendezvous channels (aka "fchannels")
  • Message-oriented synchronous bidirectional reply channels (aka "rchannels")
  • Message-oriented ISR-friendly channels (aka "schannels")
  • Byte-oriented streams
  • Software alarms
  • Console redirection
  • Object-orientation
  • Maps, including counted string and integer-keyed maps
  • Temporary buffers
  • An allocator
  • Memory pools
  • Task pools
  • Action pools (for the single-task event scheduler)
  • A line editor
  • LED drivers
  • Random number generator drivers (except on STM32F411 "Black Pill" boards)
  • Pseudorandom number generation support (using the TinyMT32 PRNG)
  • Best-effort fault recovery
  • swdcom support for non-UART-based terminal support

On the Raspberry Pi Pico (and other compatible RP2040-based boards) and Raspberry Pi Pico 2 and Pimoroni Pico Plus 2 (and other compatible RP2350-based boards) it also supports the following:

  • An optional USB CDC console
  • Programmable input/output (PIO)
  • Hardware watchdog
  • I2C, in both master and slave modes
  • PWM, including both input and output
  • Hardware timers
  • Realtime clocks (note that on RP2350-based boards this is emulated using the Always-On Timer)
  • Multicore execution; note that this can be combined with multitasking on each core and multitasking constructs can be shared by both cores

On the Raspberry Pi Pico W it also supports the following:

  • An optional IPv4 stack for the Raspberry Pi Pico W, aka 'zeptoIP'.
  • An optional SNTP (Simple Network Time Protocol) implementation for use with zeptoIP

On The Raspberry Pi Pico 2 and Pimoroni Pico Plus 2 (and other compatible RP2350-based boards) it also supports the following:

  • The Always-On Timer, which counts time and may wake up the MCU as long as a small amount of power is applied

On the Pimoroni Pico Plus 2 (and other compatible RP2350-based boards with PSRAM) it also supports:

  • Up to 8 MiB of PSRAM

On the STM32F746 DISCOVERY board, the Raspberry Pi Pico and Raspberry Pi Pico W (and other compatible RP2040-based boards), and the Raspberry Pi Pico 2 and Pimoroni Pico Plus 2 (and other compatible RP2350-based boards) it also supports the following:

  • Quad SPI flash memory
  • A block interface
  • A block editor
  • FAT32 filesystems in block storage in Quad SPI flash

There is also optional support for

  • Single-cell...
Read more »

zeptoforth-1.8.1.2.tar.gz

This bug-fix release fixes an issue with the flash dictionary index on the RP2350 which would sometimes cause words to not be usable despite being listed by WORDS or WORDS-IN.

gzip - 23.46 MB - 09/27/2024 at 23:20

Download

  • 1 × A zeptoforth binary, whether just a kernel or one containing compiled Forth code (the latter is highly recommended)
  • 1 × A compatible board, such as the STM32L476 DISCOVERY, STM32F407 DISCOVERY, STM32F746 DISCOVERY, or Raspberry Pi Pico boards
  • 1 × A means to flash said board (e.g. ST-Link, or in the case of the DISCOVERY boards, a USB to USB Mini cable); in the case of the
  • 1 × A means to communicate with said board over serial or ST-Link (to enable the use of swdcom)

  • Bug-fix release 1.8.1.2

    Travis Bemann09/27/2024 at 23:21 0 comments

    This bug-fix release fixes an issue where certain specially-defined words such as words defined with defer would cause issues with the flash dictionary index on the RP2350, resulting in words sometimes not being usable despite being listed by words or words-in.

  • Bug-fix release 1.8.1.1

    Travis Bemann09/25/2024 at 03:13 0 comments

    This bug-fix release adds a maximum iteration counter to ln and lnp1 to avoid a bug where with certain inputs they would get caught in an infinite loop.

  • Patch-level release 1.8.1

    Travis Bemann09/25/2024 at 03:12 0 comments

    This patch-level release fixes a bug with UTF-8 handling in the line editor, and adds new line editor features including the ability to cut and paste text and reset the terminal.

  • Bug-fix release 1.8.0.1

    Travis Bemann09/25/2024 at 03:12 0 comments

    This bug-fix release fixes an issue on the RP2350 where init-psram would not properly discover the size of 8 MiB PSRAM chips and instead psram-size would report them as being 1 MiB. All other platforms are unchanged.

  • Minor release 1.8.0, now with RP2350 support

    Travis Bemann09/25/2024 at 03:11 0 comments

    This is the first non-pre-release release of zeptoforth with RP2350 support. Included in RP2350 support it adds support for 48 GPIO's (note that only 30 GPIO's, the same number as on the RP2040, are accessible on the RP2350A), a third PIO peripheral (with four extra state machines), four more PWM peripherals (with two channels per peripheral; note that only eight PWM peripherals, the same number as on the RP2040, are accessible on the RP2350A), a second hardware timer peripheral, the Always-On Timer (which is used to emulate the RTC provided by the RP2040, but with added support for millisecond resolution and multiple clock sources), and four more DMA channels relative to the feature set provided by the RP2040. It also adds optional support for PSRAM; note that this is only usable on RP2350 boards that include PSRAM, such as the Pimoroni Pico Plus 2. Note that HSTX is not currently supported, but may be supported in a future release.

    Also note that there are a number of minor bugfixes and additions to things other than RP2350 support, such as fixing bugs in zeptoed and improving the DMA API on the RP2040 in addition to the API exposed on the RP2350.

    Note that there are no separate "non-big" and "big" builds for the RP2350; all RP2350 builds allot 4 KiB to the bootloader, 36 KiB to the kernel, 1912 KiB to the flash dictionary, 92 KiB to the flash dictionary index (the "mini-dictionary"), and 2 MiB to block/FAT32 filesystem storage.

  • Beta release 1.8.0-beta.0

    Travis Bemann09/11/2024 at 04:38 0 comments

    This is an initial beta release of zeptoforth with RP2350 support. Note that this release fixes a bug in init-psram where it would cause the MCU to lock up requiring a hardware reset if it were called after the second core of the RP2350 was started.

  • Alpha release 1.8.0-alpha.6

    Travis Bemann09/10/2024 at 03:47 0 comments

    This alpha release introduces PSRAM support for the RP2350 on boards that have PSRAM. Note that the user must manually enable PSRAM support, as it requires supplying the identity of the QMI CS1n GPIO to use.

  • Alpha release 1.8.0-alpha.5

    Travis Bemann09/08/2024 at 22:44 0 comments

    This alpha release fixes rng::random, which had previously been broken on the rp2350 platform.

  • Alpha release 1.8.0-alpha.4

    Travis Bemann09/07/2024 at 04:02 0 comments

    This alpha release fixes bugs in the pin module on the rp2350 platform where calling pull-up-pin, pull-down-pin, or floating-pin would cause hardfaults.

  • Alpha release 1.8.0-alpha.3

    Travis Bemann09/02/2024 at 17:13 0 comments

    This alpha release fixes an issue with the disassembler on platforms supporting Thumb-2 instructions (e.g. RP2350) where previously certain instructions and especially non-instructions (e.g. unprogrammed flash filled with $FF bytes) would cause a hardfault on disassembly.

View all 257 project logs

Enjoy this project?

Share

Discussions

Peter wrote 06/29/2024 at 10:17 point

I have just submitted my project 4TH Calculator https://hackaday.io/project/196655-4th-calculator to the Hackaday Business Card Contest. 

That's when I saw your Zeptoforth. Really cool. You did many things the same way I did for Mecrisp-Cube. I am still hooked on Mecrisp but I will try your Zeptoforth.

  Are you sure? yes | no

Travis Bemann wrote 06/29/2024 at 17:44 point

Your 4TH Calculator project looks very cool - nice job! And Mecrisp-Cube seems quite nice in that it enables combining Mecrisp-Stellaris (which has an awesome code generator ─ Matthias is a compilers wizard) with FreeRTOS (which inspired many features of zeptoforth, actually). Also, your Mecrisp-Cube supports mixing Forth and C code, which has its advantages, whereas my zeptoforth is designed specifically for Forth and assembly. (I probably would not have written my own IPv4 stack for the Pico W had lwip been an option for zeptoforth.)


Of course, I always like it when people try out zeptoforth. Conversely, I should try out Mecrisp-Cube sometime. BTW, if you ever think of creating a similar device that runs zeptoforth I would be more than happy :D. You *could* use an STM32 processor for that (as zeptoforth has support for the STM32F407 and STM32F746 amongst others), but zeptoforth is best suited to the RP2040, which it has very good support for. (For instance, zeptoforth supports a wider range of peripherals out of the box on the RP2040 than on STM32 platforms, and it also supports both cores of the RP2040 effortlessly, and can compile to and execute code out of QSPI flash rather than only being able to use QSPI flash to store fixed-sized images (it can also use QSPI flash for block storage, if that is your cup of tea).)


(The main reason I see to use, say, the STM32F407 or STM32F746 here with zeptoforth is if you want hardware floating-point support, because the math that comes with zeptoforth is either integer or fixed-point (either 64-bit or, optionally, 32-bit fixed point), and while floating point is available on the RP2040, it is implemented in software in ROM.)

  Are you sure? yes | no

zyndram wrote 06/11/2023 at 12:14 point

Can You create a working device with screen, keyboard, network (irda) and usb?

for example working time on one charge a month

  Are you sure? yes | no

Travis Bemann wrote 06/11/2023 at 17:01 point

As for USB, on the RP2040 it supports USB CDC as a console, in the place of a serial console. Note that this is as a USB slave rather than host, so it has no way of communicating as a host with its own slaves (such as keyboards or mice).

As for displays, it currently has optional support on the RP2040 for I2C SSD1306-based monochrome bitmap OLED screens, and this could be extended to other bitmap screens such as those old Nokia ones. If you want support for VGA-based displays you could implement something using PIO, as this has been done before using that.

As for networking, there are no plans to support IrDA - even though you could implement support for an IrDA peripheral on one of the STM32 platforms. However, I am currently at work on a driver for the CYW43439 WiFi chip on the RPi Pico W. Note though that it will be a while until I get WiFi support working since even when I get my driver working I will need to implement an IP stack using it.

  Are you sure? yes | no

villaromba wrote 01/25/2023 at 15:49 point

On a PICO what RTC are you using and to what pins on the PICO, also what pins for the SD CARD. I'm thinking of using the Maker Pi Pico (Cytron) which I already have. So the SD pins are fixed so where do I tell Forth where it is connected?

  Are you sure? yes | no

Travis Bemann wrote 01/25/2023 at 21:18 point

On the Pico I am using the RP2040's on-chip RTC using the 12 MHz XOSC crystal. There is a pin for a separate crystal, GPIO 20, but this is not supported currently by zeptoforth.

  Are you sure? yes | no

teraz wrote 05/05/2022 at 10:37 point

please add password for loging (meybe OTP)

password and hardware switch for replace firmware

  Are you sure? yes | no

Travis Bemann wrote 05/06/2022 at 13:51 point

What do you mean? zeptoforth has no logging independent of what it writes to serial. Also, about securing the firmware, zeptoforth has zero built-in security by design, and even if it did, the only way to prevent writing to firmware via SWD on some platforms would be to set bits to lock out SWD, and to my knowledge there is no means to lock out uploading firmware via the USB mass storage device on the Raspberry Pi Pico.

  Are you sure? yes | no

teraz wrote 05/07/2022 at 12:21 point

I see console, i need password protect for no everyone can write in console/terminal

  Are you sure? yes | no

Travis Bemann wrote 05/07/2022 at 16:17 point

If you want to lock out the console on bootup except for someone entering a password I would recommend something like:

compile-to-flash

: hash ( c-addr u -- x ) ( add your hash algorithm here ) ;

: init ( -- )

    init

    begin

        cr ." Password: " refill token ?dup if

            hash [ s" your-password" hash ] literal =

        else drop false then

   until

;

Replace your-password with the password you intend to use (because it is hashed at compile-time this password will not be in the compiled code in flash). Also replace the hash algorithm with something sane; for testing purposes I used:

: hash ( c-addr u -- x ) 0 0 -rot ?do dup 7 lshift swap 25 rshift or over c@ xor swap 1+ swap loop nip ;

However, that's not secure by any means. (Note that truly using a secure hash rather than just 32 bits of it would require significant modifications of the above code.

Also note that this will only keep out the most basic of attackers, because there is nothing stopping them from simply reflashing the whole board or reaching into the board with SWD (some MCU's have bits for locking out SWD but these are MCU-specific and i am not familiar with the operation of these myself).

Also note that this must be compiled after any other implementations of init or otherwise these will execute (provided they follow the convention of each init calling the init before it before doing its operations) after the password is entered successfully.

  Are you sure? yes | no

teraz wrote 05/19/2022 at 21:18 point

this is not otp

  Are you sure? yes | no

Travis Bemann wrote 05/20/2022 at 01:19 point

Well, anything truly OTP will be very hardware-specific. What I gave there was a general solution to passwording zeptoforth, not a means to permanently lock the user out of the device. Some devices, such as the RPi Pico, have no OTP capability in the first place.

  Are you sure? yes | no

Thomas wrote 04/13/2020 at 08:01 point

I like the story behind your project a lot! Since you're using e4thcom some of Manfred Marlow's approaches to the little Forth I'm maintaining might also be useful for your Forth. Also it's quite possible that my codeload.py works with minor adaptations :-)

  Are you sure? yes | no

Travis Bemann wrote 04/13/2020 at 12:05 point

The main adaptation that would be needed is that it would need to wait until it receives ACK to send another line of code, and it would need to treat NAK as an indicator of an error indicating to stop ending any more data. This is why with e4thcom it is used in noforth mode, because noforth behaves in this fashion.

  Are you sure? yes | no

Thomas wrote 04/13/2020 at 16:09 point

I remember I had a long discussion with Manfred about ACK/NACK vs. OK/? - he didn't like the solution he made for noforth too much and made a point of using the "human readable" handshake with OK and ? (for error). What's your reason for using ACK/NACK?

  Are you sure? yes | no

Travis Bemann wrote 04/13/2020 at 18:28 point

My reason to do ACK and NAK is that it would signal success versus failure without relying on the textual content of what is output - in zeptoforth an exception can really result in anything being output while ACK and NAK could be transparently added to all prompts and all errors without any further changes being necessary - and there was a premade mode in e4thcom to use ACK and NAK.

(Note that I am responding to this post because hackaday.io is not letting me reply to your other post.)

  Are you sure? yes | no

Thomas wrote 04/16/2020 at 18:55 point

I didn't notice your reply, sorry. Hint: in HaD discussions you can simply reply to the post someone else replied to.

OK, now I understand your preferences. When I started this I first tried to work with an XON/XOFF handshake, at least until I figured the following out about USB-serial converters on Linux: https://github.com/neundorf/CuteCom/issues/22 

  Are you sure? yes | no

Travis Bemann wrote 04/17/2020 at 15:05 point

Personally I would prefer hardware flow control, but unfortunately the USB-serial dongle I am using to communicate with the STM32F407 DISCOVERY board lacks pins for RTS/CTS, and the serial over USB connection built into the STM32L476 DISCOVERY board has no option for hardware flow control in the first place.

  Are you sure? yes | no

Travis Bemann wrote 04/16/2020 at 18:01 point

I looked at the code for codeload.py and noticed that is coded for Python 2.7, which is no longer maintained. Could you do a port for Python 3? This could be very useful for people who do not run Linux (and thus e4thcom is not a feasible option, as apparently people have not had luck with FreeBSD's Linux compatibility layer with it). (I could add more screen support for also adding XON and XOFF, but screen still would not support loading files from within other files with anything like #include or #require.)

  Are you sure? yes | no

Thomas wrote 04/16/2020 at 18:39 point

Sure I can port it to Python 3 :-) To be honest, when I wrote it I didn't know much Python and 2.7 was the default on the Ubuntu 14.04 I was using then.

Do you know of anyone who uses the e4thcom 64bit binary on WSL 2?

  Are you sure? yes | no

Travis Bemann wrote 04/17/2020 at 14:51 point

I have not heard of anyone trying 64-bit e4thcom with WSL 2, but then, I have not heard of anyone who has used WSL 2 in the first place. Most of the people I know in #forth on freenode are either Linux (and not Linux on top of Windows) or BSD users.

  Are you sure? yes | no

Thomas wrote 04/18/2020 at 08:50 point

I gave it a try. It appears to work but it's not fully tested:

https://gist.github.com/TG9541/0b48bd49854cc865469515697b5185f6

  Are you sure? yes | no

Thomas wrote 04/18/2020 at 13:01 point

I tried telnet to ucSim with the python3 variant - Python3 "byte array vs. str"  issues, of coursed. Unfortunately I get timeouts after fixing it. That's very difficult to debug. The serial interface transfer, which is likely the one you're most interested in, should work anyway.

  Are you sure? yes | no

Travis Bemann wrote 04/19/2020 at 16:19 point

Could you add a copyright notice and license block to codeload3.py so I can incorporate it, with some minor modifications, to the zeptoforth codebase? I should note that there is no such thing as the public domain in Germany.

  Are you sure? yes | no

Thomas wrote 04/19/2020 at 18:24 point

Sure, I'll do that. MIT is OK, I s'pose?

Edit: done

  Are you sure? yes | no

Travis Bemann wrote 04/19/2020 at 18:52 point

That would work, particularly since the MIT license is GPL-compatible.

  Are you sure? yes | no

Travis Bemann wrote 04/19/2020 at 21:41 point

I put my changes to codeload3.py to make it work with zeptoforth in my fork of your gist, and I will include this with zeptoforth so users can upload code without relying on e4thcom.

  Are you sure? yes | no

Elliot Williams wrote 04/13/2020 at 07:41 point

Cool!  Going to have to check this out.  

Lemme see if I have a 407 Disco around here somewhere...

I agree that Forth misses lambdas, just b/c it's hard to think up good names all the time.    

Although on multitasking/timers, honestly, I end up just writing "begin do_something 100 ms again", which works as well, if your "ms" definition has a "yield" in it.  But this keeps the chip from going into a low-power mode, b/c it's always round-robinning into delay statements.  If the scheduler knew...  

So yeah.  I'm going to have a peek at your multitasking setup.

  Are you sure? yes | no

Travis Bemann wrote 04/13/2020 at 12:00 point

I would appreciate more people trying it out, even though that requires their owning the same hardware as myself. (It is hard for me to maintain the code for hardware I do not own, e.g. I cannot create zeptoforth_full binaries without physically owning the hardware in question.)

Lambdas are a feature missing, unfortunately, from most Forths, even though there are a few with them, such as Retro (of course Retro is not a conventional Forth by any means).

The multitasker is designed to put the MCU to sleep when no task is actively executing, even though it wakes up the processor when a SysTick occurs, when a byte is received over a USART, or, if data is pending in the serial TX circular buffer and the USART TX shift register becomes free. So if one writes:

: foo begin do-baz 100 ms again ;

' foo 256 256 256 spawn constant foo-task

foo-task task-enable

it will sleep the MCU, aside from it getting woken up by SysTicks and by any input the user feeds into the REPL.

  Are you sure? yes | no

Travis Bemann wrote 04/18/2020 at 17:37 point

You said you might try it out on the F407. If you had any problems with the zeptoforth_full-[version].bin file for the F407, there were issues with it being corrupt, so try it out with the latest release binaries, where I made sure to check that it now works.

  Are you sure? yes | no

crun wrote 04/12/2020 at 20:44 point

Could you explain why vs mecrisp?

Re M0, you say "it relies on key features of the Thumb-2 instruction set which are missing from the Thumb-2 instruction set". Could you clarify?

  Are you sure? yes | no

Travis Bemann wrote 04/12/2020 at 21:22 point

To be completely honest, it fits much of the same niche as Mecrisp-Stellaris, but there being one Forth for a platform has not stopped anyone from making another (e.g. there already was a Cortex-M Forth before Mecrisp-Stellaris, namely Riscy Pygness). This project exists largely because I wanted to create a bare-metal native code embedded Forth of my own, and the STM32L4 and STM32F4 series microcontrollers were an attractive target, big enough to fit a good-sized Forth with plenty of room to spare, with good documentation for peripherals, and without being effectively a PC on a chip (e.g. the Raspberry Pi boards) with peripherals that may require proprietary binary blobs and thus not amenable to development by an individual such as myself.

About the M0, the issue is that 32-bit literals are difficult to implement without 16-bit low and 16-bit high immediate MOV/MOVT instructions, and while I tried to implement literals that use a mixture of MOVS, LSLS, and ORRS instructions the problem is that when allocating space for a literal ahead of time, and then writing to it later, it is hard to predict how long that sequence of instructions will be (unless one assumes the very longest length and then fills out the rest of the space with NOPs). So as a result I am focusing on Cortex-M3/M4 for now, and will  implement support for the Cortex-M0 later if I see the need for it.

  Are you sure? yes | no

crun wrote 06/10/2020 at 07:35 point

Looking into M4 because of the dsp floating point performance. So 4th for the little F411 dip boards would be ok with me.  Interesting how to integrate Forth with the arm dsp libraries though.

  Are you sure? yes | no

alessandro.cordova wrote 04/11/2020 at 17:43 point

Amazing

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates