How do you say?

To someone that they act like they're too stupid to write code?

We can't say that here but once again it's like warp factor 7 duh.

Sorry but "I read ALL the books" and still clueless... is just a pop cause away from celebrity stupid AFAIC.

Update: oh. Well I guess you can in a way if you just agree with them when they point it out.

Yep. I spent 30 minutes writing a piece of code for someone, to do exactly what they wanted. I got back "Very nice, but how do I do what I wanted?" Duh! :stuck_out_tongue_closed_eyes:
Maybe there could be a special flag to denote postings by morons, so that we can avoid them?
Wait!
I've got it!
A sticky with stepwise instructions of how to wrap up their Arduino and post it back to the supplier. :slight_smile: :slight_smile:

Just ignore them if you find yourself wasting time on unprepared minds. Maybe a later time the same person comes better prepared, or just disappear.

Not exactly the same, but it always amazes me the number of topics where the OP wants to take an inexpensive (or cheap clone) microcontroller, add a few peripherals and then, by the magic of software (which they cannot write otherwise it wouldn't be on the forum), they can replicate a device which costs hundreds or thousands of pounds / dollars.

Video editing is my favourite, followed by facial recognition!

Some seasoned developers have done very clever things with the Arduino, but well beyond the reach for the novice developers!

Sounds like an ID10T error: User error - Wikipedia.

However, I do tend to give newbies some amount of slack. Consider the size of the average smartphone these days, and consider the size of an Uno board is much bigger than a phone (though of course most of that is for through hole soldering).

Given everything a phone does these day and the amount of horsepower under the hood, if you didn't know anything about computers and microprocessors, you would expect the Uno to do so much more.

Lets see, the t-mobile Samsung S2 that I use was designed several years ago, it has 1GB of ram, 16GB of ROM, a dual-core 1.5Ghz 32-bit ARM processor with floating point, can handle multitasking, video, speech recognition, etc. On the other hand, the Uno has 2K of RAM, 32K of ROM, 16Mhz 8-bit AVR processor, no floating point, etc.

And which would you rather tie up doing some small task?

GoForSmoke:
And which would you rather tie up doing some small task?

As always, the answer is it depends. When you get to chips that run operating systems, you can run several things at once, and you typically don't have the blocking that you see in Arduinos. Now, of course you do lose some of the real-time nature of having the (slow) chip to yourself.

But my point is more if you know nothing about computers, except at the interface level, and you see an Arduino, you might expect it to do much, much more compared to a cell phone that has seemingly 10 million things crammed into it.

MichaelMeissner:

GoForSmoke:
And which would you rather tie up doing some small task?

As always, the answer is it depends. **When you get to chips that run operating systems, you can run several things at once, and you typically don't have the blocking that you see in Arduinos. **

cough

I take it you've never seen BWD and state machine tutorials?
In reply 13 of this thread is a sketch you only need and Arduino and a jumper wire to try.
All at the same time
-- it watches the "button" and debounces it and only then change the control state of the button
-- it blinks led 13
-- it starts the led blinking with 1 grounding of the INPUT_HIGH pin connected jumper, I use the USB plug box.
-- it shuts the led off on the next "button press" and alternates ON and OFF for future presses.
-- it does all these things and when I'm ready, I'll add better Serial input than letter-number (done that).
-- and still, a standalone ATtiny25 could do this and trigger house power as well. Those might cost a whole $1.

http://forum.arduino.cc/index.php?topic=243960.msg1747220#msg1747220

liudr:
Just ignore them if you find yourself wasting time on unprepared minds. Maybe a later time the same person comes better prepared, or just disappear.

A killfile/bozo bin would be useful for that.

GoForSmoke:

MichaelMeissner:

GoForSmoke:
And which would you rather tie up doing some small task?

As always, the answer is it depends. **When you get to chips that run operating systems, you can run several things at once, and you typically don't have the blocking that you see in Arduinos. **

cough

I take it you've never seen BWD and state machine tutorials?

I am well aware of state machines, and state machines are fine up to a point. They are pretty much required for small memory environments like Arduinos that have a single core. They also work well in environments where you have a few worker threads, handling many requests, but each request doesn't need that much state. They often times however break down in more complex systems, where you really want separate domains and not have to worry about one subsystem interfering with another. Consider a cell phone once again, you might have 50 apps sharing the machine. Because the apps are independent, you don't want a badly written app that overwrites memory to affect other apps, so you want some protection between the different apps.

The phone that cost how much?

You claimed that Arduinos blocked. I show how to not block as do others.

And I did say, which would you tie down for a simple task and not the end of the world, a gigabytes phone or a cheap little board, if even a board?

Add a few shift registers and it can run a LOT of things "at once", including power relays and 8x8x8 led cubes.
Add homebrew SD and you get instant near unlimited SPI stream read/write capacity.
All for what lunch might cost or less depending on where you eat and where you shop.

How much does that phone cost?

MichaelMeissner:

GoForSmoke:

MichaelMeissner:

GoForSmoke:
And which would you rather tie up doing some small task?

As always, the answer is it depends. When you get to chips that run operating systems, you can run several things at once, and you typically don't have the blocking that you see in Arduinos.

cough

I take it you've never seen BWD and state machine tutorials?

I am well aware of state machines, and state machines are fine up to a point. They are pretty much required for small memory environments like Arduinos that have a single core. They also work well in environments where you have a few worker threads, handling many requests, but each request doesn't need that much state. They often times however break down in more complex systems, where you really want separate domains and not have to worry about one subsystem interfering with another. Consider a cell phone once again, you might have 50 apps sharing the machine. Because the apps are independent, you don't want a badly written app that overwrites memory to affect other apps, so you want some protection between the different apps.

remember "Nonpreemptive multitasking"? I think windows 95 was the first windows os that switched from "NonPreemptive multitasking" to "preemptive multitasking"
Mac took way longer. I know because my sister in law is a mac fan boy (rofl) so I kept an eye on macOS to tease her with this.
On a arduino where you have all code in hand;IMHO doing "Nonpreemptive multitasking" is a very acceptable solution. (In other words you have all the resources in hand to tackle the bad boys)

I write all my code in setup, loop sketch thinking. If you can keep you max time in loop small you can yust add loops.
I start looking for optimization when it takes more than 20ms to run through all loops. That is still 50 times a second.

To give you an idea: below is the actual main loop of my Marin robot.

void loop()
{
	myRobotSensors.loop();
	MyMotorOnOffSwitch.loop();
	MyMower.loop();
	MySkidDriver.loop();
	MyRCModule.loop();
	MyGPSModule.loop();
	MyPowerManager.loop();
	myCommunicator.loop();
	 myBrains.loop();
}

There are 2 reasons why the subsystems do not interfere with each other

  1. Because there is only 1 subsystem that knows about the others. That is myBrains.
  2. Because loop is the only method that is allowed to take time.
    The first one is relatively easy to understand. To explain the second:
    A call to MyRCModule.getDriveSpeed() returns the drive speed. It is not allowed to go and find out the drive speed. It has to know the drive speed. off course some conversions (for instance meters/hour to miles/inch ]:smiley: ). It is known because it has been calculated/found out in loop.

