is it possible to replace Delay(1000) for example wherever you find it with this loop ?
for (int i = 0; i< 1000 ; i+1) {
asm(""); // do nothing
}
is it possible to replace Delay(1000) for example wherever you find it with this loop ?
for (int i = 0; i< 1000 ; i+1) {
asm(""); // do nothing
}
What would be the point and how long would the for loop take to run ?
A blocking delay is a blocking delay however you implement it
Also look out for the compiler helpfully optimising the code away because it does nothing
int led = 13;
int roll = 1000 ;
void setup() {
pinMode(led, OUTPUT);
}
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
for (int i = 0; i< roll ; i+1) {
asm(""); // do nothing
}
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
for ( int i < = roll ; i > 0 ; i-1 ) {
asm("");
}
}
Attempting to blink without delay()
The point is not to avoid using delay(), rather it is to avoid using blocking code
If your for loops did what you seem to expect then they would be blocking code
As it is, how long does an empty for loop take to run ?
Ok... so you can "blink" without using the "delay" statement... but is that really what you are being asked to do??
Normally it means make the LED blink but don't block the code... the option above blocks.
it seems you did not get why delay was "the bad boy"... at least delay() has some sort of precision in terms of timing you wait for compared to your code where it's hard to tune and platform dependant.
Hello
The name of the function delay should be revised to sleep.
sleep has already another very established meaning (power-saving mode)
there has been a few discussions on this topic already in the past
and more I'm sure
do we really want to open this again ![]()
I guess the answer is yes because learning about blocking and non-blocking code is an important step for everyone learning to program micro-controllers. For the person asking they are not asking 'again' they are asking for the first time. I understand your frustration, I feel it too, but we are here to help beginners.
13 posts were split to a new topic: Polling Vs scheduled events in an OS or RTOS
I've split this because the polling and RTOS discussion was too far away from what the OP asked about. Please continue in the new topic.
not frustrated - don't worry. I'm happy to have the conversation again about non blocking code although we now have a few good posts about that I have on shortcut — I was more referring to the discussion about renaming delay()
A post was merged into an existing topic: Polling Vs scheduled events in an OS or RTOS
Does this take 1ms to complete on your board?
running this (fixing the for loop) on a UNO
const int roll = 1000 ;
void setup() {
Serial.begin(115200);
uint32_t t1 = micros();
for (int i = 0; i < roll ; i++) {
asm(""); // do nothing
}
uint32_t t2 = micros();
Serial.print(F("∆t = "));
Serial.print(t2 - t1);
Serial.println(F(" µs."));
}
void loop() {}
displays
∆t = 316 µs.
That which we call a rose by any other name would smell as sweet.
One problem, the usual C/C++ user implemented state machine lacks a simple syntax like C/C++ itself. The result is that simple logic is simple to code in the state machine, but complex logic involves design pattern based source code that is exponentially more difficult to understand.
From time to time, I reply with an example I made, which emulates a 'for' loop. Because, that is often the need for it in things like Neopixel effects and so on. However since the condensed control structure statements of C are not available, constructing any very complex logic in this kind of implementation would surely cause you to tear your hair out. Although, I have pointed out previously, that statistically at least, problems which involve thoughts of hair removal can usually be solved.
A quick example would be to navigate a two dimensional array and respond somehow to the contents... already you have a nested 'for' loop and some conditionals. This won't be simple in SM paradigm.
We need to recognize the steep learning curve this places on the beginner. The other problem is that the RTOS way of doing things is not complicated, but very often the interfaces are not at all beginner friendly. It might be a reason why it is not currently included in the Arduino core.
The third problem is that the fundamental concepts of tasking and timing are another learning curve which many people have only begun to undertake. It would be nice to connect the dream with the reality and offer beginner or even non-technical people simple tools that they could use to multitask on the Arduino. But it will remain a mid level Arduino programming skill, unless some simplifying tool is made available.
The dream is, to enable people to embody self made concepts in some working project. The reality is in the nature of the hardware (and software), which is, amazing in the scope of what it can do, but also limited in what it can do.
If you like, since delay() and programming are encountered at about the same time by beginners, the implications of using it are not well understood in that case. But it is used because it is easy to understand. Paradox, no? But it is actually because the "delay paradigm" is actually so intuitive and easy to understand, in contrast to the mysterious implications.
"But... I wanted to keep checking the button...". ![]()
Thanks a lot. Anyway the code above did not compile . it was giving this error
Blink:17:12: error: expected primary-expression before '<' token
for (int i=< roll ; i > 0 ; i-1 ) {
this is YOUR code and it does not mean much ![]()
I wrote in post 23
for (int i = 0; i < roll ; i++) {
Well that is interesting. I'm actually tied up in projects right now, so no time for a deep dive. But I will read more today. This excerpt echoes one concern of mine:
Concurrency is hard, is there any way to help the user not to shoot themselves in the foot, both within multitasking per se, and when considering multitasking + interrupts which makes things even worse?
You might break this into the two main problem areas, process control (scheduling), and interprocess communication (semaphores, producer-consumer models).
There are two things to learn, the methods (framework) and the design patterns. We see all the time, it's often really easy to explain and learn the method, but not the pattern - what is millis()? It's just a simple timer, most people will grasp that right away. What is usually an obstacle is the abstract object we call a "timer". It doesn't help that it isn't necessarily visible, it can be "baked into the code" which makes it very mysterious to beginners. Something like a library that allows you to create and use "timer objects" may be helpful in some cases, but it may complicate what might otherwise be very simple code (20-100 line sketches). The abstraction and encapsulation of such a critical function may make it difficult for a beginner to integrate with multiple tasks in their sketch. They will not soon learn how it works, either. So what is the learning value?
Linear code is itself a paradigm, and a simple one that beginners can grasp and begin to use immediately. Even so, we see how much trouble they can get in with it. Questions like, "how do I exit an 'if' statement" and the like. Linear code can be traced extemporaneously but multitasking requires more conceptual tools to form a clear mental image of what is going on. We see it already, just with interrupts.