¿ªÔÆÌåÓý

  1. BITX20
  2. Messages
Single Messages Topics Expanded Polls

Re: Trouble ahead

 

Tom

Very interesting questions.? I have to admit that going back to Forth might be
painful, even for us older and long past users of the language.? I do have an
Arduino with a TF card socket and a couple of 512 GB TF cards.? That was
installed to support work on building a way to page external executables from
the TF card into flash memory.? The experiment failed...not because it is not
possible but because I reached my own MLI (Maximum level of Incompetence).?
The project is still in my files in case I want to resurrect it.? Jack and myself
touched on it briefly but it was just a question or two.

More recently I have been working on a pico-OS and scripting environment
for the Arduino.? It works but still has a way to go before going public with it.?
While working on that OS idea it became very apparent that the OS could
very easily be made into an RT (Real-Time OS) by simply using the AVR/Arduino
microsecond timer to build out each routine called by the main loop to a
fixed execution time by adding delay to make each routine comply with the RT
granularity.?

FYI This idea started out to be an April 1st article but it quickly became
obvious that it did have some real potential.

Using the standard Arduino IDE layout for a sketch with conventional
"void startup" and "void loop"? makes up the basis for the static and dynamic
parts of the OS.
---------------------------------------

? /* pico-OS.uno
?* ?Arvid Evans K7HKL
?* ?1 April 2021
?*/
? ?
?*/void setup() {
? // put your setup code here, to run once:
? // this becomes the OS BIOS and BOOT section.
? // all variables are defined here and all are global
? // to avoid needing garbage collection.
}

void loop() {
? // put your main code here, to run repeatedly:
? // put calls to applications here inside this loop.
? // time them and build out each call to match RT granularity.
}

/* DEVELOPER MANUAL:
?* ?The "void loop" part is the core of the OS. ?
?* ?All variables are Global (avoids needing a garbage collector).
?* ?
?* ?The main loop will contain "long int loop_Start" from AVR
?* ?microsecond clock and "long int loop_End" which allows DEBUG
?* ?mode timing of each run around the loop.
?* ?
?* ?"int DEBUG can be set to any value from zero (DEBUG = OFF)
?* ?to the total number of callable routines in the main loop.
?* ?This allows each routine to have DEBUG ON or OFF for that
?* ?particular routine.? Negative DEBUG modes are global, while
?* ?positive DEBUG values are routine specific.
?* ?
?* ?Each callable routine will have a start value from the AVR
?* ?microseconds clock and an end value which allows calculation
?* ?of the delay build-out to match RT granularity.
?* ?
?* ?Each callable routine in the main loop will do one thing and
?* ?one thing only to keep it small and fast. ?ie, (getting ?
?* ?characters from an attached terminal reads one character only
?* ?per pass around the main loop, and adds that character to a
?* ?"char keyboardBuffer" until it receives a Carriage Return,
?* ?which causes it to process the command stored in
?* ?"keyboardBuffer).? Other callable routines from the main loop
?* ?work in a similar fashion.? This helps with RT granularity and
?* ?makes each transition of the main loop go very fast.
?* ?
?* ?If using C++ routines found in arduino.h, there may be situations
?* ?where a small and direct Garbage Collection Routine
?*? may become necessary.? Only time and use of the C++
?*? routines can be used to determine if this is necessary.
?* ?
?* ?The user interface or "shell-s script" language has yet to be
?* ?determined.? It may be a partial implementation of the Bourne
?* ?Shell, a Python based shell, or something that is yet to be
?* ?designed and built.
?* ?
?* ?*/

?/* USER MANUAL:
? * ?Yet to be written.
? */ ?

---------------------------------------

Still lots of work to be done.? Will post more when it is finished...or fails.

Arv
_._


On Mon, Mar 22, 2021 at 8:45 PM Tom, wb6b <wb6b@...> wrote:
All this talk about FORTH makes me wonder.

I wonder if SD card reads, with the Nano for instance, could be optimized well enough that running FORTH byte code from a SD card would be fast enough for many projects.?

Just add a SD card connector and suddenly there would be vast amounts of space for code. Or even one of those 99 cent multi megabyte serial flash chips.

Many of us already have a SD card in some of our projects by virtual of having a TFT display, with a tag along SD card connector included. ?

Then that starts thinking about the more general case of languages that compile to "P" code. How efficient are P byte code interpreter loops compared to a FORTH byte code interpreter loop. Is one more magically efficient than the other.?

Because we all likely have ATMega328 and close relatives AVR processors in our parts boxes, it is fun to think of ways to extend their usefulness at low cost.?

Here is a random C to FORTH complier I found on Github.


Tom, wb6b

Join [email protected] to automatically receive all group messages.