I am a pensioner starting out a new hobby. My Son bought me a Starter Kit - Arduino UNO with a projects book. I am familiar with hobby electronics but have never programmed anything with a computer. How reliable is the code information in the projects. following said codes intensely, some work and some don't.
The Forum seem to be written by people very familiar with computers and a knowledge of programming.
Basic information should be very understanding,with good examples explaining code errors and solutions.
Sorry for the mourning, It can be very frustrating, however I will persevere.
Problem is, a lot of us don't have the starter books, so until someone points out a particular problem, we're not likely to be aware of them.
The key thing to remember here is that the C compiler is better and more pedantic than any human proof-reader (myself included); it will jump on the the tiniest typo.
If you have specific problems, please feel free to ask - copy and paste the exact code you are trying to get to compile/work and the exact error message you get.
Hi alysma,
It was hard to write. It should be hard to understand. To some extent I'm kidding but to a greater extent, this can be true. Some of us are seasoned professionals (raises hand) and we still come here to ask questions when something doesn't work as expected (raises hand again. ) Don't be put off if the discussions do not always make sense. The deep end of this pool is very deep indeed. You can still have a lot of fun at the shallow end but you need to get your feet wet. (Pun not intended but somehow seems appropriate. )
The book I learned C from is "The C Programming Language." Amazon lists it at over $50 US and my copy went for $25 in '78. I recommend checking to see if your library has a copy - it should! It's oriented toward Unix but the principles for programming C remain the same. (I just looked at my copy and perhaps it is not the best since the examples rely heavily on text output and that is not part of the default Arduino setup. The Arduino equivalent of "Hello World" is to blink an LED.)
If this book (or a similar one) is not readily available (or if you prefer reading stuff on the web) just do a search for "C tutorial" or "introduction to C programming" or similar and some of the links might be helpful. A little background in C will help you to understand what the code in the examples is doing.
I don't know what you have seen or not but the Arduino site has a lot of pages for references and tutorials. Would you like some links to bookmark just for starts?
Every day, read the threads in the forums that sound interesting.
You can usually learn something new each time.
Pick a small project, do your best to complete it, when you have problems or don't understand something ask for help.
and many of the posts there have comments on tutorials and books. You can also go to Amazon.com, type in Beginning C Arduino and see what comes up. They have a reader reviews section that you might find helpful, plus the photo of most book covers have a banner across the book's cover that says "Look Inside". Clicking on that allows you to look inside the book. Check out the Table of Contents to see if something of interest pops up.
I'm retired, too, and I think you'll really enjoy this activity once you get over that first hurdle.
econjack:
I'm retired, too, and I think you'll really enjoy this activity once you get over that first hurdle.
There's quite a few of us here. You couldn't swing a cat without hitting a few pros.
Sometime the hard part in helping is finding what the person does and doesn't know.
There is also the difference between the standard C main() and Arduino setup() and loop() for the really new people. It's a tiny thing but when you know nothing, that difference alone can be daunting.
alsyma, we want to get you in and going as smoothly as possible.
Beginning code is not so hard. It is all instructions for a machine.
With simple examples and a decent reference (both are provided) you should be able to trace line by line what you think should happen and then check against what does happen, and there are ways to do that.
I've got shoes older than that! I was lucky enough to get an NSF grant in the late 70's to study microcomputers in Education while I was teaching at Butler University. My instructors were Peter Rony and David Larsen (of the Bugbook Series) and we did our assignments on a KIM-1 with 256 bytes of memory! Long in the tooth? Yes, but I'm still learning stuff here.
econjack:
I've got shoes older than that! I was lucky enough to get an NSF grant in the late 70's to study microcomputers in Education while I was teaching at Butler University. My instructors were Peter Rony and David Larsen (of the Bugbook Series) and we did our assignments on a KIM-1 with 256 bytes of memory! Long in the tooth? Yes, but I'm still learning stuff here.
My 1979 TI-59 beat that!
LarryD:
Shoes older
Boy things have sure changed, haven't they?
The first computer I worked on was a brand new PDP8S.
Sounds like lots of us have a great hobby now.
Did it have the panel lights showing the register states?
Did it have toggle switches or thumbwheels?
Did it have magtape? Teletypes? Card reader? Keypunches?
Or stuff to drool over like disk drives and packs or even 8" floppies?
I read 1966 there? I was still a kid. My bronzed shoe is 50's.
One thing when learning to program is to distinguish between different kind of errors:
Compiling errors: missed; spelling, syntax, declarations etc. The compiler will find these and alert you. Choosing sketch/compile (ctrl+r) will invoke the compiler and tell you the errors. Doing so frequently is a good habit, compilation takes just a couple of seconds and you will learn to interpret compiler messages. Of course a incomplete program will not compile but you can circumvent this by writing empty functions (stubs) that compile but don't do anything
Hardware interface errors, you have choosen the wrong pin number or the wrong i2c or spi adress. Or you have specified the wrong baudrate etc. Your program will compile and run but it is not getting or sending the data
Logical and computational errors. Your program makes false decisions or calculates incorrectly
Great thread.. Lotsa good stuff mentioned and as pointed out earlier.. The internet is a great place to find out how to learn.. I for a small voice personally like http://www.cplusplus.com/doc/tutorial/.. While not aimed at embedded C++ it has been a real great resource for me..
I have also made friends.. Here and there who are most helpful.. There are many used book stores where you can buy serviceable material as well... It doesn't have to be new or pretty to be educational..
Education is/must be incremental... Rome, Wasn't built in a day.
nilton61:
One thing when learning to program is to distinguish between different kind of errors:
Compiling errors: missed; spelling, syntax, declarations etc. The compiler will find these and alert you. Choosing sketch/compile (ctrl+r) will invoke the compiler and tell you the errors. Doing so frequently is a good habit, compilation takes just a couple of seconds and you will learn to interpret compiler messages. Of course a incomplete program will not compile but you can circumvent this by writing empty functions (stubs) that compile but don't do anything
Hardware interface errors, you have choosen the wrong pin number or the wrong i2c or spi adress. Or you have specified the wrong baudrate etc. Your program will compile and run but it is not getting or sending the data
Logical and computational errors. Your program makes false decisions or calculates incorrectly
Design and approach errors
data errors. I've seen data be the culprit many times, Program = Code + Data.
Sometimes it's unfilterable GIGO leading to questionable results and a bug hunt over a mistype.
Still, idiot-proofing is next to fault-tolerance in making crash-resistant code. I don't say 'proof'. Murphy's Watching.
Fault tolerance and error handling are far easier to handle with state machine as opposed to checklist code.
The checklist code is braces { } bound. Exceptions just add braces and complications to structure-bound checklist code, any deviation from the expected path spawns more spaghetti code.
With state-driven code, the code for the current process state is run in a switch case and that code may change the state value to run any different case next time around, the order can be variable on notice. It reduces indent levels and increases modularity and response. Add in time, pin states and change detections and interrupts that all can be used to change the process state, total path flexibility at high speed.
That's what I think that MCU's are designed to run is real time event driven code.
The Arduino setup() and loop() serve it well.
) Don't be put off if the discussions do not always make sense. The deep end of this pool is very deep indeed. You can still have a lot of fun at the shallow end but you need to get your feet wet. (Pun not intended but somehow seems appropriate. 