Go Down

Topic: BEGINNERS: We rarely write code for you, but will help you write it for yourself (Read 8538 times) previous topic - next topic

Kiwi_Bloke

As a newbie with little experience in electronics or programming (I have programmed at low level Rockwell/Allen Bradley and Schneider SLC and PLC Ladder logic controllers), my advice to fellow newbies would be read as much as you can, start small, try the demo sketches and think about how they work then ask targeted questions.

Be prepared to get caustic responses from experienced members who see the same question over and over but always look at the WHOLE response because there is normally some clue to finding the next step on Google.

Please read and understand the stickies about how to post code and circuit diagrams etc, even I get frustrated when I see a post looking for a high level solution and the poster hasn't even worked out the difference between Delay and Milllis timing.

Don't just vanish half way through the thread, if you find another solution say so, if you can the project say so, if it all gets too hard say so.

Regardless of the outcome a simple thank you to the people who tried to help goes a long way, simple manners don't cost.

Most of all have fun!!

Kia Kaha
Kiwi






lastchancename

Thanks kiwi - a refreshing reply, taking responsibility for your own learning!
The older guys can take the lead in teaching, but can't do both.

Most of all, have fun.  Kia Kaha!
Experienced responders have a nose for laziness, (they were beginners once)... expecting the poster to contribute to the learning experience.

Kiwi_Bloke

Thanks kiwi - a refreshing reply, taking responsibility for your own learning!
The older guys can take the lead in teaching, but can't do both.

Most of all, have fun.  Kia Kaha!
The "older guys" can only teach (and maybe mentor?) those that want to learn.

GoForSmoke

The hardest thing to teach is anything new to the student. There seems to be some kind of horror of the unknown.

So what is behind a section 2 Arduino tutorial example (BWD) becomes hard perhaps because anything so key must be?
Consider that arrays and loops are section 5 beginner tutorial material.

Maybe the hardest thing is believing how simple it can be even when that is shown?

I posted an example that has two tasks in loop(); one that blinks led13 if a flag variable is set and another task that watches Serial for a newline char and when it gets one, toggles the flag and turns the led on or off to match the flag. It's a blinky with stop and start control, it is short.

So far only experienced members seem to fathom that it's not black magic or science so advanced it's indistinguishable from black magic. I have to wonder if those who don't get it are able to follow code line by line at all. Perhaps not.

Learning to follow code line by line is more important than learning all the commands. If you have any doubt about a command or its use you can look it up and find out, just doing that will strengthen your memory till you get it right by habit. It's a matter of personal development, why fight that?
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

lastchancename

Quote
Maybe the hardest thing is believing how simple it can be even when that is shown?
Without being disrespectful to 'those' learners - they quite seriously ma be better suited to Meccano, Lego or other physical hacking.
Not every person has logical and intangible problem-solving skills.... and god knows the software/tech community often need mechanical hackers to help!
Experienced responders have a nose for laziness, (they were beginners once)... expecting the poster to contribute to the learning experience.

Kiwi_Bloke

I posted an example that has two tasks in loop(); one that blinks led13 if a flag variable is set and another task that watches Serial for a newline char and when it gets one, toggles the flag and turns the led on or off to match the flag. It's a blinky with stop and start control, it is short.

So far only experienced members seem to fathom that it's not black magic or science so advanced it's indistinguishable from black magic. I have to wonder if those who don't get it are able to follow code line by line at all. Perhaps not.
Would you mind reposting the link to that please? I could use that in my ongoing Data logger project.

Thanks

GoForSmoke

Here ya go. I had to do a fix to make led13 shine bright like it should. The other night it flashed weakly because the led on pin 13 can get small current bleed due to how it's wired. So I added the pinMode() line and now it's as bright as it should be. It was late and I wanted done so I took flashing as my sign it worked... oh well, it's brighter now!

Code: [Select]

// Blink with serial control, free for the Arduino.cc forum members and archives.
// Set your Serial Monitor for 115200 baud with newline printed at end of entry.
// Made on UNO R3 with IDE 1.6.9
// By GoForSmoke 1/24/18

#include "Arduino.h"                  // 1

unsigned long blinkStart, blinkWait = 250;       // 2
byte doBlink = 1, ledState = 1;                  // 3
const byte ledPin = 13;                  // 4


void setup()                  // 5
{
  Serial.begin( 115200 );                  // 6
  pinMode( ledPin, OUTPUT );                 // 7
}

