PLEASE ask hardware questions BEFORE software questions!

It's staggering how many questions here are related to the simplest problems - akin to a battery, switch and light bulb.

Don't try to make software fix something that doesn't fundamentally work in hardware. Remove the Arduino - then make the switch and LED or MOTOR work FIRST - then put the processor in the middle!

OK, so i got out the wrong side of bed today !

Hi,
Interesting point! I guess us hardware guys who started with vacuum tubes way before software existed automatically do that. But a good pointer for today.

lastchancename:
Don't try to make software fix something that doesn't fundamentally work in hardware.

I do understand your frustration. Maybe the point is that a basic knowledge of electricity is almost essential and is often missing.

But Arduinos are associated with lots of hardware that cannot be tested without the Arduino - ultrasonics, stepper motors, servos, wireless comms for example.

...R

Robin2:
I do understand your frustration. Maybe the point is that a basic knowledge of electricity is almost essential and is often missing.
But Arduinos are associated with lots of hardware that cannot be tested without the Arduino - ultrasonics, stepper motors, servos, wireless comms for example.
...R

"...and is usually missing."
Of course I agree - hence my earlier 'wrong side of bed' quip!
I don't think we should completely let the newbies & lazybones off the hook so lightly.

Ultrasonics, stepper motors, servos, wireless comms - can all be 'simulated' and monitored with LEDs or serial.print - and observing the basic logic operations before they buy the parts. This isn't the project - it's proving your first principles of the project at hand.

In fact I'd suggest that all new projects should be 30% functional before wiring the pieces together - assuming you have a basic understanding how to wire them together - which started this thread :slight_smile: !

I'm working on a web/telnet-based project for another member of this forum - which drives four bi-directional 24V motors along with other requirements - yet I have no motors or power supply and different processor hardware - but can guarantee the code works before it leaves my workroom.

