Become a better Arduino programmer..!

Community General Discussion
1

A lot of the 'issues' seen on these forums, are new users that jump into programming without 'reading the manual', and we see a lot of poorly constructed, unreliable or hard to maintain code.
In many cases, it's difficult to help these members, because their code is virtually unreadable by us - let alone the IDE/compiler!

Almost all the experienced devs in here want to help, but expect the OP's to also make an effort to help themselves.

Some concepts are hard to grasp until you've made a few mistakes, or played around a bit. Hardware development is a completely different 'kettle of fish'.

It's ok - and often desirable - to test your logic and code with simple 'sequential' logic to get it working, but that soon becomes massively overcomplicated or fussy when you try to debug or extend it.

Notwithstanding good style, which always helps - take look and see what you can learn about these elements...

  • Scope of variables
  • Arrays
  • Pointers
  • Data types
  • Functions (and calling/return values)
  • Conditional operations (Switch-Case-Default / If-ElseIf-Else / Do-Loop-While)
  • Logical and Bitwise operators

You will often see the experienced coders say don't use 'blocking functions' or 'delay()' and use a 'State Machine' along with other unhelpful hints...
When you understand the relevance of above elements, the whole picture becomes a lot clearer to write complex, efficient and more reliable code - that is EASIER to diagnose!

Finally... if your code doesn't do what you expect, and you've used good style - you can comment out function calls or other elements in order to isolate the faulty logic... then work on the broken parts independently.

Added: For the most part, the 'standard' Arduino libraries are fine, and convenient for most basic development.
As your application settles in, or you need specific performance improvements - you may need to look at creating some code to replace or work-around the less efficient, but convenient library functions.
And don't for a moment, think that because you installed a third-party library - that it must be well written. It's just someone else's code hiding in a black box - for better or worse!

Added: Arduino experimenters that want to work 'outside the board' - using switches, buttons, sensors, servos, steppers, LEDs etc... should stop for a moment and learn the very basics of electricity (not necessarily electronics).
With that basic knowledge - about 80% of the 'why doesn't my switch work', or 'the LED comes on when it should go off' questions would not exist.

Understanding VIN, 12V, 5V, 3.3V, 0V/Ground/earth etc will help a long way to realising your software ideas - before you write any code. Then reading a bit about current (Amps and mA) - will possibly save you from releasing even more white smoke.

2

Can't find a bit of that to say "Yeah, but..." to. Good job.

3

your observation is interesting, but....

learning on this planet is by reading. then mimicking what you read.

it is not possible to understand anything that is described by words you do no understand. just get some Russian electronics books and try to make a simple делитель напряжения you should have no problem, right ?

if you looked at that and went .. WTF are you talking about.... you have an idea what a newbie is faced with.

here is a simple list

συστοιχίες
δείκτες
τύπους δεδομένων
Λειτουργίες ( και αξίες κλήση / επιστροφή )
Υπό όρους πράξεις ( Switch - Case- default / Αν - ElseIf - Else / Do- Loop - Αν )
Λογική και δυαδικούς τελεστές

these are the things you say someone should learn about.

you did correctly point out that someone very experienced who says bloqueo is not good, thinks they are helping, but alas, the un-indoctrinated understands what you said at about the same level that you understand what I said.

now, if you understood every word I posted, you are bi-lingual and probably are smiling.
if you think what I posted is confusing as all heck, I would offer that what I posted is similar to some posts others post to the newest newbie.

4

if you understood every word I posted, you are bi-lingual

Greek, Russian and English would make you tri-lingual, at least.

5

The arduino being a beginner educational tool open to everyone will simply suffer from this "get results now without prior knowledge" mentality. Unavoidable.

The first program I wrote in arduino I made a very simple timer class to mimic windows idle loop because I just seriously couldn't live with the default dead-pan sequential loop and delays as it creates one big blob of a mess, but I understand why it was done like that in a first place - it is much easier to grasp a concept of a single loop vs interrupts/timers for the absolute beginner.