Och yeah; and of course the whole subsystem thinking is inside the subsystems as well.
This is part of the code of void RobotSensors::loop()

	myCompass.loop();
	myLeftMowMotorTemp.loop();
	myRightMowMotorTemp.loop();
	myLeftFrontDriveMotorTemp.loop();
	myLeftBackDriveMotorTemp.loop();
	myRightFrontDriveMotorTemp.loop();
	myRightBackDriveMotorTemp.loop();
	myState = CalculateMotorTempState();
	CalculateCoolingState();
	 myStateName=getStateName();
}

I guess I just did to much programming in windows 3.1 for workgroups.

Best regards
Jantje

You guys are running around in circles here. No one is saying a phone or Arduino is better. They're obviously very different tools suited to very different things. I don't think this viewpoint is even slightly controversial.

Arduinos don't block. Single-tasking code does, which is what typically runs on an Arduino due to the inherent resource limitations. Setting up a task-oriented framework doesn't (usually) make much sense on a 16MHz processor running with 2KB of RAM. It can be done, but the overhead is excessive. On a phone, with 1GHz+ clock and 1GB of RAM, the housekeeping overhead is negligible, while the development cost of not using process separation is enormous. So it's a no-brainer.

It's absurd to argue that an 8-bit micro would be a better smartphone CPU, or that you should be using a multi-core ARM as a temperature controller for a thermal reflow oven. 8-bit micros are going nowhere, despite what the ARM M-series product portfolio might have you believe. :wink:

Interesting (to me) aside: I was building a circuit block the other day, and realized it's more expensive (in parts cost) and more complicated (in PCB layout and logic) to try and use specialized parts than it was to just dedicate a small micro to a trivial task. I ended up removing a hardware UART and a bunch of programmable logic ICs and using a single low-cost MCU instead. It felt like gross overkill, but it was advantageous in every single way. Now, in my case, I went with the LPC812 (32-bit ARM M0+), but an ATtiny would've worked just as well. The '812 just happened to have a more convenient pin-out (assignable UART pins).

These are microcontrollers. They are suited to many tasks and they can work well together.
They are not what we considered supercomputers by mid-80's standards, but the phone is.

Do I tie up an expensive phone to run home automation when cheaper though lesser devices will do just fine?
That's the point of that.

I run tasks in smaller pieces and often get sub-ms loop() time.

Whatever task it is, if it doesn't have to be done in one pass then if it is a candidate to split.
If I have a cycle-heavy task, maybe an analog read, I put a return at the end to run loop() from the top and do the priority checks in order again. That takes writing blocks in loop(), not neatness-tucking everything into retentive functions and calls that load up the stack with return addresses and args. Well, at least you can inline some of it.

We start out learning to code start to end and then learn to make it interesting in between but it is single-process thinking, your code has all the resources and time is usually only something to work to reduce. It doesn't have to be that way. When all jobs are divided into short fast steps, control can be maintained through different process state variables and only the routines that should run, run.
What one program may put inside of a loop, I'd have a case block in a switch statement to run 1 iteration only. That case may run again in less than 50 micros or it might not, but it's going to finish and change the state to the next piece to run next time. In between, the sensors get read, then motors turn and the status led blinks steady.

And I've got a new trick that reduces RAM for running things on time, especially with arrays of timers.
Instead of needing two unsigned 32-bit variables per event, if you need 65.535 seconds or less, use unsigned 16-bit and mask millis() reads 0xFFFF to fit. The same reason why unsigned math doesn't have rollover problems makes this work.
I even used bytes to time denounce millis. I only needed to count to 10. 2 bytes can time up to 255 ms watchdog, 1 for start and 1 for interval, and even interval could be a const.

I find that things that need to be timed to less than a second usually don't need more than one minute duration if even that, though sporting and racing are two notable exceptions.