I am new to the programing world, and am trying to learn how to write the code for the arduino. I thoroughly read "Getting Started with Arduino" but still I am not capable of writing coherent code. My biggest problem is I really don't know any command's the arduino would understand. How do i learn the language?? If someone would point me in the right direction the would be very helpful. Last year my school offer a C++ programing class but just dropped it before i could take it, do I need to learn C++ anyways? Any help would be appreciated.
Many learn the Arduino C/C++ language without formal classes. There are several tutorials around including this on the Arduino site:
I learned mostly by lots of referring to this page:
While loading/running and studying the example programs that are included in the Arduino IDE files section.
And of course there are hundreds of free C/C++ reference manuals available on the web. Like I said I'm still learning but mostly by reading and studying other peoples sketches and libraries.
Lefty
IMHO you should start small, perhaps more simple than programming with something like a PICAXE, just until you understand the processes involved. Then learn ASM, it's faster than C (due to compilation, that is translating C into 1s and 0s for the chip to execute) and all the cool kids use ASM. Then go to C, ASM I'm told is very simple, if a little unusual at first, but it will be a closer step from flow charts and BASIC to ASM than that to C. My two cents, feel free to pick it to pieces.
/me
My two cents, feel free to pick it to pieces.
I won't pick it apart, you are entitled to an opinion. However I do think it is very poor advice. Learning ASM as a path to mastering C is not required and a real time sink to mastering the Arduino platform.
Lefty
Uh yea, suggesting someone start with assembler? I have a feeling that poster is trying to be funny or sarcastic.
The whole reason high level languages exist in the first place is because humans don't think like a compiler does. Why do we have languages that are human readable then, if assembler is so great? Oh thats right because it is tedious, laborious to program, difficult to debug and completely counter intuitive for the majority of human beings.
Learning assembler first is a great way to get really discouraged and give up.
Learning C is a great first step, and you do not need assembler to learn a great deal about programming and get a lot accomplished. Later on after you have experience you can learn about what is going on under the hood and study assembler if you want.
ASM I'm told is very simple,
Hmmm..., who you been talking to? I'd suggest a beginning C/C++ book, and compare what you see there to what is in the various arduino sample scripts that are available.
suggesting someone start with assembler
Luxury, when I started there were no assemblers. You wrote it down in mnemonics like an assembler and then you looked up what hex value belonged to each mnemonics along with doing some bit oring to reference the register you wanted.
Mind you, you'd have to be mad to do that nowadays, it's just we hadn't a choice when I started.
IMHO you should start small, perhaps more simple than programming with something like a PICAXE
Then learn ASM, it's faster than C (due to compilation, that is translating C into 1s and 0s for the chip to execute) and all the cool kids use ASM.
Then go to C, ASM I'm told is very simple, if a little unusual at first, but it will be a closer step from flow charts and BASIC to ASM than that to C.
What is this - Let's Have Fun With A Noob Week?
PIC(axe) - possibly the worst imaginable processor to start to learn assembler language programming, thanks to the paged RAM Harvard architecture.
Cool kids learn ASM? People with too much time on their hands and no interest in team-work program in assembler from scratch on modern processors. I've been seriously uncool for the last twenty five years, and have written probably no more than 2000 lines of assembler in that time.
BASIC?
I think of the company advertising "Thought Processors" or the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery. Edsgar Dijkstra
Actually, I was going for the flow char environment to ASM, because ASM is very much like a flow chart without arrows it seemed reasonable to go from The flow chart to there, if it were starting at BASIC I'd have said go with C afterwards, because that would be a smaller jump. Also, those PICs
are fairly good, an AVR won't run at 40Mhz
Actually, I was going for the flow char environment to ASM
A flow-chart? Does anyone actually use them anymore?
If you use a medium high-level language like C, there's no need to flow-chart - you can sketch out in psuedo-code, then simply transcribe to C/C++.
How many of the PICaxe range operate at more than 4MHz (1MHz instruction rate)?
The path I went, was to start up as a web programmer (html, css, javascript, php/mysql) and playing around with the simple "Game Maker Language".
While working with that, I used to take a peak into C++. Making small program such as a RPG item engine (you can buy stuff, sell stuff, and watch what you have in your bag - just text based).
I am working my way into game programming. Find out what your goal is, and work your way from there, with small steps.
Grumpy Mike,
Regards,
-(Non-Grumpy) Mike
@graymalkin:
You are quite right that an AVR won't run at 40MHz, but with its four stage instruction pipeline, a PIC clocked at that frequency is executing simple instructions at half the rate of an AVR clocked at 20MHz, so even a 16MHz Arduino is faster than the PIC.
You have to compare like architectures when considering clock speeds.
I come from an electronic background and didn't really appreciate programming until I had to use the 68HC11 chip for uni. It had 256 Bytes of EEPROM and 512 Bytes of RAM- You could write in C: But if you wanted to do anything useful, you didn't, you used assembly.
Because I was formiliar with logic gates, and how to build "adders" and "comparitors", assembly was a pleasure to use: I understood what was happening on a hardware level (which is what was missing when programming on a computer). As I got more confident in programming, I eventually swayed my way back to programming in C (with the step up to the AVR). If I didn't see what was happening, I wouldn't have liked programming.
Today I write programs on the computer using VB.NET, thanks to a push back into C and an appreciation of what the compiler does. I believe that everyone should know a bit of assembly, but only use it occationally as a "#define" in C/C++ code.
So if you are from an electronic background, it may pay to look at assembly language, but in most cases it just gets in the way.
Shades of
A flow-chart? Does anyone actually use them anymore?
They're used all the time by Six Sigma professionals for process mapping...
If you use a medium high-level language like C, there's no need to flow-chart - you can sketch out in psuedo-code, then simply transcribe to C/C++.
IMHO, I disagree. Many times, with proper flowcharting and thinking about the process you are trying to implement, you invariably find that there are items and steps you miss along the way if you didn't flowchart it.
Especially if the process is a business process that you are trying to automate, or trying to figure out if the automation you are using actually maps to the process being used. In many cases, there are steps or shortcuts being done to the de-facto process that when mapped out, show all sorts of confusion.
In fact, when done right, a flowchart can graphically show you where problems lie; in many cases, if you see in your process map flowchart an over-abundance of crossing lines, or no way to diagram the process to avoid crossing lines, that section is likely "spaghetti-code", or close to it, and needs to be re-thought, and re-mapped.
I honestly believe that if more time were spent up-front designing and mapping processes (whether large business processes or small microcontroller programs), less time would be spent on debugging, and a better quality system would result. Unfortunately, what you invariably run into is the "motivation" to "get it done", without spending that up-front design time. In the end, if your house of cards doesn't collapse on the first iteration, what you end up with looks like something Spanky and the gang would build for a fort, instead of a properly design, process-mapped, and architected system.
Ok - that was a very poor and mixed metaphor, but I hope you understand what I was getting at. I've just seen it in action at every single employer I've worked for (with the exception of one, which was a membership organization for Six Sigma professionals). Typically, inertia and costs are what scuttle the proper methodologies, because the number of rounds you have to do to discover, diagram, plan, rewrite, etc - the actual process (not to mention, you typically find people doing things to keep the wonked process moving that they shouldn't be doing - invariably caused by a previous worker or process outputing the wrong thing to their input, so they have to fudge it - inertia - and toes are stepped on); it looks to certain people like you aren't doing anything, when what you are actually doing is coming up with the blueprints to build (or re-build) a stable structure.
It's maddening sometimes - sometimes (many times) I feel like, as a software developer, I'm an engineer who has been asked to build a building, but to start building it from the 12th floor up, then when I get done, I am asked to put a door in on a wall several feet away from where the actual wall was put in (oh, and that doorway goes right thru the services conduit).
In many cases, most of these issues could be avoided had the entire process been thought about in excruciating plodding detail (even if it takes a few years to do so), before hiring someone to implement it...