My Unconventional Way to Become an Embedded Software Engineer

It is quite a story that how I became an embedded software engineer.

Back in 2007, I got my Ph.D in control engineering, and accepted an offer from a silicon valley startup company as a digital control engineer. Unfortunately, I was fired before I joined the company because the company was acquired while I was waiting for my Optional Practical Training (OPT). It is in silicon valley, and I quickly found a job as a Firmware engineer.

Since then, I have been working as an embedded software engineer. Have I ever been regretted to be a embedded software engineer ? Never ever! There has never been a more exciting time to be a part of the embedded software community and become an embedded software developer.

Looking back at my journey, these are some of the biggest lessons I took away from making the career move.

What Does an Embedded Software Developer Do?

Before answering the questions of what the embedded software developer do, let’s look at what is an embedded system. Embedded systems is an advanced technology with the combination of software and hardware. If you looking at the modern world, you could have surely found it everywhere from consumer electronics, medical devices, commercial applications, and even military applications. In general, It is a dedicated computer-based system with the following components:

• Hardware: It includes micro-controller, processor, memories, I/O devices, ports, etc.
• Application software: To perform multiple tasks at the same time.
• Real Time Operating System (RTOS): It supervises the application software, schedules and manages the tasks, resources, and time response to events timely.

Embedded software developers are responsible for designing, developing, implementing the software that is programmed into devices built around a microprocessor or system on chip (SOC).

They write code to solve problems and implement systems that make a physical hardware device work through software. They take the concept right through to delivery: from the briefing, writing, testing and fixing stages to final release.

A good embedded software engineer can develop hardware and all the source code that runs in the system, from board support package (BSP) to the user interface, can undertake hardware/software co-design and co-verification. A full stack embedded software engineer is such a person that has full knowledge of hardware, software, firmware, PCB designs etc..

What Makes a Good Embedded Software Developer?

Developing software is hard. Developing embedded software is even harder. Why? As a special branch of software, some time we also called the embedded software as a Firmware or middleware. Firmware, as an “invisible software” , is the programming that governs the low-level operation of hardware devices

As an embedded software engineer, you need a broader knowledge about the job you ware working on. Below is a list of a few of them:

• Basic electronics
• Board bring up
• Hardware schematics reading
• Microprocessor and microcontroller fundamentals
• C/C++ programming
• Algorithms
• Memory
• Communication protocols
• Design patterns
• Real Time Operating Systems (RTOS)
• Build environments
• Concurrent/parallel programming

Embedded development is a vocation. You need a genuine passion and interest for technology and troubleshooting technical problems. In my opinion, the best embedded software developers need to bring a whole system perspective.

They need to understand the low level concepts of how the software talks to the underlying hardware. And they need to know the hardware they are working on, including the different peripherals connected to the system.

A large part of embedded software development is problem solving. Embedded developers have to be able to identify and solve problems, while incurring minimal drain on time and cost.

In addition to technical skills, to undertake commercial development work, there are a number of ‘softer’ skills you will need to hone. Project management for example is crucial. Client deadlines and budgets are often non-negotiable. In terms of delivering the project, embedded developers can work individually, or as part of a team. Either way, you are likely to come across some element of collaboration as you take on projects, either with fellow developers or engineers from other disciplines. Another skill is collaboration. Working with clients means taking and understanding the brief, devising and proposing solutions, and keeping them informed as the project progresses.

You also need to keep on top of emerging trends and technological developments. This means an ongoing commitment to learning and understanding best practice, to ensure your knowledge is up to date and relevant.

Why I Enjoy Embedded Software Development

The biggest joy of being an embedded software engineer is when I can say “I made that work”.

Since 2007, I have worked on projects in a number of sectors from industrial automation, renewable energy, distributed power flow control, through to m2m wireless mesh communications. The variety of end users and project type is a key draw and keeps me challenged and motivated to deliver exceptional final products.

Some of my most memorable projects have included working with various companies who wanted to move large and complex code bases to new processor or operating systems, or both. These projects required a good understanding of software construction, real-time operating systems, and processor architecture and board design. In other words, they provided the toughest and most interesting technical challenges.

Embedded software development demands patience and attention to detail. For embedded software developers, submitting a software patch is usually difficult or not an option at all. There are no re-releases once it leaves your charge. You have to get it right.

This translates into long and thorough release and testing cycles because often there are no second chances. Patience and focus therefore are essential virtues. But the satisfaction at the end of the project is immense. Having something tangible, operable and functional directly resulting from your own creativity and hard work is a rewarding experience.

Rumors of Firmware’s Death Are Exaggerated

There is one article called The Soo-to-Be-Extinct Embedded Software Engineer. The title seems a little bit scary, but the author had made some good points about the trend of the embedded system industry. The traditional embedded software developer could be extinctic because more and more microcontroller manufacturers are currently in a big push to provide developers with high-level software frameworks and tools that abstract out the low-level hardware. This makes it easier for embedded software developers or even application developers to write their application software at a higher level. They do not have to reinvent the wheel by worrying about the low-level hardware and software.

However with the era of the Internet of Things (IoT) , we will deploy billions of devices over the next 10 to 20 years. All of these devices have firmware: Wi-Fi routers, digital cameras, point-of-sale credit card terminals, and pretty much anything that communicates with your computer via USB, to name a few. By definition, these devices will want to communicate to accomplish the tasks for which they were designed, whether wirelessly or over a physical medium (copper wires or fiber optics).

Some sets of devices will need to work together, which means they will need to communicate with each other and with whatever central device is in charge of them all. This requires new protocols and algorithms to make sure they all can communicate without talking over each other or losing messages in transit—all while being mindful of energy constraints. In addition, many wireless IoT devices will operate on batteries or solar cells; some will even need to harvest energy from environmental sources. These devices need to be super energy efficient, and thus not only will the firmware that runs them need to make sure the device components operate only when needed, but the firmware itself needs to be ultra-efficient in order to conserve energy.

Last but not the least, increasingly commercial-grade real-time operating systems (RTOSs) are being deployed to IoT devices for their determinism, flexibility, portability, scalability. These systems integrated with RTOS truly require not only the feature set of a commercial offering, but also the expertise of the people that support it in order to be able to deploy the features as an articles talked about when IoT meets RTOS.

For these reasons, among others, I believe there are many opportunities for innovation in the firmware space.

Stay tuned!