How to become an embedded software developer?

Today I see a question in Stack Overflow :”How do I get started in embedded programming?“. There are many industries starved of embedded software developers such as Apple, Cisco, also include my current company ZTE. The students graduated from CS or EE major fall into the dilemma that the CS students know nothing about the embedded systems and their most proficient language is JAVA which involved little in embedded systems. On the other hand, The EE students have a amount of knowledge about embedded systems but their programming skill is poor.

If you enjoy embedded programming and want to be the member of this industry, congratulations! You are the people who can make a great living doing work they enjoy and you can across the area which the pure software engineer and electronics engineer want to enter. You know the system information from the bottom to the top and you can handle everything of your system.

Here are Steven’s Four Pieces of Advice for newcomer of embedded programming:

  1. Become an expert in C
  2. Familiar with embedded systems software architectures
  3. Learn to read microcontroller datasheets
  4. Practice makes perfect

Become an expert in C

First of all, you should read The C Programming Language and write the function samples in your own way and compare your implementation with the book. This will improve your programming ability a lot. If you flip over the pages of the book to fragment, you will become an expert in C. Are you kidding? Yes I do. Despite you can be familiar with C language by means of reading through this book for many times, it is just the basic skill of embedded software developer.

Familiar with embedded systems software architectures

RTOS, scheduling, interrupt, timer, memory management, these stuff are the fundamental stores of programmer. For instance, we know that deadlock caused by the condition that two or more processes form a circular chain where each process is waiting on another resource in the chain. If the resource can use by more than two processes, the deadlock cannot take place. When we dig into, we must exclude preemption, which means one process cannot forcibly remove another process’ resource. If these three conditions listed above met concurrently, it is not the sufficient condition for the deadlock. Why? If the processes holding a resource cannot request new ones, the desire to deadlock vanish.

Learn to read microcontroller datasheets

Intel® 64 and IA-32 Architectures Software Developer’s Manual is the best material for learning the knowledge of CPU and microcontroller. You can learn byte order, memory organization, registers and instructions, interrupts and exceptions and so on. All the things you can learn from the datasheet are very useful for the embedded programming since IA-32 architecture is popular in embedded system with the widespread of ATCA. And certainly, if you read datasheets of MIPS or ARM, It is the same.

Practice makes perfect

Start with basic interrupt driven/background loop processing, then move up to background schedulers, then real-time operating systems. It’s practice. Challenge yourself to re-write your code more efficiently in terms of speed and memory usage. It’s pratice. Don’t use someone else code, just re-invent the wheel when you’re learning. Keep  pratice! Maybe one day you find youself become the real embedded software developer!

Posted in embedded programming, Uncategorized | Leave a comment

Rewriting or refactoring?

My first article in my own Blog, which was followed Jeff Atwood’s advice: How to Write Without Writing.

Today I asked a question in Stack Exchange. In stack exchange, there have some point of views. Someone think we should rewrite it and someone think refactoring is the best choice because rewriting is the last resort.

This question came from a real situation in our project. The module began with a graceful and concise aspect just as the beginning of the fairytale:” Once upon a time, there was a beautiful princess…”. An experienced programmer wrote the original code which was readable, robust and neat. It worked well in systems and gained reputation for the programmer.

With more and more features added to the systems, the code base got worse over time. But it was the same aspect as former code in the surface and one day the programmer was promoted to team leader. A junior programmer just graduated from university took over the module and coded with great care. Unfortunately, he or she didn’t know all the fundamental decisions and ideas behind the architecture. The team leader was busy in his or her new management affairs and ignored the transition of knowledge. When features flooded into the systems, the new comer complained to the team lead and asked for help. Then a new member of the team was added to maintain the module who was still not familiar with the module. More people – less communication. Less communication – bad decisions. Two years later, the module became the hidden bomb in the systems.

How to deal with the problem? The question was raised by project manager eventually and there have just two choices: rewrite or refactoring.

Michael Dubakov suggested that,

Though refactoring and rewrite might lead to cleaner code however, both the techniques bring chaos to the existing system. Refactoring is an incremental activity hence it touches some portion of the system at a time. This creates chaos at local levels and might be easy to contain. Rewrite on the other hand is a more invasive change and results in a bigger chaos in the system. Due to the wider impact, the stabilization period of a rewrite is much longer than that of refactoring.

As Joel on Software suggested,

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time.

Return to the living example, experts mentioned the risks and chaos brought by the rewrite and refactor, so it is difficult for the team members to make up their mind to start. Netscape, Friendster, Myspace…, the long list of the companies which made the worst mistake had the same point: they rewrite the code of their mainstream products.

According to general common sense, this horrible news may hold up the pace of the team members. But with repeated discussions and meetings, the final decision is rewriting the module with some special policy.

The module has some characteristics which were different from Netscape, Friendster and Myspace. The module has twenty thousand code lines, and the prediction of the code line after rewriting is the same. The scale of this module is far more less than the gaint products, so rewriting the whole module is easier to under control. Another approach is dividing the team to two parts, one team maintain the old code, and the other team rewrite the module. When the rewriting complete and is verified to reach the release standard, the new module will replace the old one. Before this, these two modules run in parallel.

Posted in software engineer | 1 Comment