Code practice and testing

[bperrybap]

PerryBebbington:
Bill,

Here is my code, it is not very responsive and often pressing the buttons does not cause anything to appear in the serial monitor.

const uint8_t BUTTONPIN = 2;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  pinMode (BUTTONPIN, INPUT_PULLUP);
  pinMode (LED_BUILTIN, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  if (digitalRead(BUTTONPIN) == LOW) {
    Serial.print("Button pressed");
  }
  digitalWrite(LED_BUILTIN, HIGH);
  delay(5000);
  digitalWrite(LED_BUILTIN, LOW);
  delay(5000);
}

I am new to coding and have no idea why this is.
Please help.
Thanks, A Noob.

So, serious point, how would you help someone with this without pushing them to blink without delay and similar techniques?

Ironically, this sketch demonstrates the exact issue I initially brought up of polling for things in loops.
Kind of funny....

First,
I would explain to them that they can't use delay() for something like this as it pauses everything so it will affect button reads.
Then I would refer them to a timer or metro library to handle the scheduling of the blinking LED so that the processing of the button does not get held up to do the blinking.

Next,
I would explain to them and warn them that there can be some real-world issues related to reading buttons due to electrical signal bouncing that can happen by just doing a simple button read as they have done.
And I would also tell them that once they remove the delay() issue, that they will likely start to see issues related to electrical bounce.

Then I would refer them to a button library that handles all that for them so that they can avoid all the pitfalls and real-world issues relating to switch/button debouncing and pick up some extra capabilities like being able to easily do things on a button being pressed, being released, or being pressed for a certain amount of time.
All easy to do with a button library.

While I see it all the time, I am against the constant pushing everyone twards the "blink without delay" technique to avoid some issues caused by using delay().
While it can work, I think it is often a bit cruel and unhelpful to many newbies and less technical people that just want to get things done.
There are usually easier ways (for them) to do what they want than having to mess around with dealing with inline counts and comparisons of millis() values.
To me what Arduino is about is making things easy and much of that is accomplished through libraries.
Arduino has a great big offering of libraries to do things that allows less technical users that have limited programming skills to string things together to do some amazing things.

IMO, the entire blink with out delay and its creation came out of a serious hole in the Arduino platform.
That hole is that Arduino contains no scheduling capabilities in its core library or bundled libraries.
This "blink with out delay" stuff should not be needed for many applications and often can end up with less technical users running into issues from creating incorrect implementations don't work or that fall apart on millis() rollover issues due to how the code was implemented.
I see lots and lots of posts on on the forum related to this and various issues around trying to implement it.

IMO, none of this "blink without delay" type stuff should be necessary.
It could be avoided through the use of libraries and, IMO, Arduino should include some simple scheduling capabilities out of the box so that some minimum level of scheduling is available on all Arduino platforms.

--- bill

[gcjr]

at qualcomm, our RF module in a 4g femto cell, was criticized as not being "event based". it blocked on input from one processor which prevented it from servicing messages from other processes on the processor it ran on.

in general, it is bad practice to "delay" or even wait for a specific event. it is better "wait" for any event and be able to process any event without being impacted by some other independent event.

the unix internals course discussed "cu", the call unix command. it allows a user on one system to call (login) another system. it had to process keypressed from the local user as well as ascii input from the other system. but rather than constantly poll both sides, that program forked into two separate processes (this is pre threads) and each blocked on input from one side or the other, relying on interrupts from UARTs, device drivers, semaphores and process scheduling.

the point is polling is wasteful especially on a multi-tasking system (i.e. unix) which has features to support efficient programming.

obviously an arduino is not a multi-tasking system, but does have interrupts and it is not great hardship to check a number of flags signifying the occurrence of some event that is significantly less wasteful than calling delay().

the arduino environment is targeted for non-programmers. the problem is a non-programmer succeeds in getting something to work and then needs to take it to the next level and has problems because the code was done the "simple" way.