There is also sometimes an opposite effect from hard-core programmers - put too much complexity into a simple problem and no beginner can follow that at all. They can only blindly use such library without having any idea how it works.

6

Oscarko:
put too much complexity into a simple problem and no beginner can follow that at all. They can only blindly use such library without having any idea how it works.

Library code should be efficient, portable and understood by the compiler,
not necessarily by a user that has no idea of C++.

Interfaces should be documented, best by a different person than the author.

The examples should be as understandable and easy as possible.
Because many people use them as a start, examples should not block, or waste memory deliberately.

7

I am a strong supporter of @lastchancename's intentions.

And, unfortunately, I also agree with much of what @dave-in-nj has said.

I believe strongly that you can only teach someone when they have decided they want to learn and are, therefore, in a mood to take advice.

I also believe that some people are good at understanding programming concepts and others never seem to get their heads around them.

There are also people who expect to be "taught" without any notion that "leaning" is the other side of that coin. Those people never make any effort to find anything out for themselves.

With all this in mind my approach to the little tutorials I have written has been to produce code that works accompanied by a small amount of explanation. I believe that a long essay explaining every variant would do more to discourage than to assist. The Forum provides a convenient space in which to ask for clarification.

Which reminds me that there is another type of person who would die rather than ask a question that shows that they don't understand.

...R

8

I (mostly) agree with you Robin. This goes to the nature of "teaching and learning". I put that in quotes, because there is no "teaching", only "learning". Even though it is the name of my profession, I do not teach. I provide situations so the students can learn the topic (usually chemistry, but lately a whole lot more) I am trying to convey. And I explain stuff.

...
I believe that a long essay explaining every variant would do more to discourage than to assist. ...

This is the part I agree with most. Explanation is best applied in small, directed sessions.

Robin2:
...
Which reminds me that there is another type of person who would die rather than ask a question that shows that they don't understand.

...R

I encounter a lot of that. Sometimes it's not knowing enough to even ask a question, but also students have learned that "There are no dumb questions, except yours." I tell them this:

"All questions are dumb questions, because dumb means that you don't know something. So go ahead and ask a dumb question. If it's funny, I might laugh - sorry about that. But once you learn the answer, you won't be dumb about it anymore."

9

I think one of the greatest challenges to a Newbie is the wealth of information out there. Sometimes it can be just plain mindboggling.

There can be many ways to get to the same end point, some coders prefer one way and will not be budged other a completely different way.

As a teacher (certainly not in programming) i use the simple teaching style of EDIP.

Explain

Demonstrate

Imitate

practice.

Now i don't for a second believe that anyone giving there time freely on this or any other forum should adopt that style (although some are much better than others when trying to give assistance.

It is a great tool for structuring responses.

You need to look at [this] tutorial

it will demonstrate [this]

write them [these] out on your own if you go wrong see where.

then practice adding extra things in.

There have been many excellent tutorials that have been written on this forum and made stickies which are often referenced in replies.

go [here] or [there], however most new coders as with almost everything else in this world normally have an agenda or a particular problem (normally the same as 5 other posters on the same page).
They will go [there] and start to understand, sometimes the penny drops others a Newbie will just stare at code and the logic won't sit in the right place.

So they'll try another search and another until they return with 3 seperate pieces of code smushed into one with a "oh balls" expresssion.

I don't think that will ever change, all that can be done is to mitigate it with a well structured forum, try to be understanding and not give "thats a peice of crap" answers. They dont help.

People should be expected to put some effort into at least trying to make their own headway and, unless there is a magic bit of code that identifies if someone is writing code in their post and wraps it in tags, that one will always annoy people.

Lastly, I would say that there would be many things if this world that would not be here if it wasn't for someone saying "need a hand with that".

Thanks for all your efforts on behalf of the community.

Alex

10

