Electronic – How to start embedded Programming?

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:

• Learn C: The fundamental language of the hardware that is still portable (too some degree). Don't just learn it, but become an expert of all it's features like volatile and why it is important for writing device drivers.
• Start out with a good development kit like Arduino, but as said before learn other architectures once you got a good feel for it. Luckily there are some Arduino compatible boards built with other processors, that way you can rewrite the same design on a different uC not mess up your whole design while getting a feel for something new.
• In the learning stage, feel free to re-invent the wheel on device drivers or other pieces of code. Don't just plop someone else's driver code down in there. There's value in re-inventing the wheel when you're learning.
• Challenge yourself to re-write your code more efficiently in terms of speed and memory usage.
• Becoming familiar with different styles of embedded systems software architectures. Start with basic interrupt driven/background loop processing, then move up to background schedulers, then real-time operating systems.
• Get good source control! I prefer Mercurial myself.
• Even sign up for some free source control hosting sites like Sourceforge.net or Bitbucket.org to host your project even if you're the only one working on it. They'll back your code up, so you don't have to worry about that occasional hard drive crash destroying everything! Using a distributed VCS comes in handy, because you can check in changes to your hard drive then upload to the host site when ready.
• Learn your tools well for whatever chip you're working on! Knowing how the compiler creates assembly is essential. You need to get a feel for how efficient the code is, because you may need to rewrite in assembly. Knowing how to use the linker file and interpreting the memory map output is also essential! How else are you going to know if that routine you just wrote is the culprit of taking up too much ROM/Flash!
• Learn new techniques and experiment with them in your designs!
• Assume nothing when debugging. Verify it!
• Learn how to program defensively to catch errors and verify assumptions (like using assert)
• Build a debugging information into your code where you can such as outputting memory consumption or profiling code with timers or using spare pins on the uC to toggle and measure interrupt latency on a O-scope.

Here are some books:

• The Pragmatic Programmer by Andrew Hunt and David Thomas - more or less required reading for any practical software development
• Practical Arduino
• Programming Embedded Systems by Michael Barr
• Embedded Systems Building Blocks by Jean Labrosse
• MicroC OS II Real Time Kernel by Jean Labrosse, great intro into RTOS's in general in there along with his OS.
• Embedded Software Primer by David Simon - good intro to embedded software

Here are some websites:

• Embedded Gurus
• Ganssle Group Jack Ganssle has some wonderful historical stories to tell. Read the articles. He gets a little preachy about some things though.
• Embedded.com Good info for latest techniques and tips from Ganssle, Barr, and other industry experts.

If you're concerned that code for a simple switch() based state machine (SM) will become untidy, you can split it into smaller subroutines.

void do_state_s1() {
    // stuff
    if ( /* certain  contidition */ ) {
        g_iState = STATE_S2;  // transition to another state
    }
}

void do_state_s2()  {
    // other stuff
    if ( /* some other condition */ ) {
        g_iState = STATE_S1;
    }
}

void do_state_machine() {
    switch (g_iState) {
    case STATE_S1:
        do_state_s1();
        break;

    case STATE_S2:
        do_state_s2();
        break;
    };
}

void main() {
    g_iState = STATE_S1;        // initialize the SM

    while (1) {
        do_state_machine();
    }
}