Replies: 7 comments 4 replies
-
|
On Fri, Nov 21, 2025, 11:42 ctmalan ***@***.***> wrote:
I need advice on running Meshtastic and zeptoforth on the same RP2040. The
goal is to dedicate one core to each system, but I’m not sure about the
best way to manage core assignment and communication between them.
Here’s what I want to achieve:
1. Run Meshtastic on one core and zeptoforth on the other.
2. Be able to update and execute Forth code via Meshtastic messages by
using | as the first character (for example, |1 1 + .). The output
should be returned as a Meshtastic reply message.
3. Access MQTT publish functionality through Meshtastic from the Forth
side.
4. Decide whether to use the RP2040 inter-core FIFO or another
communication method for passing messages between Meshtastic and zeptoforth.
5. Decide whether I should delimit MQTT messages using { for JSON
payload parsing.
6. Decide whether I should rather switch to the Pico 2 W instead of
Pico W / Pico.
Questions:
- Has anyone tried combining Meshtastic with a Forth environment like
zeptoforth or Mecrisp?
- Does anyone else need this or have similar ideas?
- Should I rely on the RP2040 inter-core channel (FIFO) for
communication, or is shared RAM safer?
- Any recommendations for cleanly routing MQTT through Meshtastic
toward the Forth environment?
- Thoughts on MQTT message framing (e.g., JSON {…} as delimiters)?
- Is the Pico 2 W a better hardware choice for this?
I will first draft a plan and add comments on GitHub before proceeding,
but I’d really appreciate feedback from anyone who has tried something
similar or has experience with dual-core RP2040 firmware architecture.
Any suggestions would be extremely helpful.
c-:
To my knowledge, nothing like this has ever been tried with zeptoforth, and
pulling this off would require extensive modifications to zeptoforth as
zeptoforth expects to control both CPU's and all RAM and flash on the board.
If you were to try this the first thing I would do is modify zeptoforth on
the RP2040 or RP2350 to operate in a purely single-core fashion, without it
using the hardware FIFO's or spinlocks for its own purposes. This is not a
simple task! Then I would modify its memory map to allot a fixed block of
memory for Meshtastic to operate in. After that, I would create a separate
vector table for Meshtastic on the second core.
As for communication between zeptoforth and Meshtastic, I would use memory
buffers in the form of lockless circular buffers.
As for RP2040 (Pico, Pico W) versus RP2350 (Pico 2, Pico 2W), I would
always go with the RP2350 -- you get much more SRAM and a much faster CPU
clock for clock. Actually, for the RP2350 I would recommend getting a
Pimoroni Pico Plus 2W -- it is like a Pico 2W but with 16 MiB rather than 4
MiB of flash and it has 8 MiB of PSRAM.
Travis
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Many thanks for your excellent comment. In summary it seems that another Forth, such as Mecrisp or Mecrisp-cube might be better far easier as it is already single-threaded? Can you recommend one? |
Beta Was this translation helpful? Give feedback.
-
|
On Sat, Nov 22, 2025 at 3:04 AM ctmalan ***@***.***> wrote:
Many thanks for your excellent comment.
In summary it seems that another forth, such as Mecrisp or Mecrisp-cube
might be better far easier as it is already single-threaded? Can you
recommend one?
You could try Mecrisp-Stellaris for the RP2040; it may still need some
modification of course. Also note that it indeed does not support
preemptive multitasking. In addition, it does not have many of the extra
amenities zeptoforth provides.
For the RP2350 there are no other good options aside from extensively
modifying zeptoforth; while there is Mecrisp-Quintus support for the
RP2350, it is extremely rudimentary (last time I checked it could not even
write to flash).
Travis
… Message ID: <tabemann/zeptoforth/repo-discussions/258/comments/15045118@
github.com>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
FWIW I have use quintus and it works fine, and can write to flash IIRC. I also added multi processor support which is checked into main. |
Beta Was this translation helpful? Give feedback.
-
|
On Sat, Nov 22, 2025, 08:20 Jim Morris ***@***.***> wrote:
FWIW I have use quintus and it works fine, and can write to flash IIRC. I
also added multi processor support which is checked into main.
Oh, so Quintus has been improved since last time I looked at it then.
The fundamental issue here, though, is *removing* multiprocessor support so
Meshtastic can have a core all to itself without interference from the
Forth side of things.
In the case of zeptoforth I simply had not foreseen a use case where one
would want to limit zeptoforth on the RP2040 or RP2350 to running on one
core.
Note, however, removing multiprocessor support from zeptoforth so as to
free the second core up for another application, in this case Meshtastic,
is by no means impossible, as zeptoforth has baked-in support for
single-processor platforms (e.g. the STM32F407). It just requires some
surgery to the source code (e.g. replacing src/rp2040/forth/multicore.fs or
src/rp2350/forth/multicore.fs with src/common/forth/multicore.fs).
Travis
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On Sat, Nov 22, 2025 at 10:25 AM Travis Bemann ***@***.***> wrote:
On Sat, Nov 22, 2025, 08:20 Jim Morris ***@***.***> wrote:
> FWIW I have use quintus and it works fine, and can write to flash IIRC. I
> also added multi processor support which is checked into main.
>
Oh, so Quintus has been improved since last time I looked at it then.
The fundamental issue here, though, is *removing* multiprocessor support
so Meshtastic can have a core all to itself without interference from the
Forth side of things.
In the case of zeptoforth I simply had not foreseen a use case where one
would want to limit zeptoforth on the RP2040 or RP2350 to running on one
core.
Note, however, removing multiprocessor support from zeptoforth so as to
free the second core up for another application, in this case Meshtastic,
is by no means impossible, as zeptoforth has baked-in support for
single-processor platforms (e.g. the STM32F407). It just requires some
surgery to the source code (e.g. replacing src/rp2040/forth/multicore.fs
or src/rp2350/forth/multicore.fs with src/common/forth/multicore.fs).
I have decided to bite the bullet and implement versions of zeptoforth
which only use one core of the RP2040 and RP2350. I have gotten the RP2040
version working in a very preliminary fashion (i.e. all I have tested is
that it boots, that I can run two tasks on core 0 side by side, one which
provides the REPL and one which prints asterisks to the USB console, and
that it raises an exception if I attempt to run a task on core 1); note
that I have not seen any reason to believe that it will not work in
general. Right now I am busy compiling an equivalent version for the RP2350
as well. I should be able to push this preliminary code to the repo tonight
if all goes well.
Travis
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On Sat, Nov 22, 2025 at 8:01 PM Travis Bemann ***@***.***> wrote:
On Sat, Nov 22, 2025 at 10:25 AM Travis Bemann ***@***.***> wrote:
> On Sat, Nov 22, 2025, 08:20 Jim Morris ***@***.***> wrote:
>
>> FWIW I have use quintus and it works fine, and can write to flash IIRC.
>> I also added multi processor support which is checked into main.
>>
>
>
> Oh, so Quintus has been improved since last time I looked at it then.
>
> The fundamental issue here, though, is *removing* multiprocessor support
> so Meshtastic can have a core all to itself without interference from the
> Forth side of things.
>
> In the case of zeptoforth I simply had not foreseen a use case where one
> would want to limit zeptoforth on the RP2040 or RP2350 to running on one
> core.
>
> Note, however, removing multiprocessor support from zeptoforth so as to
> free the second core up for another application, in this case Meshtastic,
> is by no means impossible, as zeptoforth has baked-in support for
> single-processor platforms (e.g. the STM32F407). It just requires some
> surgery to the source code (e.g. replacing src/rp2040/forth/multicore.fs
> or src/rp2350/forth/multicore.fs with src/common/forth/multicore.fs).
>
I have decided to bite the bullet and implement versions of zeptoforth
which only use one core of the RP2040 and RP2350. I have gotten the RP2040
version working in a very preliminary fashion (i.e. all I have tested is
that it boots, that I can run two tasks on core 0 side by side, one which
provides the REPL and one which prints asterisks to the USB console, and
that it raises an exception if I attempt to run a task on core 1); note
that I have not seen any reason to believe that it will not work in
general. Right now I am busy compiling an equivalent version for the RP2350
as well. I should be able to push this preliminary code to the repo tonight
if all goes well.
I have now done preliminary testing of the RP2350 version, and it also
works similarly. Note that I have not tested starting an independent
application on the second core, mind you.
The code is at https://github.com/tabemann/zeptoforth/tree/single-core-devel
.
Travis
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Wow, Travis, this is not at all what I expected. Many thanks, I will test soonest!c-: |
Beta Was this translation helpful? Give feedback.
-
|
You're welcome!
Note that the single-core platforms are named similarly to their normal
dual-core counterparts but have '1core' in their names.
Also note that the word to launch an application on the second core is
CORE1::LAUNCH-CORE1 .
Travis
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
I will need to run Meshtatic with WiFi on core0. Is it possible to run zeptoforth on core1? |
Beta Was this translation helpful? Give feedback.
-
|
On Tue, Nov 25, 2025, 04:18 ctmalan ***@***.***> wrote:
I will need to run Meshtatic with WiFi on core0. Is it possible to run
zeptoforth on core1?
zeptoforth is designed to be directly booted into, and core 0 always boots
first. Is it _impossible_ to launch Meshtastic as a child application on
core 1? It seems to me that switching zeptoforth from core 0 to core 1 at
runtime would be quite difficult to implement, as would modifying
zeptoforth to run as a child application on core 1.
Travis
… |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I need advice on running Meshtastic and zeptoforth on the same RP2040. The goal is to dedicate one core to each system, but I’m not sure about the best way to manage core assignment and communication between them.
Here’s what I want to achieve:
|as the first character (for example,|1 1 + .). The output should be returned as a Meshtastic reply message.{for JSON payload parsing.Questions:
{…}as delimiters)?I will first draft a plan and add comments on GitHub before proceeding, but I’d really appreciate feedback from anyone who has tried something similar or has experience with dual-core RP2040 firmware architecture.
Any suggestions would be extremely helpful.
c-:
Beta Was this translation helpful? Give feedback.
All reactions