void loop()                  // 8
{
  if ( doBlink )                  // 9
  {
    if ( millis() - blinkStart >= blinkWait )                  // 10
    {
      blinkStart += blinkWait;                  // 11
      digitalWrite( ledPin, ledState );                  // 12
      ledState ^= 1;                            // 13
    }
  }

  if ( Serial.available())                  // 14
  {
    if ( Serial.read() == '\n' )                  // 15
    {
      ledState = doBlink ^= 1;                  // 16
      digitalWrite( ledPin, ledState );                  // 17
    }
  }
}
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Kiwi_Bloke

Thanks it works (after i noted to select newline :smiley-confuse: )
Is there a way to make it a specific number or better still a phrase or word?

GoForSmoke

Well yes though you might want to work up to the word-recognition.

How comfortable are you with this sketch? Is any of the syntax not familiar?

Most important is do you understand how it works? It's a bit like a running motor with a 1 speed plus neutral gearbox, isn't it?

With you on solid ground about this then it's next step time, you can skip the 1st tutorial listed in my sig space below though you might want to scan through his (very good) explanations to catch the parts on blocking vs non-blocking code and see what techniques he uses. Good technique is worth stealing... errrr, copying!

If you are solid on the above, go to this tutorial (  http://www.gammon.com.au/serial ) and scroll down to part 2, State Machine.

I think that this is close to what you want. The step to recognizing command words means adding states to collect the chars that make the word, watching that each in turn does match and to handle errors when the input text does not match.

Quote
State Machine


Another way of processing incoming data, without blocking, is to set up a "state machine". Effectively this means looking at each byte in the input stream, and handling it depending on the current state.

As an example, say you had this coming into the serial port:


R4500S80G3


Where Rnnn is RPM, Snnnn is speed, and Gnnnn is the gear setting.

The state machine below switches state when it gets a letter "R", "S" or "G". Otherwise it processes incoming digits by multiplying the previous result by 10, and adding in the new one.

When switching states, if first handles the previous state. So for example, after getting R4500 when the "S" arrives, we call the ProcessRPM function, passing it 4500.

This has the advantage of handling long messages without even needing any buffer, thus saving RAM. You can also process message as soon as the state changes, rather than waiting for end-of-line.
So anyhow the next step is yours if you want to take it. Start a thread about your particular code and leave an invite back here. If you have any questions be sure to ask, trouble-shooting is about eliminating unknowns so it's easier to spot errors which we ALL make.
Part of writing compiled code is that if you write much you have to deal with being wrong many times before lunch until you have the code tamed at least, then you're wrong less times per hour. If you're hardly ever wrong, you're probably not doing much either. If you're never wrong you probably don't write code at all, just sign the checks and make the deadlines.

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

232

I have been reading thru this post by forum participants  with more than 10 posts under their belt.
In past week I also read few first time posts and followed some of the resulting discussions.
It seems that an average discussion lasts few pages and seldom involves the original poster.

Maybe this particular discussion would be more useful, it is IMHO just bunch of vents, to have you "frequent flyers" attempt to analyze why beginners ( in Arduino forum in particular) behave in real world and not in your naive outlook HOW they should behave.

Perhaps a fresh look on some of  the long winded "how to" tutorials is due instead of this group exchanging views on beginners misbehaving.

For example - most first time code post are poorly formatted because IDE formater is buried somewhere, if it even is documented.

Maybe beginners with short attention span would benefit  from simple one liners"how to " instructions.
In no particular order order :

Comment your code to avoid "what it does ?" replies.
Use code formater before posting your code
If it does not compile it won't run
Turn on ALL (compiler) error monitoring
Referring to "line number " is useless when you did not turn "line"  on.
Post ALL error messges ( memory is cheap )
Check you sketch logic structure BEFORE troubleshooting hardware
WRITE , for yourself, down WHAT your sketch suppose to do.
There are three basic "problems" when writing software
1. Typos
2. Code syntax errors _. such as ; in wrong place
3. Logical errors - == versus =, reading serial data and not collecting the results..
Do not apologize if your are  a beginner
Do not apologize for your poor English
Use "scaffolding" (google)  to help to pin point the issue




Thunder is good, thunder is impressive; but it is lightning that does the work.

Robin2

Maybe beginners with short attention span would benefit  from simple one liners"how to " instructions.
In no particular order order :

Comment your code to avoid "what it does ?" replies.
Use code formater before posting your code
If it does not compile it won't run
Turn on ALL (compiler) error monitoring
Referring to "line number " is useless when you did not turn "line"  on.
Post ALL error messges ( memory is cheap )
Check you sketch logic structure BEFORE troubleshooting hardware
WRITE , for yourself, down WHAT your sketch suppose to do.
There are three basic "problems" when writing software
1. Typos
2. Code syntax errors _. such as ; in wrong place
3. Logical errors - == versus =, reading serial data and not collecting the results..
Do not apologize if your are  a beginner
Do not apologize for your poor English
Use "scaffolding" (google)  to help to pin point the issue
Your concept is good but I'm not sure that your one-liners would be as obvious to a beginner as you think.

In this Thread there seems to have been general agreement that tutorials should not include rambling discussion. However I have not been able to persuade others of the virtue of only having a few items in the beginner's tutorial section.

And the problem of implementing and policing any system has not been resolved.

A big problem in dealing with beginners is that everyone is only a beginner for a very short time and what seemed like a mountain when the person was truly a beginner quickly changes to the smoothness of a putting green. In your one-liners I sense this is beginning to happen to you, also. And, of course, one needs to have knowledge (i.e. to be on the putting green) to impart it to a beginner.

It is also important to distinguish between beginners who are ignorant in the sense of absence of knowledge and those who are ignorant in the sense of discourtesy and bad manners.

Computer programming requires great clarity of thought and the compiler is brutally unforgiving. I find it hard to reconcile an expectation of getting a program working when the person's Post clearly shows that they cannot follow simple instructions and don't have the initiative to try to solve their problem with the aid of Google who puts the whole world of knowledge at one's fingertips. Perhaps the problem is that a false aura of simplicity has been created around the concept of programming because so many software products are available for free or very cheaply and the hundreds or thousands of hours needed to create them are not visible.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

lastchancename

@Robin2 is right...
sometimes the rambling discussion is needed to put specific explanations i. context.
A simple one-liner will only help if the person knows what they're trying to achieve, and 'how to hold the hammer'. Often they don't!

As the OP, I start these threads to attract learners with the topic name, then to stimulate critical thinking, conversation and coding strategy.
Your list above is well informed, but learners often don't want to read, can't understand what is written, or are too impatient to put in the hard yards...

Remember the stages of learning
* Unconscious Incompetence
* Conscious Incompetence
* Conscious Competence, and finally
* Unconscious Competence....

Consider these representing the starting point, 6-months, 12-months, and 2 years milestones of a dedicated beginner's learning cycle --- assuming they have access to a well informed tutor.
Experienced responders have a nose for laziness, (they were beginners once)... expecting the poster to contribute to the learning experience.

GreyArea

I find the best teachers are those at the "conscious competence" stage. They know how to do it, but they still have to think about it...

There's a risk that an assumption of knowledge creeps in at the unconscious competence stage ("I'm sure I knew this when I was at your stage...") so sometimes critical information can be omitted...and sometimes a little frustration creeps in when it has to be re-explained at a later stage.

It's harder to do in an internet forum, and arguably noobs with their "I want it now" attitude don't help...but a good teacher always checks the existing knowledge of their student.

I just realised this whole thread put me in mind of a real story my best mate once told me.

His younger sister would often get punctures on her bike and always asked Big Bro to fix them. She'd be about ten, him about 15. One day he said..."Come on then, I'll show you how to do it."

Her priceless reply...

"I don't WANT to know how to do it. I want YOU to do it FOR me!"

Hmm, I wonder if she visits this forum... :-)


LesserMole

Her priceless reply...
"I don't WANT to know how to do it. I want YOU to do it FOR me!"
In principle, there's nothing wrong with that attitude, as long as one realises that in real (adult) life with no big brother, $$$ usually need to change hands.

I'm very bad at making a nice job of window putty: I pay people to replace window glass for me. I really cba to learn how to do it efficiently, effectively and neatly. It's worth $$$ to me, not to have to worry about crap like that.

That's presumably why this forum has has the gigs board: someone might think Arduino could be a solution to some problem and (perhaps after a quick dabble) realise they don't have the skill, background or quite simply the inclination to figure out how to do it themselves. Pay someone, turn the key, vroooooom. Problem solved.




Robin2

Her priceless reply...

"I don't WANT to know how to do it. I want YOU to do it FOR me!"
Some people seem to get through life effectively with an attitude of "pretend helplessness" There are people who respond well to that attitude and do the necessary chores - usually in return for "Gee Gerry (or Mary), you're great, whatever would I do without you"

In the real world where people can see each other it may be that those types easily identify each other, and equally easily avoid others who don't want to play the game.

If so, maybe the crunch comes when the "pretend helpessee" gets told "learn how to do it yourself" by a Forum member who is not interested in being a patsy.

...R

Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up