i recently watched an interview of Brian Kernighan (The C Programming Language, AWK) where he described C as not having the "guard rails" that object oriented programming languages have making them better suited for much much larger applications.

in some ways the Arduino environment provides "training wheels" allowing some dumb things to work (e.g. stop pedaling without falling over) but get in the way of going fast around turns by leaning.

While I know it is very common practice these days, not just in Arduino code, but all over the place to write code that essentially does some sort of polling so it very much depends on a particular speed of some sort of looping code, IMO, it is very bad practice and it concerns me greatly.

in general, good programming skills are valuable on all types of processors with various levels of support from simple libraries abstracting hardware to multi-processor environments with multi-threading operating systems

[PerryBebbington]

Hi Bill,
Sorry for taking ages to reply, I have been mad busy with work and too tired to think about this when I've had time.

I would explain to them that they can't use delay() for something like this as it pauses everything so it will affect button reads.

On that we agree.

Then I would refer them to a timer or metro library to handle the scheduling of the blinking LED so that the processing of the button does not get held up to do the blinking.

On that we don't. Is a simple millis based timer so difficult? Perhaps as importantly, is teaching the use of a millis based timer more difficult that leaning how to use some kind of library? You surely know I would be teaching the use of a millis based timer, and perhaps you would read that and feel uncomfortable, well, next time you see that feel free to suggest the alternative, not as 'better', but as a choice Mr or Ms OP; 'here's another way to achieve this, use whichever you find best'.

I would explain to them and warn them that there can be some real-world issues related to reading buttons due to electrical signal bouncing that can happen by just doing a simple button read as they have done.
And I would also tell them that once they remove the delay() issue, that they will likely start to see issues related to electrical bounce.

