what about HCF 
(edited - sorry the link was in French)
StopThisMadness( )
1 Like
I think timing is the best word! Don't wait, don't pause, don't delay. Do stuff all the time. Everything you do, do it on the right time. That's timing, isn't it? Seconds may go by while you do seemingly nothing. But you still do, don't you? You check tens, hundreds or thousands of tasks whether their time has come.
Some more synonyms for schedule: plan, arrange, await.
This is something I've thought about for a non-blocking timing library, settled on 3 letters ...
Clk
another question: how would you be using it in code?
Not sure if you're asking me, but I'd implement it as a small class. If the user needs 12 timers, they could initiate 12 objects. Then use them where needed in condition statements, state machines, etc. The same way a user can use a button library to deal with 12 buttons and deal with "onPress" and "onRelease" transitions, Clk() would be configured to respond on timeExpired or timeToStart events and more.
I was asking @StefanL38 but any answer is good
I wanted to see how that would be used in code which could give a hint on the words being used
DelayedTask timeIsUp(x, y , z);
...
if (buttonIsPressed) timeIsUp.start();
...
if (timeIsUp) {...}
I think you're basically describing this. (Or its predecessor, Metro.)
The thing which tends to make state machines pretty messy is that their state transitions are sometimes time-based, sometimes event-based, and that you tend to end up with multiple state machines at the same time, compounded by the fact that the common C++ implementations with a huge case block just aren't all that great.
So, I'm not so sure that this is a silver bullet to make state machines more approachable.
All of this seems myopic, as no consideration is being given beyond current one-cpu microcontrollers and state-machine like programming.
Once an RTOS is added and "threads" are implemented, commands such as delay() do not have the same meaning. One only need to consider FreeRTOS and ESP32 to understand that for novice programmers, delay() is as good as any English term whether it is your native tongue or several rungs down on the ladder.
Thus, my preference would be to leave the lowly term delay alone but were I to supply a candidate:
Edited:
NothingProductiveHereForMS();
Even in "one-cpu" environments like JavaScript and node.js (which generally run single-threaded no matter how many cores your physical CPU has), things are very different than they are in the Arduino system because your application is driven by events in the form of callbacks, promises, or observables. This isolates your "state transitions" from their actual causes - it doesn't matter if you want a thing to happen in 1000ms, or if you want a thing to happen when a button is pressed, or if you want a thing to happen if something goes wrong, you simply attach the thing you want to happen to the event which should trigger it.
Personally I think that this programming model is not necessarily intuitive, but it allows for better organized and more expressive code than the state machine approach that is common in the Arduino world.
But be that as it may - most people in this forum use the Arduino API, and I doubt the Arduino folks are going to pivot their well-established API into a completely different programming model and force all their users to completely re-learn the platform. I wouldn't exactly call this matter "myopic" - this is the Arduino forum and there's nothing wrong with having discussions that are limited in scope to the Arduino ecosystem. Nothing wrong with looking at the rest of the universe, of course. Discussions about how things work elsewhere have their use, but for solving problems in the here-and-now, that use is limited.
As Arduino is bolted onto C++, callbacks and timer interrupts and pin state interrupts also exist with Arduino: state-machine approach is generally easier for a novice to grasp which I suspect is why that methodology is often suggested.
My point regarding the term myopic, is that changing the 'name' given to delay() changes nothing; it is a perfectly good name for what happens, IMO. The implementation of delay, is just "SpinWheelsFor" and more knowledgeable programmers know that such a command often introduces negative consequences for the novice.
A tremendous effort is made to assist an Op with a problem a great amount of knowledge transfer is often provided; often unwanted by some who are just trying to complete their homework or trying to follow an Internet article/code. Others want to understand but have not the background to appreciate the Big Picture.
Random Nerd has an article titled, "Why You Shouldnât Always Use the Arduino Delay Function" here. Maybe you or I would have written it differently? The home-grown Arduino Blink Without Delay is a good tutorial for some.
With great respect to StefanL38, I started reading this post and found it humorous. Why? Because this search:
suggests that the chances of changing a command name is close to 0% ... because there is simply too much written material out in the market. No author is going to want to write, "... the command once known as delay() is now more appropriately called ..."
Sometimes, things are really written in stone.
My code runs 30 (or 40, or 50) times a second (each time displaying something onto the screen). To do that I implemented bool nextFrame(void). Which tells me if it's time for the next frame or not.
A delay() does not stop the arduino. It merely sits in a empty loop while the time has not elapsed (the amount in the parameter). I would assume the controller can still process interrupts. It's a bit similar to the "sleep" on RISC chips (ATm series, not ARM chips).
So in reality it should check the (global timer) to see if the time has elapsed enough for (whatever code) to run, rather than halting the main loop. Or a set and a check (to delay a certain amount of time) which can presumably be called "setwait" and "checkwait". something along those lines.
A lot of problems with delay involve not being able to see a button press until some sequence of operations containing for loops with embedded delays finish. Typical of this is addressable LED patterns with a push button to change the pattern.
Sometimes rather than advise the full state machine approach I have advised to use what I call a "commutable delay". It is a simple millis loop that will also exit on some event like a button press.
I am sure I don't have to explain the advantages of that to those involved in this thread.
1 Like
delaylessDelay
I don't want to change the name of the function delay()
I started the thread with the hope to find one single word that expresses what non-blocking timing (3 words) does. maybe even better than non-blocking timing.
It turned out reducing it to one single word does not work.
Even if it would be 100 billion books. If I came to the opinion that a certain word is bad suited and confusing I still would suggest to change it. A badly chosen word stays badly chosen even if it is used 100 billion times. The minimum would be to insert an easy to understand explanation in front of this 100 billion times used word and then add "what has been explained in the last paragraph is usually called "........" which would transform the word in a technical term over time.
I like the idea of a class which would create a common pattern like posted below
As a first draft. That I would overthink for quite some time if I will find even better names.
nonBlockingTimer myBlinkTimer;
myBlinkTimer.schedule(1000); // setup timer to expire in 1000 milliseconds
if ( myBlinkTimer.reSchedule() ) { // returns true if specified period has expired and starts a new period as soon as it has been called when expired
digitalWrite(LED_Pin, !digitalRead(LED_Pin) );
}
etc.
@paulpaulson : that was an entertaining read
best regards Stefan
Delay feels OK to me. When your plane is delayed, it does not take off. It is stuck on the tarmac and does not move and often you are stuck in it and canât move eitherâŚ
Your nonBlockingTimer thingy makes me think of words like asynchronous ( not happening or done at the same time or speed) or concurrence (the fact of two or more events or circumstances happening or existing at the same time.)
Youâll find the AsyncTCP or ESPAsyncWebServer libraries for example to hint at what benefit they have (on ESP)
I quickly whipped up something that may be of interest.
This example contains two delayed tasks and one state machine. There are probably better ways to do either of these things.
yield()?
intermission()? (Anyone else hearing the Pearl & Dean advert jingle?)