A lot of people learn top-down coding so well they can't think any other way without a major effort.

Sometimes the others can be enticed to stretch just a bit and learn to get themselves off the rails.

You help your way but please don't set beginners in a rut they may not climb out of.

Reading is a good start. Doing is where the real learning happens.

11

All interesting observations... and they expose a flaw in 'online'... 'correspondence school' style of instruction. The lack of face-to-face interaction. And using purely written communication is extremely painful both for the helper and helpee ! Video tutorials only remove half of that pain.

Coding an outcome is extremely subjective, and there are frequently many ways to achieve a given result, however that doesn't mean they are all 'right', and being able to understand the benefits or failures of each approach is critical when building knowledge.

No matter how well you you learn simple sequential String, println() and Serial functions, that doesn't suggest in any way you'll be able to write robust, serial communications code. The concepts of asynchronicity, double-buffering, message framing and other vagaries can only be explained and absorbed by hands-on discussion and demonstration.

Yes, you can send and receive messages, but it's highly unlikely your bulky, simple spaghetti code can do both simultaneously! and good luck debugging or expanding it! ... and yes, I write crap code - then my OCD kicks in, and I just have to clean it up! I suspect OCD is a hidden ingredient within many developers.

ADDED A COUPLE OF LINES TO ORIGINAL POST

12

Something I have noticed with newbies in the Arduino land is the tendency to put all the hardware together, and then write the code - then wonder why it doesn't all work. This is especially a big problem when the hardware "design" is unique or otherwise custom by the builder.

What they don't seem to grasp initially is that you can code without needing all of the hardware involved.

Instead, one should apply "simulation" to the problem - digital outputs to LEDs, simple switches for basic input, potentiometers to analog inputs to simulate other controls.

Even make the code so that you can feed it fake inputs, and have it output data to the serial port and monitor it with a terminal.

That way - you can build up a simple test-bed, and get everything validated as to it being likely to work with the actual components. Then, once you are at that stage, slowly add each additional component, continuously testing and checking that everything is still working properly at each stage and change.

Eventually - you'll have the whole system together and likely working flawlessly. Not always, though - sometimes weird bugs crop up only when the whole thing (or a large part) comes together - but even there, the process of doing things incrementally can help. If for instance, a motor controller fails to work after you have added a sensor (in place of your simulated input or such) - but works again when you remove it - then you know that the problem lies with the sensor, how it is connected, the code, or a combination of those. At that point, you can step back and re-assess things to find out what the problem is.

Yes - this method is slower - but the benefits outweigh the frustration one gets when trying to do everything at once with a system completely assembled (without understanding it as parts - or even as the whole - and it possibly being difficult to isolate individual sections afterward).

13

lastchancename:
All interesting observations... and they expose a flaw in 'online'... 'correspondence school' style of instruction. The lack of face-to-face interaction. And using purely written communication is extremely painful both for the helper and helpee ! Video tutorials only remove half of that pain.

Coding an outcome is extremely subjective, and there are frequently many ways to achieve a given result, however that doesn't mean they are all 'right', and being able to understand the benefits or failures of each approach is critical when building knowledge.

No matter how well you you learn simple sequential String, println() and Serial functions, that doesn't suggest in any way you'll be able to write robust, serial communications code. The concepts of asynchronicity, double-buffering, message framing and other vagaries can only be explained and absorbed by hands-on discussion and demonstration.

I salute your position but beyond teaching basics, techniques and getting some past the next step it gets down to doing what I want to be sure is followed and not just taken.

I try to keep things to what I call simple and fish for live ones ready and able to make a leap or two.

I at least want to see better questions and changes produced as a project goes along and that's not just one way, I get to learn and adapt as well with the good ones.

Yes, you can send and receive messages, but it's highly unlikely your bulky, simple spaghetti code can do both simultaneously! and good luck debugging or expanding it! ... and yes, I write crap code - then my OCD kicks in, and I just have to clean it up! I suspect OCD is a hidden ingredient within many developers.