(Go back to post #1 !)

lastchancename:
which drives four bi-directional 24V motors along with other requirements - yet I have no motors or power supply and different processor hardware - but can guarantee the code works before it leaves my workroom.

IMHO the reason you can do that is because you know A LOT of stuff that a newbie hasn't a clue about.

And it's not "simple" knowledge that you have either - I mean it is not the sort of thing you could teach a newbie with one or two pages in a text book.

One of the skills that IMHO makes a good programmer is the ability to see a pattern in one piece of code that can be applied to a very different project - to be able to focus on the few similarities in a crowd of differences.

The same sort of thing can be applied to hardware. But in my experience most people are just as confused by hardware - and not just electrical stuff. It takes a considerable skill or knowledge to envisage an LED as a substitute for a relay.

...R

Robin2:
IMHO the reason you can do that is because you know A LOT of stuff that a newbie hasn't a clue about.
And it's not "simple" knowledge that you have either - I mean it is not the sort of thing you could teach a newbie with one or two pages in a text book...
...R

But I believe that example is minimal understanding - a relay or a LED are simple two-state devices (on / off) they are interchangeable when visualising actions or simulating control. A switch is (usually) a two-state input device - same rules.

This very fundamental hardware knowledge is absolutely necessary before you put 12V into the 5V pin on your Uno. The only reason there aren't more tears on this forum - is the USB supply, and/or the DC plug-pack input. Don't imagine for a moment that 40% of the participants have any idea of the difference between AC/DC 1A/2A, or +12 and +5 or 3.3V interfaces.

We already see novices loading pins or the 5V rail with motors and searchlights - simply because they have no idea of basic electrical circuits, voltage, current, power etc.

Taking those fundamentals forward to pull-up, negative-logic, high-side/low-side and other staples of a design - simply means they aren't ready to build anything yet. They are ripe candidates for questions and hand-holding, but really - you can't sell me that these MEGA powered pigeon feeders are working at half theor potential of reliability, or consistency (nothing to do with performance).

If newbies are tortured because they blew up their Arduino on day two, they really should be careful of the drain cleaner under the sink. The sticky posts and these threads are there to save them from themselves - but they choose to ignore every one, every time!

The experienced players aren't here to glorify ourselves, but to hammer some basic project 'common sense' into their soft skulls before ours implode!

Yes, I'm OCD - and on the wrong side of the bed!
Perhaps the next Arduino should be The Darwin - especially for newbies! (natural selection - that's harsh!)

lastchancename:
Perhaps the next Arduino should be The Darwin - especially for newbies! (natural selection - that's harsh!)

I have a "Darwin" version of an nRF24L01+ module. :slight_smile: There is a complete short circuit between Vcc and GND and I don't think I put it there. There is no sign of damage or anything unusual on the board.

...R

Robin2:
I have a "Darwin" version of an nRF24L01+ module. :slight_smile: There is a complete short circuit between Vcc and GND and I don't think I put it there. There is no sign of damage or anything unusual on the board.
...R

(( Vcc = left ear, GND = right ear )) :o
That's a shunt - just for us electrically inclined types!

lastchancename:
But I believe that example is minimal understanding - a relay or a LED are simple two-state devices (on / off) they are interchangeable when visualising actions or simulating control. A switch is (usually) a two-state input device - same rules.

this is all well and good, but the amount of understanding of a coil is staggering for a newbie.

first off, it is just a long wire. why is not a short circuit ?
has to do with magnetic fields and induction and capacitance.......
how much power do you need to charge the coil, then how much to keep it charged ?
inductive spike ?
collapsing magnetic field ?

steppers are coils, but you charge them with 30 times move voltage than they are rated for, but you charge a relay coil with the nameplate voltage.....

when you get into a simple part like a coil, it takes a week to cover all the aspects on broad general terms, then another week to understand how to run a stepper coil or choose an electromagnetic coil or a metal detector coil

while it is true that you have to have some grasp of the concepts of your parts, and while it is true that sometimes a complete understanding eliminates the need for a micro-controller in the first place, the depth of understanding to do a thing is often not important to get results.

have a how-to guide for a new project is like writing a business plan. you have to have someone hold your hand each step of the way. and you will make mistakes along the way.

a simple template with simple instructions on how to do a flow chart would help some people greatly, and confuse the heck out of others.

I would propose that a simple 10-step guide to a new project would help newbies in ways we have yet to imagine.

#1 what is your end goal ? don't get lost trying to figure if you need to cut the blue or the red wire... what is the END goal ? make sure you have that pretty clear.

#2) mysteries are just questions we have not answered and knowledge is based on understanding, TRUE understanding, not superficial glossing over some text or web page. we often focus on the mystery, not the goal.

#3) if you have a mystery, a block or a chasm that you cannot see the other side, DO NOT MAKE ASSUMPTIONS and DO NOT RULE OUT anything. if you were able to make such decisions and rule things out, you would not need help. and often the answer is the thing you ruled out, see #2

#4) anything you can make, be it software or hardware, can be represented by a drawing with pencil and paper.
make a sketch, as you try to connect things, you can put in blocks and label [ magic happens here ] if you do not know.
your sketch, call it a diagram a schematic or a flow chart, will be helpful to others who might offer help, and may answer your questions as you figure things out.

#5) search for something like that. often a garden sensor is exactly like a weather station and is exactly like a clothes dryer control. you measure, decide, control. sometimes the answers are in front of you already.

#6) figure out how you can break your project into baby steps. do the ones you know about as a module. make it work,
you may want to have a light flicker and blink, but that is really just turning it off and on with some timing. make it turn on and off first, then add the timing.

#7) make sure things work together. using your 12 volt motor with a 5 volt sensor and a 3.3 volt micro powered by a 230 volts is not hard, but you have to attempt to purchase the things that work together easier. this is like putting the load on the cart, before having either the horse or the cart.

#8) mistakes will be made, expect that. if you make small ones, it is easier to fix.

#9) expect that your first attempts will dump the wagon, then fill it and the horses will run in circles. take pride that you could get the horse to run in the first place, getting things to work together has been the goal of Churches, governments, businesses and parents for centuries. don't expect to get it ring the first time.

#10 ) maybe the most important, it is better to make a foolish question than a foolish mistake.
IGNORANCE gets you into trouble PRIDE keeps you there.

But Arduinos are associated with lots of hardware that cannot be tested without the Arduino - ultrasonics, stepper motors, servos, wireless comms for example.

There is no reason, though, to try to put all of that hardware together, and try to run PID and a web server and web client, and 40 bazillion blinking LEDs as a single, first-time-ever-writing-a-program sketch.

Test ONE piece of hardware at a time. When you have a sketch that controls one piece of hardware and another sketch that controls another piece of hardware, THEN it is reasonable to combine them, and learn about pin conflicts, timer conflicts, PWM issues, memory issues, etc.

When all the hardware works in one sketch, THEN, for example, one can add PID, to make the output (whatever it is) proportional to the input (whatever it is).

It's certainly amazing the number of people that post 400 lines of code that won't even compile, and wonder why the hardware doesn't work.

And, one final point. By asking the hardware questions first, you won't be stuck with trying to use the wrong kind of hardware. Buying a DC motor and hoping you can use it as a servo is silly. Buy a servo, if that is what you need.

Robin2:
But Arduinos are associated with lots of hardware that cannot be tested without the Arduino - ultrasonics, stepper motors, servos, wireless comms for example.

...R

^ ditto...

Also.. sometimes, especially if a 'noob'.. they might not know or understand that it can or can not be used with or without an MCU/Arduino..

I consider the above to NOT be the same as PaulS outlines.. I 100% agree that projects (especially if you are a beginner) should be broken down into its individual parts/functions and understand how they all work.. and THEN try to get them all to work together.

I have been happy to support @lastchancename's Solving Project Problems Thread

But I think it is much more difficult to address hardware advice to newbies - there is such a wide range of different hardware and such a wide range of ignorance (in the polite sense).

It is even interesting to look through a few Threads at the different initial understanding of the problem by different experts.

To be helpful the teacher has to see the problem from the same point as the student. Without being able to stand in the students shoes it can be very difficult to bring his/her level of knowledge to the level that is taken as "normal" by the expert.

Perhaps the best advice to give a newbie would be
"Tell us exactly what hardware you plan to use and tell us how much you know about it. Don't be afraid to say you "know nothing" as it will make it much easier to explain things in terms that you understand. And if you get advice that you don't understand please tell us. If you don't, we will assume you do understand and that just cause confusion and wastes time."

This could be tagged on to the other Thread.

...R

Robin2:
...To be helpful the teacher has to see the problem from the same point as the student. Without being able to stand in the students shoes it can be very difficult to bring his/her level of knowledge to the level that is taken as "normal" by the expert.
...R

Extremely valid.
Some experts are simply unable to bend down to the novice level - their understanding has moved on too far, and they don't speak or listen the same language.
This is why the best teachers are often not from directly within 'the industry' - as they have the patience and innocence that has been lost on hardened, experienced players.
(Guilty)

What about problems with firmware? Do these come into the definition of hardware or software problems ? :slight_smile:

Firmware - as in libraries? or gcc itself?
Otherwise the only firmware in a micro is YOUR code.
(Ignoring instruction microcode in the silicon!)

lastchancename:
they don't speak or listen the same language.

That is a very helpful way of expressing the situation. Listening is often so much more important than talking.

I often find it useful to say "I don't think I understand what you are asking, can you explain it again"

...R

lastchancename:
Extremely valid.
Some experts are simply unable to bend down to the novice level - their understanding has moved on too far, and they don't speak or listen the same language.
This is why the best teachers are often not from directly within 'the industry' - as they have the patience and innocence that has been lost on hardened, experienced players.
(Guilty)

teaching as if your student does not any clue what you are talking about. ie: teach on THEIR level.
Ask the first 20 people you meet today how to use code tags.

a person cannot understand ANYTHING past a misunderstood word, so you cannot just toss out detailed examples, you need to use baby words until THEY grasp and comprehend the meaning.

you know an exponent is how many times a number is multiplied, but a 1st grader does not even understand addition.
the person does not understand the meaning of the words you use in your help, they cannot become masters of help they are given.

probably the only thing a school needs to teach, but the teachers are not aware of concept because they were never taught it.

you say use code tags,..... they are not aware it is an idiom.
they hear code tags... they think... code = programming..... tags = notes........ ok, add notes to my program.

Firmware - as in libraries? or gcc itself?
Otherwise the only firmware in a micro is YOUR code.
(Ignoring instruction microcode in the silicon!)

Tell that to the bootloader. Or, the firmware in a WiFi shield.