On that we also agree, I was getting so fed up with explaining this over and over again I wrote a tutorial for it. I realised that it was no use just saying 'you have to debounce buttons', people needed to know why they needed to debounce buttons, hence the oscilloscope traces to show what happens when you press a button (as an aside, while I was doing that I discovered that some of the popular buttons don't bounce! How they achieve that mechanically I have no idea).

While I see it all the time, I am against the constant pushing everyone towards the "blink without delay" technique to avoid some issues caused by using delay().
While it can work, I think it is often a bit cruel and unhelpful to many newbies and less technical people that just want to get things done.

You see it from me! I am a strong advocate for learning these techniques. However, I do agree there are people who just want their project to work and don't really care about learning programming. The thing is, while I do answer some of those questions I generally keep away from them and leave them to someone else. Maybe you answer them? I try to pick questions where I think my answer will be helpful. I don't always get it right, sometimes I provide an answer and it is quickly obvious that the OP prefers the other answers they are getting, so I leave it alone after that.

To me what Arduino is about is making things easy and much of that is accomplished through libraries.

I think Arduino is about a lot of things, and that's one of them. For myself I have devices linked using WiFi made possible with libraries I learned to use in the Arduino environment and with the help of this forum. I am reasonably experienced in programming PICs in both assembly language and C but when I wanted to add WiFi to a PIC based project I used an ESP8266 and the Arduino IDE. Even knowing what I know now I don't think I could use WiFi in a purely PIC based environment. I think the point though is there is no one right way, there are lots of different ways that suit different people and different projects. The libraries are great, but they also hide what's going on. Have a read of this How should I (as a 15 yr old) begin to learn embedded engineering (Arduino) - Education and Teaching - Arduino Forum to see that not everyone new to this world wants a library to do everything for them.

IMO, none of this "blink without delay" type stuff should be necessary.

I profoundly disagree!

It could be avoided through the use of libraries and, IMO, Arduino should include some simple scheduling capabilities out of the box so that some minimum level of scheduling is available on all Arduino platforms.

So get writing, get on GitHub and and get involved and maybe you can get Arduino interested. I don't imagine that will be easy but it won't happen unless you try. Even if you can't get your ideas into the Arduino core you can get them as a library for people to install into the IDE and use.

We are all volunteers here helping in whatever way we can. I am not going to start recommending this or that library for scheduling things that I think can easily be scheduled in a few lines of code and a millis timer, however, feel free to offer alternative ways of doing things to those who ask questions. If you look at my Nextion tutorial I have done exactly that: I have taught my methods but I have also said there is good library by a guy called Seithan for those that prefer a library. I don't know anything about Seithan's library other than the most important thing, which is that people who use it report that it is very good, but then people also say my methods are good too. Different methods suit different people, obviously!

[wildbill]

The issue I see with a library approach, especially a new one, is limiting the number of people who can help. I estimate that there are about fifty people who regularly answer questions in the parts of the forum I frequent.

That number will be drastically reduced if the supplicant has chosen to use a library that is not well known - I've seen this a few times with folks advising various libraries for managing state machines. As good as they may be, few people here will have used them, or be interested in learning them to answer a question.

[PerryBebbington]

The issue I see with a library approach, especially a new one, is limiting the number of people who can help. I estimate that there are about fifty people who regularly answer questions in the parts of the forum I frequent.

Well, it would be you at first! If it proved popular then maybe other would join in, you can't be the only person who thinks this is a good idea.

For Nextion displays I am almost the only person here answering questions about them. When I first came here Nextion questions were either unanswered or given very poor answers, hence the tutorial. Occasionally someone does give a helpful answer but mostly it's me. You'd be in the same situation I guess.

[bperrybap]

PerryBebbington:
Is a simple millis based timer so difficult?

"Blink without delay" is not really a timer but rather a coding technique of constantly looking at a time based counter to determine elapsed time.
For me, having 40+ years of embedded and OS development experience including developing fault tolerant products and high volume consumer products, this technique is trivial, as as I am sure for many of the other "old timers" that have years of experience in programming who often answer questions on the forum; however....
having now watched the Arduino forum and posts on it for around 13 years, unfortunately, from what I have observed is that yes, this technique is a bit too much for quite a large number of Arduino users.
It is a viable solution that works great for some simple applications / situations; however, it doesn't scale very well to more complex environments, nor does it work for many situations that need real time responses to certain events.
Situations where something undesirable or even bad can happen if the event isn't processed on time.
i.e you can't always reliably poll your way out of time critical event processing.

Nor does the blink-without-delay technique work if power management is desirable.

Perhaps as importantly, is teaching the use of a millis based timer more difficult that leaning how to use some kind of library?

Teaching and learning are two very different things.
To answer the specific question, no, teaching is typically not as difficult as learning as the "teacher" usually has a grasp on what they are attempting to teach vs the "student" who is often less skilled and is attempting do or grasp something new.f
So it stands to reason that it should be less difficult for the teacher than the student.
But it really isn't about the "teaching" side of it, it is about the user side of it.
Obviously peoples abilities and their wants & needs can be very different but it often comes down two types of people, those that want to learn some "cool new coding techniques" and those that may have some interest in coding techniques but are mainly are wanting to complete a project.
IMO, it can come down to which allows them to be productive and get what they want to do done, especially taking into consider that the design goal for Arduino and the Arduino IDE was for less technical users and even non technical users (non programmers).
I've seen the responses over the years which I'm sure are tied to very glassy eyed looks behind the screens when there are attempts to explain to them about unsigned integer math and how the comparison inside the if() statement works due to integer math roll over.
IMO, there are some timer/metro type libraries that can do a better job at scheduling in a much simpler and easier to understand way than trying to cobble together something using the blink without delay technique, especially when the there is more than just one or two things that need to be scheduled.
i.e blink without delay does not scale very well

I realised that it was no use just saying 'you have to debounce buttons', people needed to know why they needed to debounce buttons, hence the oscilloscope traces to show what happens when you press a button

versions 1.0 and 1.0.1 releases of Arduino came with the Bounce library which was a library to debounce buttons.
I have no idea why it was removed.
If that library were still there today, I think more people would be using a button library and we'd see fewer people having issues with button debounce issues.

I think the point though is there is no one right way, there are lots of different ways that suit different people and different projects. The libraries are great, but they also hide what's going on.

Totally agree.

I guess overall, my dislike of blink-without-delay and its constant promotion comes from a few things.
After 4 decades of doing embedded development, I have very rarely ever used that technique - like out of thousands of products and projects , I could probably count it on two hands.
While it is a viable technique, one that a programmer should know about and understand how to use when appropriate,
it simply doesn't scale very well and it doesn't work for many situations that need real-time responses to events.
The blink-without-delay technique also can't be used once power management becomes desirable since this technique requires constant rapid looping/polling which is incompatible with going to sleep for power management.

IMO, especially for less technical Arduino users, there are easier to use alternatives available. i.e. s/w timer, h/w timer, or "metro" type libraries.
That can more easily scale into more complex scenarios.
Yes libraries hide things, but I think that is ok.

And in some cases, interrupts need to be used rather that trying to poll the h/w.

--- bill

[PerryBebbington]

Teaching and learning are two very different things.

They are! When I saw that I wondered if I'd typed 'teaching' when I meant 'learning', and now reading back I think I did. I think I actually meant to say:

Perhaps as importantly, is learning the use of a millis based timer more difficult that leaning how to use some kind of library?

To answer the specific question, no, teaching is typically not as difficult as learning as the "teacher" usually has a grasp on what they are attempting to teach vs the "student" who is often less skilled and is attempting do or grasp something new

I do not agree with that. Teaching and learning are very different things, but teaching is just as much a skill as the thing being taught. I am not a trained teacher, I don't think you are and I don't think anyone who regularly answers questions here is either. Some of the answers I see are very clumsy but hey, we are volunteers not trained teachers so that's to be expected. Some people here clearly get annoyed at some of the questions, a good teacher does not do that, or at least they learn to hide the annoyance. Some of the questions annoy me, so I hide by not answering them. Maybe you can see my annoyance in some of my answers though. Teaching IS a skill and not one everyone has that skill. I think the fact we are discussing this is in itself a demonstration of that fact.

I've seen the responses over the years which I'm sure are tied to very glassy eyed looks behind the screens when there are attempts to explain to them about unsigned integer math and how the comparison inside the if() statement works due to integer math roll over.

Agreed so have I, maybe some of my responses have caused that too, I do not know. Sometimes my motivation for answering a question is that I can imagine the OP thinking "WT..?" so I try to give a very different and, I hope, more helpful answer. Whether I succeed I do not know. Anyway, you don't need to know all that stuff about unsigned ints and roll over to use millis timers successfully, just as you don't need to know what goes on in secret inside a timer library, you just need to know the correct form to use the millis timer, just as you need to know the correct form to use the timer library. I don't see much difference there; use it correctly and it will work, use it incorrectly and you'll have problems. Now if you want to know how it works then of course that information is available, but it's not essential to the effective use of the code.

i.e blink without delay does not scale very well

Sure, but by the time someone realises that they have learnt a lot about writing code and coming up against the limitations of some technique or other signals the time to learn something better. Realising there is a limit to how well a technique works is in itself a valuable lesson. Whatever the limits of millis based timing those limits are far less restrictive than the limits of delay based timing.

After 4 decades of doing embedded development, I have very rarely ever used that technique - like out of thousands of products and projects , I could probably count it on two hands.
While it is a viable technique, one that a programmer should know about and understand how to use when appropriate, it simply doesn't scale very well and it doesn't work for many situations that need real-time responses to events.

Sure, but noobs don't have 4 decades of experience, they might not even have 4 days of experience when they begin to realise that delay has severe limitations. I am quite used to using hardware timers on PICs, but I would not dare even mention their existence so someone new on here, and by the time someone is ready to use a hardware timer and configure it to their needs they are past the point where most of the help available here is going to be of much use.

The blink-without-delay technique also can't be used once power management becomes desirable since this technique requires constant rapid looping/polling which is incompatible with going to sleep for power management.

Of course, and I stay away from those kinds of questions because I have limited experience in building things where power management is an issue. There are some people on here who seem to know how to get a tiny battery to last a year or more while communicating with their home made satellite in orbit over the poles (I might be exaggerating a little bit here), I am not that person.

And in some cases, interrupts need to be used rather that trying to poll the h/w.

They do, but not as an antidote to the inappropriate use of delay, which is a common source of the questions we see here.

[drmpf]

First up, I have only very quickly skimmed this post so my comments may be a bit off.

Re Polling versus Interrupts

Polling is easier to use, no time limit on the tasks and no need to handle volatiles or critical code sections.
My tutorial on Multi-tasking in Arduino covers this in detail

However, Interrupts are the choice for very low power projects where the CPU goes to sleep most of the time and is just woken up by an interrupt to do some work every now and again
My series of projects on Very Low Power BLE in Arduino covers this application using is a specialized library.

[gcjr]

drmpf:
Polling is easier to use, no time limit on the tasks and no need to handle volatiles or critical code sections.
My tutorial on Multi-tasking in Arduino covers this in detail

multi-tasking is more that just a series of polling functions. if real-time response is critical, polling would be too wasteful, making interrupts essential. for some hobbyists, it would be helpful to clearly understand the tradeoffs between using interrupts, millis() and delay. one common need for interrupts, even on an arduino is servicing an encoder.

a poor approach is often selected out of ignorance rather than good practice

[UKHeliBob]

BlinkWithoutDelay

from what I have observed is that yes, this technique is a bit too much for quite a large number of Arduino users.

The main problem seems to arise when problems are caused by delay() and users post here seeking help. Whilst the answer may well be "use millis() for timing instead" that usually requires a radical rewrite of the sketch. The same goes for solutions using interrupts or libraries

The techniques are not fundamentally difficult if explained properly but applying them to code that has already been written can be difficult. The experienced members of the forum would not normally start writing a sketch using delay(), beyond a trivial example or test, but would start knowing that millis() was to be used and structure the sketch appropriately

[PerryBebbington]

UKHeliBob:
BlinkWithoutDelay
The main problem seems to arise when problems are caused by delay() and users post here seeking help. Whilst the answer may well be "use millis() for timing instead" that usually requires a radical rewrite of the sketch. The same goes for solutions using interrupts or libraries

Yes, quite. Any learning worth having usually comes with attached difficulty, in this case getting your head around how to use millis or any other timing mechanism properly, and getting your head around even the simplest multi-tasking. What newbies fail to realise is that they go through life muti-tasking, the only difference being the time scale, the underlying process is the same whether it's a processor or a human doing it.

[dave-in-nj]

Bringing this down to a level much closer to the noob.

they, copy working code, then stumble when merging a temperature sensor with a relay and a display....

The Arduino is a beginners platform. It is designed to allow us bumbling fools to cobble together bits of this, and that and be able to read a temperature, change an OLED, host a simple web page, save some data, move some motors....

As one becomes more proficient, they learn more. how many times have we seen people say uint8_t was new to them ?
or asked the difference between int8_t and uint8_t ?

In my understanding the whole Arduino platform is to teach people how to write an if() program.
let me explain.....

read temperature if(temp > 50) then digitalWrite(RELAY1,LOW)

but.. the thing is done, so really wanted to write
if RELAY1 is already low.... don't bother
if RELAY1 is not low.... then do bother.

now it becomes
read temperature
if(RELAY1 == HIGH )
if(temp > 50) then digitalWrite(RELAY1,LOW)

You didn't NEED to add the qualifier... but your THINKING about the step, and each step may have dozens of other steps to improve your code.

The simple if() is easy,
But making it powerful is part of the learning curve

noobs think the computer knows what to do, that it knows not to re-write the whole screen when just one temperature changed...
Or to write one thing, then let is sit so the user can see it, and not try to change the reading 1,000 times a second.

If someone did not like looping, then they should do the common thing we see. write all code in setup()

but, if someone's awareness comes up to "why do I need to keep turning the relay on, when it is already on ?"
or "does it hurt and LED if I try to turn it on with every loop?"

It just means they are up to higher level of awareness of what is going on.

For Bill, when I did CNC, I hand wrote all my G-code until I could read g-code easily. only then would I use software to write my code.

blink without delay, IMHO, SHOULD be in a library

bwd(LED1,500,250,50,0) // pin, time high, time low, # of repetitions, end flag.... or some such structure.

but, the BWD concept being taught is that one has to change one thing before something else.
it is hard for a noob to understand with the way it is presented and taught, but even with baby steps, the noob has to wrap their mind around juggling three things, and that that one thing you want to change is the one thing you are not touching, but is in the air, the one in your hand that you can change, is not the one you are looking at.

You're LOOKING at temperature,
In YOUR HAND is the relay.
What you really want to know is if it is already off or on

and that is magicians miss-direction but our bane.

if() the relay is already low, don't bother turning it on again. stuff.

Also, I think over 98% on the people posting questions are self taught and are not being taught the fundamentals of proper coding. yet, they still amaze us with masterful works.

as to the question of looping. all computers are, like human processes in machines.
look at a wall. no, really. look at it for 5 seconds.... we'll wait.
do you realize that your eyes scanned that wall over 30 times a second and you processed the image over 150 times ?

now, close your eyes, face the wall, blink as fast as you can. that is still more than 1 scan (loop) of the image.

reading between the lines, if someone thinks scanning 1,000 times a second is bad, they are imposing some belief that turning on an LED 1,000 times after it is already on, is either a waste of time or bad for the LED, or might hurt the micro, like wearing it out in some way. The fact that they are asking, means they are questioning, and wondering, and are at that stage of being ready to learn.

Also being discussed on this thread,,,,,
Should the IDE force you to keep revisions ? or do it for you ?
I am of the school that you know what you wrote and why and you know what you F'd up and how to fix it.
and if you don't, then going back and trying to figure that horrible mess of dis-jointed thoughts and meaningless descriptors is the pain you need to suffer in learning to code.

THAT too is a teaching moment.
you 'should' learn that comments, sensible descriptors and neat editing are skills that help you.

Imagine if you went to compile and the pop-up says ' what did you change ? and you had to write in what you changed.
And 'did the last compile work Y/N ? if no, why not ?

And the compiler would add this in text in the beginning of the sketch.

Then you could look over your scores of old files and only pick the Y answers to go back to a working version

would the noob turn this off ? would you ?

just some food for thought in this thread.

[dave-in-nj]

PerryBebbington:
Bill,

Here is my code, it is not very responsive and often pressing the buttons does not cause anything to appear in the serial monitor.

const uint8_t BUTTONPIN = 2;

void setup() {
 // put your setup code here, to run once:
 Serial.begin(9600);
 pinMode (BUTTONPIN, INPUT_PULLUP);
 pinMode (LED_BUILTIN, OUTPUT);
}

void loop() {
 // put your main code here, to run repeatedly:
 if (digitalRead(BUTTONPIN) == LOW) {
   Serial.print("Button pressed");
 }
 digitalWrite(LED_BUILTIN, HIGH);
 delay(5000);
 digitalWrite(LED_BUILTIN, LOW);
 delay(5000);
}

I am new to coding and have no idea why this is.
Please help.
Thanks, A Noob.

So, serious point, how would you help someone with this without pushing them to blink without delay and similar techniques?

we get so wrapped up in BWD that we miss the klunky, but workable options
delay(1) ;
count ++ ;
if (count >= 60000) {
...do a thing
count =0;
}
yes it has delay of 1ms.
and it does it's thing once a minute.
blocking without blocking ?
and, yes to say one minute is deceptive as it could be seconds longer. but for checking if it is time to re-postion the solar array to follow the sun, or to open the blinds, or to say the coffee is hot. if the cat is off the toilet...... it is more than accurate.
AND..... for a noob, it is EASY to follow.

[gcjr]

dave-in-nj:
The Arduino is a beginners platform. It is designed to allow us bumbling fools to cobble together bits of this, and that and be able to read a temperature, change an OLED, host a simple web page, save some data, move some motors....

beginner what ...?

as an engineer, i would have described it as an eval board. i learned assembler coding on a KIM-1 i got it from a Bell Lab engineer who used it to learn programming microprocessors.

however the Arduino is more than an eval card for an Atmel processor because it includes a separate interface to allow convenient programming via USB an an IDE for development. but an Arduino or ESP32 is something i definitely wish i had as a kid or while in college. it would have been a lot easier to program microprocessors with than an HP 64000

i believe the issue with the appropriateness of the guidance on the thread depends on the goals of the poster

• future engineer
• hobbyist
• physical computerist
• student looking for a passing grade
• ...

i don't see a clear answer. i think most responses focus on helping just getting the code to work

[dave-in-nj]

gcjr:
beginner what ...?

as an engineer, i would have described it as an eval board. i learned assembler coding on a KIM-1 i got it from a Bell Lab engineer who used it to learn programming microprocessors.

however the Arduino is more than an eval card for an Atmel processor because it includes a separate interface to allow convenient programming via USB an an IDE for development. but an Arduino or ESP32 is something i definitely wish i had as a kid or while in college. it would have been a lot easier to program microprocessors with than an HP 64000

i believe the issue with the appropriateness of the guidance on the thread depends on the goals of the poster

• future engineer
• hobbyist
• physical computerist
• student looking for a passing grade
• ...

i don't see a clear answer. i think most responses focus on helping just getting the code to work

I agree that it does depend from the user point of view.
but 'Adruino' is more than a board, it is the IDE, the Forum, hardware and boards from the STM32, ESP32, Atmel, ARM-Cortex.....
RPi is an alternate universe.

from my very limited point of view, most noobs are here to get a thing to work and their professor or friend told them to use an 'Arduino'
also from my very limited point of view, a lot of the actual programmers use different software to program than the IDE.
The Arduino grew way beyond what Atmel tried with the Butterfly, it because a sort of Universe.
If I get the gist of what Bill was saying, that these days software is a rush to get it out the door and working 'well enough' to sell product, and reading between those lines... hope the sales will pay for engineers to fix all the mistakes on the multiple future rev's needed to have it work as intended. anyone use MS-DOS or Windows ? prime examples.
but the fundamental premise, that on a thread, someone did not like looping,
is my point. that the 'problems' a person sees, gives us insight into what they want and to a large degree, their ability and level of understanding.

[bperrybap]

dave-in-nj:
If I get the gist of what Bill was saying, that these days software is a rush to get it out the door and working 'well enough' to sell product, and reading between those lines... hope the sales will pay for engineers to fix all the mistakes on the multiple future rev's needed to have it work as intended. anyone use MS-DOS or Windows ? prime examples.

Yep. And in some cases "well enough" can be a pretty low bar.
My concern is that it has now gone beyond just the pressure to push something out sooner.
Much of what makes or goes into many products today is s/w and I believe that now that there is such an ease of providing updates rapidly at very low cost, it has led to an acceleration of poor product development practices.
In other words, it has led to the normalization of short circuited product development processes and shipping out code that is of questionable quality. Things like up front planning / design and after development testing are both really getting reduced.
I see lots of products out there with code that years ago, would have been called "alpha" level.
It is going on all over the place and we are getting to the point where even users are now starting to accept it.
Today, many products effectively never get out of beta.

I look at something like Android applications. Some of these do updates once a week or sometimes more.
There is no way any level of planning or testing is going on in that short of a time frame.
IMO, a product slamming updates out that often is sign of a project that is of control.

but the fundamental premise, that on a thread, someone did not like looping,

I was the one that initially brought up looping, but I'll say it once again. Looping was not at all what I was talking about or was concerned about.
What I talking about was using a design methodology that depends on constant and rapid polling of something in a loop to detect events and then subsequently do things.
This can and does work well for certain applications, typically smaller and limited scope type applications.
What I've seen over time is that this rapid polling methodology has been expanded and pushed into areas/environments where it should not be and that it breaks at a certain point as new capabilities / features are added.
I even see it being used on systems that provide a full OS with lots of event and task capabilities where is no need to do polling.

IMO, it often comes down to a lack of initial up front planning and/or poor design.

In the case of Arduino and blink-without-delay, I still believe that most Arduino users would be better served by using some sort of timer/metro library to help do the scheduling rather than trying to push them into learning how to do their own crude scheduling by constant polling of a counter in a loop to determine elapsed time(s).
Can the blink-without-delay technique work -yes, and quite well for some situations but not for others.
I just happen to believe that unless the overall project is very simple or the point of using it is an academic exercise, that there are other and better alternatives that are less messy or more reliable/robust once the project starts to get larger, more complex or has very time critical realtime demands.

I believe that the entire reason blink-without-delay came into existence is because Arduino is lacking even some very basic scheduling capabilities.
IMO, a lack of some sort of scheduling is very a big hole in Arduino.

btw,
I think dave-in-nj hit the nail on the head when he talked about how users have to learn how to juggle in order to use blink-without-delay. And that can lead to them spending more time figuring out how implement and use the scheduling mechanism, rather than just getting on with their project.

--- bill

[bperrybap]

dave-in-nj:
Also being discussed on this thread,,,,,
Should the IDE force you to keep revisions ? or do it for you ?

I have not seen any discussion about the IDE doing revision tracking.
Revision control tools and the Arduino IDE are two different and separate tools.
I originally brought up that source code control tools can make a person more productive.

Beyond the ability to track changes and tag versions that can be referenced in the future, another
big benefit of using a source code control management tool is for projects that are non trivial or that span time.
All these types of tools allow entering a comment when changes are committed.
It can be extremely helpful when coming back to a project after some time has passed to see why certain changes were made.

Also, tools like git allow the creation of code branches that do not affect the main line development.
That might be for development of experimental code that can be subsequently automatically and easily merged back into the main development should they be desirable.
This kind of stuff is just not possible without this type of tool.

Over the past 3+ decades, I have made a casual non scientific observation on the use of or the avoidance of using source control tools.
Those that don't use them or have a big reluctance to use them have either never really used them or tried to use them but ventured down a path with a package that had a high learning curve and gave up before they ever came productive using it.
Today there are several GUI based source control tool sets that don't have a high learning curve so the argument over not using them due to a complex high learning curve isn't really true anymore.

--- bill

[bperrybap]

Speaking of poor development practices and lack of testing....
Just look at the mess google created yesterday by slamming out an updated version of Android System WebView that was not adequately tested.

What is most infuriating about this is that Google used one of their side channels to force this update on users, including those that have disabled automatic updates.

Ironically, it even broke their own gmail app.

Just another example of the poor development and project management practices that concern me causing issues and chaos in the world.

--- bill

[dougp]

bperrybap:
Speaking of poor development practices and lack of testing....

It spans the gamut. It's purely anecdotal but I have a coffeemaker that every so often takes a fit. It's one of those newfangled ones with tactile switches, an LCD clock display and, I presume, a piezo buzzer.

Instead of beep-beep-beep to announce brewing is complete it'll veer off into beep-beep-beeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeep then recover and do the proper signal. I haven't opened it but I have no doubt there's a microcontroller in there with a once-in-a-while bug in the code.

No chaos though.

[gcjr]

bperrybap:
I believe that the entire reason blink-without-delay came into existence is because Arduino is lacking even some very basic scheduling capabilities.
IMO, a lack of some sort of scheduling is very a big hole in Arduino.

it's a micro-controller ?! no need for such