Hi everyone,
I am a web developer(LAMP), cms, apart of this, I have worked in C/C++ beginning level, java in medium level. And I have did
some V&V(Validation and Verification in C). I don't know can I be a embedded programmer, I was very bad in electronic subject in University.
Please, consider me as stupid beginner and give me a suitable advise!
Thanks a lot
can I be a embedded programmer
Yes.
I was very bad in electronic subject in University
That won't help, as a programmer you don't have to be great with hardware but it's better if you know what's going on outside the chip and you certainly have to be able to deal with internal hardware at the register level.
Rob
Thanks a lot for your replay,
Can you please tell me which hardware should I buy which could help me to learn Arduino? and how should I start?
Thanks a lot
If you have an embedded system that you can use, why not. In fact if you persevere to expert level, you will write code far more efficiently than most commercial programmers for PC's.
Over the last 10 or more years programming practices have become overly relaxed due to shorter completion deadlines and an over abundance of available resources. By becoming intimate with a very limited system, you are subtly forced to learn more aggressive ways of tacking complex problems, then for example; applying that knowledge to something like 3d systems where number crunching is the main job, you may have a significant advantage over someone with experience only on resource friendly architectures.
The UNO or Mega I would assume is the easiest to start with, I guess the UNO is the most common.
Start by using the arduino tutorials in the getting started section and read numerous C++ tutorials and learning material.
Investigate... Rather than using something blindly, have a crack at re-creating it yourself. If you read something particularly interesting, don't just try and remember it, write a small program that implements it in your own way, until you understand it. No matter how gifted you are C++ is extremely involved ( many systems use other languages ), reading material is of no use without a practical basis.
An experienced programmer should have an archive of many unfinished/cancelled projects, they may be unfinished, but most were learning experiences.
I guess the point I'm trying to stress is, actively learn, write code... lots of code, experience every error the compiler can throw at you, learn to decipher their hidden meanings. Try things you are pretty sure won't work, but you still reserve that tiny hope it will.
Thanks a lot for your descriptive information 
Like a lot of things, it's probably 90% "getting in the door". If you've got a job as a Java/C++ programmer, you might be able to get transfered to an embedded project. Or, if you work for a small company, you might be able to do some system-level programming and some lower-level embedded programming.
Look-up some job openings and see what the requirements are....
In order to get hired straight out of college, you'd need lots of hardware knowledge. I suspect that lots of embedded programmers actually have an EE degree with a strong programming background. (It looks like my old college has embedded courses offered by both the EE and CS departments.)
I was very bad in electronic subject in University.
You need to understand digital electronics. You need to understand how basic logic gates work (and-gates, or-gates, flip-flops, shift registers, etc.) You should know something about how PLDs work.
You should understand what the address & data lines on a memory chip do, as well as the other control lines. If the hardware engineer tells you, "The RAM chip-select never goes low", or "Data line 3 looks like it's shorted to ground", you've got to understand what he's talking about.
If you are working on a new design, you are working on non-debugged hardware and non-debugged software. You can't just say, "That's a hardware probem." You have to write the code to prove it's a hardware problem and you have to write the code to help track-down the hardware problem.
You need to understand the machine/assembly code for the processor you are working on.
You should know how to use an oscilloscope and logic analyzer. A lot of times, you'd be working with a hardware engineer, but you've got to understand what he's doing and what you are seeing on a 'scope or analyzer.
You should be able to understand the datasheet for a microcontroller/microprocessor as well as the various peripheral/support chips. Have you looked at the ATmega datasheet? It's 400 pages! If you are not intimidated by the datasheet, tha't's a good start. You've got to understand what's going-on inside the chips and how the various chips are communicating.
Well put DVDdoug.
you might be able to get transfered to an embedded project.
I was a HW engineer in a small company but did a lot of assembler programming at home. When there was talk about a new project and how to go about it I put my hand up and suggested I could do it on a microprocessor. They took the chance and now I consider myself to be maybe 60% HW 40% SW.
I got the HW job in the first place after working in a mailroom because I had many schematics and designs I'd done at home and I went around the electronic companies I could find in the phone book.
So the moral of the story is be keen about what you want to do, do a lot of it on your own time, then wait for an opportunity or make your own by knocking on doors.
To this end you could buy an Arduino and get started
Rob
Just to reinforce concepts already broached, you will be writing code to control things. Electronic things, electro-mechanical things, mechanical things. I think this means you'll have to have a fair idea of not only electronics but physics as well. Turning on an LED or a little motor on your hobby bench is one thing, but if you want to make a living out of it, you'll have to make stuff work that others have spent a lot of time and money on. For instance, if you need to control a heavy device, like a milling head, with a stepper motor, you'll have to be able to read the specs on the motor to be able to decide on the correct acceleration/deceleration rates. Otherwise the motors will 'cog' and the mill head will end up in the wrong place. You'll be responsible for reading the engineers specifications and turning that into working code.
Professionalism is the key word.
It's different if you buy a hobby kit or two and never go much further,
or if you really follow professionalism approach, and constantly try to improve your circuits/designs.
You can be embedded programmer but that does not neccessarily mean that you can compare with real-world professional embedded programmers.
Great advice, pYro_65, for anyone just getting started. It may not be the only way to learn, but what you describe is about the only way that I learn!
pYro_65:
If you have an embedded system that you can use, why not. In fact if you persevere to expert level, you will write code far more efficiently than most commercial programmers for PC's.Over the last 10 or more years programming practices have become overly relaxed due to shorter completion deadlines and an over abundance of available resources. By becoming intimate with a very limited system, you are subtly forced to learn more aggressive ways of tacking complex problems, then for example; applying that knowledge to something like 3d systems where number crunching is the main job, you may have a significant advantage over someone with experience only on resource friendly architectures.
The UNO or Mega I would assume is the easiest to start with, I guess the UNO is the most common.
Start by using the arduino tutorials in the getting started section and read numerous C++ tutorials and learning material.Investigate... Rather than using something blindly, have a crack at re-creating it yourself. If you read something particularly interesting, don't just try and remember it, write a small program that implements it in your own way, until you understand it. No matter how gifted you are C++ is extremely involved ( many systems use other languages ), reading material is of no use without a practical basis.
An experienced programmer should have an archive of many unfinished/cancelled projects, they may be unfinished, but most were learning experiences.
I guess the point I'm trying to stress is, actively learn, write code... lots of code, experience every error the compiler can throw at you, learn to decipher their hidden meanings. Try things you are pretty sure won't work, but you still reserve that tiny hope it will.