Colaborate on a beginner friendly real-time tasking system?

Community Jobs and Paid Consultancy
1

The project would be able to run on an Uno, the user interact through serial monitor or a VT-100 emulator. (VT-100 text screen control allows way more display and key entry options)

The user can start tasks running from a menu of supported types to be configured. Once started the task continues to run and the user may interact with it also through menu choices.. always the legal options get shown.

Examples of tasks are of course button and led (and all hardware I/O). Processes are less cut and dry.

I want to keep variables internal to task objects as properties. An object that does output, like a button, should have output variable(s) that it keeps updated. An object that does input should have link(s) to point to output variable(s) to be read. These things must show up in user task configuration menus for all task objects.
Note that a led task could have an input link directly to a button task status output. Next add a timer process task with input link set to the button status and link the output value of that to led to get a non-blocking delay without writing code.
But perhaps I can merge process tasks by letting the user add timer, counter, etc, as the do part?

For processes, I start with when (not if, when fits the approach better) condition do xxxx as the first and then add timers, repeats, timed repeats, countdowns and call states modes in a modal task with timer menu choice.

The condition above are so far output variables (linked to or local) and constants used in logical operations, ex: when button status == 2 do xxxx (not set on this).

I'm still trying to frame this right to give beginners the ability to set up and run simple operations without knowing the details just to see how the pieces can fit and work together. I could make something very flexible that would not be easy for beginners.

2

I've done something like this a few times in my life (not on the Arduino). My experience has been so far that the complexity of the RTOS tends to overshadow the gains. Maybe publish your tentative library and some examples of using it? So far it is a bit hypothetical. :slight_smile:

3

I've just about settled on a system for processes, which you've seen but isn't posted above.

I'm trying to not get down to code just to find out "it should do Z" that I hadn't thought of.

What I have figured out so far avoids being over-complex but from experience, trying to incorporate numerous exceptions to an original plan pretty much guarantees mass complexity.

Input and output will not be user-customizable except what they link to. Best word I can think for them is "drivers". The user will choose them and set them up.

Process tasks will be sequences of pre-written functions chosen by the user.

All tasks will be C++ Class objects. Variables will be internal if possible, the users I have in mind should not be wanting to play with arrays on their own. That doesn't mean there can't be arrays but they won't be user-managed.

Overhead:

The 1st task is linked to by the system and every added task is linked to by the task before it.
Every task runs every time loop() runs.

Within process tasks, an array of function numbers to run and an index into that list.
Each function is pre-defined and runs non-blocking. When it exits the next task is run, not the next function.
As each function runs the index may or may not change, a function with a loop or wait runs over until finished.

I'm trying to avoid using the function indexes to perform jumps but may have to.

For the WHEN function, if the conditional is true it advances the function index else it doesn't, exit task.
Just how REPEAT will work or how state/modal machines get in there I haven't simpled out yet.

A lot could be done by allowing what beginners and non-programmers don't/can't deal with. If they were up to inventing with bags of tricks they'd be writing C in the time it would take to learn a slightly simpler system. So far the idea is that needs as complicated as iterating through arrays have to be handled by system functions and IO tasks written for the purpose.

It doesn't need to do everything but it can do a lot. Mostly it's to get beginners to see the woods without getting lost in the trees and have enough to do basic automation. Those who want more may reach and do so knowing more from an overall view.

4

Right now with what I'm solid about the user can:

Connect inputs to outputs direct.

Connect inputs to outputs with wait.

Connect inputs to outputs on event/condition with or w/o wait.

I expect to need a repeat function for "do this X times".

I'm working on how to present a state machine as steps or modes.

I really really really need ideas on what the user should see or be able to do for basic automation tasks.

Nick, I did a bit of this kind of thing back in my day too. I don't stray far from what I know can work. The bigger parts will be built-in trace logging (Not a dream, I've already done so on a 2014 Arduino greenhouse project, worked out the techniques, got the code but it does run on a Mega.), help and friendly docs.

5

Sounds a bit like my idler code. I have a dynamic global list of objects derived from class idler and they all get a call each time through the loop.

Makes doing concurrent things REALLY easy.

loop() {

   idle();

   other stuff
}

Your plan seems more structured with all this input output . I'm having trouble understanding how that helps. What kind of problem does this solve?

-jim lee

6

It is to let beginners set up and run non-blocking task-oriented automation without having to deal with the code details.

Right now I could use ideas on this level:
Connect inputs to outputs -- direct.
Connect inputs to outputs -- with wait.
Connect inputs to outputs -- on event/condition with or w/o wait.

I can see need for repeated actions, "do this X times" in a way to not just blink X times but also count X button presses before running the next function in that task. The repeater ideas I've been thinking of will let one task set up a count for another to trigger on X times.

I can see need for simple state machine and am trying to figure out how to make that not scare beginner users beginning with not using the name "state machine" and referring to "steps" or "modes" that a process goes through.

I don't want the user to have to know as much as I can get away with the user not knowing. Maybe I have enough to make a start with just conditionals, counts and waits since thresholds can be handled by conditionals.

7

I've built a toolkit that addresses most beginner problems. The real issue is getting beginners to understand even that. I've backed off a lot form showing it around because, until you run into the problem, you can't understand the solution. And it follows my thinking process. Probably different from theirs.

I could share a link with you for my stuff. NOW THINK what was your reaction to that statement? I bet it was along the lines that "this is just clouding the issue." This is how a beginner is going to think when you hand them anything short of a complete working program. We all want it to work according to our thinking pattern. Someone else's pattern is just more confusion..

I think what you are working on is needed, but first how are you going to "sell" the idea? How can you make the beginner think that this is an easier and better way?

-jim lee

8

jimLee:
I've built a toolkit that addresses most beginner problems. The real issue is getting beginners to understand even that. I've backed off a lot form showing it around because, until you run into the problem, you can't understand the solution. And it follows my thinking process. Probably different from theirs.

I could share a link with you for my stuff. NOW THINK what was your reaction to that statement? I bet it was along the lines that "this is just clouding the issue." This is how a beginner is going to think when you hand them anything short of a complete working program. We all want it to work according to our thinking pattern. Someone else's pattern is just more confusion..

I think what you are working on is needed, but first how are you going to "sell" the idea? How can you make the beginner think that this is an easier and better way?

-jim lee

For a few people I've worked with, this may be the possible way.

My big hope is that after playing with this the users will have enough overview to approach "many things at once" with ideas of how many things can work together, see the woods without getting lost in the trees.

I spent 20 years bridging gaps between computers and users (secretaries are easier to write for than engineers), making things as simple as I could really helped. This will be an expert system with more flex than all but maybe one of those had, a CNC programming package from the text-not-graphics age that translated "shop language" to G-codes on different systems.

9

I will make member functions of IO class objects choices for task functions as well as member variables.
Custom functions can then be added native to the system, arrays/formatted IO/file ops.
Whole tool sets can fit in the system as is.

10

Update

I see where the bigger overhead is in this. It's more in user-choice-support, the beginner-friendly interpreter than in the user tasks. And I want more user features/help, more overhead. And SD, even more overhead.

I will try and keep it to flash and CPU cycles as much as possible.

Also I've decided to have it interface with PuTTY instead of Serial Monitor.