I wrote my share of spaghetti too even as I worked out ways to reduce it. A deadline environment with useless pressure from idiots who equate hours at the screen with progress does tend to force that kind of coding.

I just have to clean it up!

If you HAVE to RIGHT THEN it's OCD. If you want to and get time to do it, it's an intelligent practice that pays off in all the next-times. "Apple polishing" leads to new apples needing less polishing.

14

lastchancename:
and they expose a flaw in 'online'... 'correspondence school' style of instruction. The lack of face-to-face interaction.

This is a very important point. A huge amount of "information" gets passed by body language - especially the "does he understand what I just said". This needs to work in both directions, rephrasing the question or the answer.

cr0sh:
the tendency to put all the hardware together, and then write the code - then wonder why it doesn't all work.

This is just as true for people who think of the program as a single item rather than a collection of small pieces.

...R

15

Many 'more experienced' builders, will assemble the hardware first - because they already have enough knowledge to 'visualise' the software approach before a line of code is written.

This goes back to my OP, that learners might be better off trying not to solve the whole project in one sitting, but learn and write (functions for example), then bolt all the parts together - one at a time, to get the core of their ideas working.

Sure it may not work perfectly, but they'll have a far better understanding of the elements that make it work 'at all'!

ADDED A COUPLE OF LINES TO ORIGINAL POST

16

lastchancename:
... learners might be better off trying not to solve the whole project in one sitting, but learn and write (functions for example), then bolt all the parts together - one at a time, to get the core of their ideas working.
...

This is why solderless breadboards are so popular. Incremental learning is facilitated when the learner is not committed by each step: if you make a mistake, just fix it andmove on.

17

lastchancename:
And don't for a moment, think that because you installed a third-party library - that it must be well written. It's just someone else's code hiding in a black box - for better or worse!

I like this bit.

Another problem with libraries (and not just for the Arduino) is that they solve the author's problem but maybe they don't solve your problem. It is very easy to spend a lot of useless time trying to figure out or fix a library when it would have been quicker to write your own code in the first place.

...R

18

Robin2:
It is very easy to spend a lot of useless time trying to figure out or fix a library when it would have been quicker to write your own code in the first place.

Indeed. That's why I encourage noobs in my videos, where I can, to read and extract the relevant library parts (methods) and write their own version as you probably don't need the other 90% (certainly not to begin with anyway).

That way, even if you go back to the library, you understand the concepts behind all that code. Well, I guess that applies to a lot of us!

19

Perhaps one other factor that I have now added to the first post...

Arduino experimenters that want to work 'outside the board' - using switches, buttons, sensors, servos, steppers, LEDs etc...

...should stop for a moment and grasp the very basics of electricity (not necessarily electronics).
With that basic knowledge - about 80% of the 'why doesn't my switch work', or 'the LED comes on when it should go off' questions would not exist.

Understanding VIN, 12V, 5V, 3.3V, 0V/Ground/earth etc will help a long way to realising your software ideas - before you write any code. Then reading a bit about current (Amps and mA) - will possibly save you from releasing even more white smoke.

20

Ralph_S_Bacon:
Indeed. That's why I encourage noobs in my videos, where I can, to read and extract the relevant library parts (methods) and write their own version as you probably don't need the other 90% (certainly not to begin with anyway).

That way, even if you go back to the library, you understand the concepts behind all that code. Well, I guess that applies to a lot of us!

This is what I always try to do. I want to understand the concept then I know why things do not work.
But we are derailed here from the real benefit.
I thought 20 years ago that DIY electronics is dead. I was sure about it 15 years ago, and absolutely positive 10 years ago.
And look now, there is more people interested in electronics than I ever remember. Yes, some will really not get the concept and just follow some fritzing picture copy/paste sketch... but so what. At least they are doing something and not spending time answering post on Internet...ooops..