I'd like some tips for those who want to become a good embedded software developer or want to improve in this area.
What should I need learn about hardware, software?
Which books are most recommended? Blogs?
In the end, how could I go from a beginner hobbyist to an excellent professional?
All the answers have been good so far, but I'll throw in my two cents.
Here's a repeat of some tips with a twist and some extra:
Here are some books:
Here are some websites:
For books, I'd recommend digging through history. Most of today's embedded software techniques come from the bleeding edge of yesteryear.
Like anything, practice daily.
The other answers are great, but the biggest difference between a hobbyist and a professional should be a mindset about quality. So have your project go all the way, don't stop when you are 80% done with a project. Take it all the way, prove that it is working, and document it correctly.
Make sure your code is readable and maintainable.
And don't forget to have some fun as well :)
Apart from the obvious, like learning C and start with some developer board, you'll want to learn to read microcontroller datasheets.
Manufacturers add more and more features to microcontrollers, which therefore become more and more complex. The datasheet doesn't only provide electrical characteristics (which is more interesting for the electronical engineer than the software developer), but also detailed description of registers, memory maps, etc.
On first reading a datasheet may look daunting, but failing to understand them can cause a more severe headache in the debugging phase.
'Embedded' is a bit of a loaded term..
In some respects, any system dedicated to running a single application could be called an embedded system, as long as there is some hardware to be controlled. You can arguably call a 400MHz PPC604 with 2GB of RAM running a java application on top of linux an embedded system, if it happens to be controlling a process through local I/O modules. On the other hand, an arduino just running some kind of minimal network application wouldn't be much of an embedded system. But probably 'embedded' makes most people think of flash based controllers with only a few hundred bytes of RAM, no operating system to speak of, and a plethora of on-chip peripherals.
That being said, probably the two biggest hurdles non-embedded programmers usually face learning embedded systems are I/O registers and interrupts.
Interrupts may actually be the easier of the two concepts for non-embedded programmers to deal with, since the main issues with these, concurrency and event driven programming, are often encountered in mainstream applications. What makes interrupts a pain is realizing the extreme sensitivity of a system to the quality of its interrupt handling, and the intricacies of dealing with hardware to clear the interrupt condition and set up for the next one. With a GUI, a deadlock kills just the application. With an interrupt handler, a deadlock causes your entire system to lock.
I/O devices seem to be the area that cause the most difficulty. For the uninitiated, it can be quite a surprise to discover that reading this register here has an effect on that register there. Writing 1's to clear bits. Status bits that clear themselves when you read a data register, etc. There are so many possibilities with I/O hardware that there is no general rule for dealing with it, except to learn how to find and interpret device data sheets. Writing a device driver for a serial port will teach you much about low level I/O programming.
There's really no substitute for learning these things than to roll up one's sleeves, and program some straight C and/or assembly language on the bare metal. Even the aforementioned java based embedded system eventually needs a device driver for the I/O, and this means ultimately dealing with some C. Experience is the best teacher. Pick a microcontroller, be it MSP430, TMS320, AVR, ARM, PIC, 68HC11, whatever, find an eval kit, and build some systems.
Sparkfun has a number of good sub $\$$50 development boards. Also go to TI for the Stellaris family in the $\$$50 to $\$$100, also the Hawkboard which for now I would recommend before the Beagleboard for what you may want/need to learn, also TI has the MSP430 family and I would get an EZ430 and a three pack of the add-in boards for $\$$10. At Sparkfun get a Lillypad with the FTDI USB serial/power board, the Lillypad is pretty much the same as the Arduino pro mini but you need to solder for the pro mini. I am not a fan of the PIC family but you may want to get something there as a history lesson, same goes for the 8051, both families are still popular and in use, just not very efficient and have been passed over by other architectures. Absolutely learn ARM and thumb, maybe MIPS (which is a pic-32, not to be confused with the older original PIC architecture). The ARMmite Pro is a good entry level ARM board, although the Stellaris may be as well.
What you want to learn here is assembler for various platforms. C. C and assembler interaction. Different tools GCC and non-GCC. How to read a datasheet/programmers reference (and realize they all have some errors or can be misleading, never trust them, the hardware wins over documents) and how to read or use a schematic. These are not complicated schematics normally. A number of the boards are good for interfacing in projects meaning they dont have garbage on the board in the way, just direct access to the I/O pins. But that is not the best for learning. Something like a Stellaris board which is painful for projects has lots of fun stuff on board for learning embedded and learning to borrow/use drivers or write your own from datasheets. The Atmel AVR butterfly is a good board too if still available, may need to solder on your own serial port to program it or just jam some wires in the holes. What it gives you is a few peripherals you can learn to program.
Even if you end up doing embedded work that involves writing applications using SDK or API calls on linux or an RTOS (never touching hardware or reading datasheets), the above knowledge will still set you ahead of the rest.
This article (auto-translated from Portuguese to English) has a good overview of developing a career as a developer of embedded software. Note: The original is here.
It begins by outlining the spheres of knowledge you must develop:
Knowledge: You must know the theory involved in embedded systems. This means hardware and software. It is impossible to be a competent developer of embedded software without getting to know the hardware architecture which is working.
Skill: You need to get experience in the area. Needs practice. You can decorate all the PIC assembler mnemonics, but it is no use if you can not drive a LED with this knowledge.
Attitude: Above all, you need to attitudes that will make you grow in this area. It is a very dynamic with frequent changes and developments. You need to always be motivated (a) be self-taught, enjoy learning, "tweak" and understand how things work. Without such attitudes will give you soon. Because this area you need to be very, very persistent.
It then gives the following tips for mastering these areas (and develops them with further text, these are just the headings):
- What you need to learn hardware (at least)
- What you need to learn the software (at least)
- In addition, study operating systems
- You need a training
- Do not stop, keep learning and developing your networking!
Think twice before you become an embedded software engineer. I have had phases in my career. I have developed software the first 5 years, than move to sales/marketing, done that for 15 years, managed a 100+M$ business and now I am back to software.
When I come back to software after 15 years, I remember why I left in the first place. It is hard. It needs concentration, several hundreds of lines of code touching each other and you all need to keep it in the memory. Embedded is particularly hard.
You also need to understand yourself. If you are generally a smart guy, meticulous and patient you would make a great engineer. If you are missing any one of those you will be average at best. Think about that. If you are ultra smart and not patient, doesn't worth much because no matter how smart you are, good engineering takes patience and attention to detail.
You also need to be comfortable looking at code hours at a time without talking. I observe that people with good social skills find this unbearable.
If all this checks out, than read all those great books, do the exercises and you will make a great engineer.. Good luck
Everyone else says great things. So I'll give you general advice: read read read read read read read read!
Read every article on http://embeddedgurus.com If you don't understand something, research it. If in the explanation of those things you find something you don't understand, read some more. I'm about to head into an embedded software position and my experience is a handful of professional projects over the past few years and a lot a LOT of reading. Experience lets you try things, but reading lets you know whether the things you've tried have been done before, maybe better than you could. It introduces you to concepts that you can work with in any circumstance.
Just read!
Become an expert in C Understand Timers and Serial communications. You should get your hands dirty with it. Understand RF protocols, tweak them to your requirements. Don't just blindly try out combinations of code while debugging. Code does exactly what you tell it to do. Read the user manual and data sheet and then make a change if something doesn't work. All that said and done, the only real way to become an expert is to practice. Keep building applications. Soon, it will become second nature.