6 deleted 21 characters in body
source | link

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

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.

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

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.

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

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.

    Post Made Community Wiki by Jason S
5 added 32 characters in body
source | link

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems.
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect.
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

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.

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems.
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect.
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

For books, I'd recommend digging through history. Most of today's embedded software techniques come from the bleeding edge of yesteryear.

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

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.

4 added 102 characters in body; added 141 characters in body
source | link

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems.
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect.
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

For books, I'd recommend digging through history. Most of today's embedded software techniques come from the bleeding edge of yesteryear.

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems.
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect.
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability

Some random tips:

  • Remember, "There is no silver bullet", don't fall into the trap of believing that there is one tool, methodology, language or system that can solve all problems.
  • Become an expert in C
    • Learn to get by without malloc() and POSIX
  • Don't get hung up on one architecture, it's easy to become a PIC or AVR or ARM fanboy by accident
  • Build stuff, debug it, make it work. Practice makes perfect.
  • Learn at least one source control system (SVN/git/etc) and use it
  • Always be prepared to test your assumptions. The bug is usually in the thing you are assuming works
  • Don't become too reliant on debuggers, they're different on every system and of varying reliability
  • Think frugally. When problem solving, think about code footprint, RAM footprint and hardware cost

For books, I'd recommend digging through history. Most of today's embedded software techniques come from the bleeding edge of yesteryear.

3 added 111 characters in body
source | link
2 added 229 characters in body
source | link
1
source | link