you can actively stop a loop, reprogram a “function” and restart your loop.[..]
can a PRECOMPILED upgrade of those functions *or words* be sent to a
FORTH system without interacting with the forth console?
On Wednesday, September 7, 2022 at 4:32:15 PM UTC+2, jem...@gmail.com wrote: [..]
you can actively stop a loop, reprogram a “function” and restart your loop.[..]
I assume you have a main word A with that big loop inside of it. Inside this loop
a word named B is called. Something stops A, writes / uploads a new definition
named B, and executes A to restart the loop.
No, this will not work as if the new B replaces the old B, unless run on a Jupiter Ace. However, when B is a deferred word, then ": new_b ... ; IS B A" would work on any Forth without dirty tricks. (I'm sure somebody is
going to teach you that dirty trick now).
Hi all, I’m new to Forth after rediscovering it on embedded systems.reprogram a “function” and restart your loop. Which is why most MCU’s get a FW upgrade, they are basically refactoring or adding functions to a loop of tasks or functions…
I have a quick idea vision I was wondering if any of the Forth builders are considering.
Let me start with the vision, I found that one of the biggest value for Forth as part if interactivity with the the little systems was the fact that one can basically do this magic (I say that with my C hat on) where you can actively stop a loop,
OK, so here is the idea, how can one automate this in a way there you add a upgrade task to your loop to enable OTA upgrades… here I’m really considering, can a PRECOMPILED upgrade of those functions *or words* be sent to a FORTH system withoutinteracting with the forth console?
Like I said, I’m still learning Forth, but it would certainly just trigger an update to the dictionary, same as the ; does…be a PITA. This type of system could benefit massively with these “simple” updates at scale. Even at say, 4MB Full RTOS + App, is a very large waste of bandwidth… vs say tens of kilobytes with that I’m envisioning.
Here os a problem (no not one I’m working on or considering but a really problem non the less) your electric meter, that is one of the most common IOT device out there, seen that those range in the billions, upgrading those with even large pipes must
The other problem to that coin is, there are probably many targets types or versions of the MCU’s, so as a reference, consider you are developing in a tethered Forth environment where you are actively testing gains all your target types on a singlecode base. You can keep all your *includes* for each target separate, they are just the HAL, but your app is a single source.
For me, in general, I’m working on STM32 *3 different flavors* PIC24 and AVR MEGA and Dx to that, I’m adding M0+ *RP2040 and RISC/V which will be like another multiple chip from an architecture perspective, just like the M0 and M0+ variances. I’dlike to target these different MCU within a single code base. Sure I still have to maned the HAL drivers/Compilers, but it would be interesting.
It looks like there is something similar to this tethered option, MikroForth looks like it has the basis of what this would be the Ideal IDE only if it supported all these targets.
Thought, counter, or pointing me in project that is set out to this would be great.
Cheers!
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 475 |
Nodes: | 16 (2 / 14) |
Uptime: | 18:52:13 |
Calls: | 9,487 |
Calls today: | 6 |
Files: | 13,617 |
Messages: | 6,121,093 |