Docker Hardware Emulation

Where’s the Hardware?

In the embedded software development world, I have run into a common issue.  The company is developing a new embedded board.  It is supposed to be delivered in a month.  Hardware will not be available to developers until two weeks before the board gets delivered.

Time

The best case scenario would be to have enough hardware for each developer to have a board.  Unfortunately, business objectives don’t always align for best case scenarios. 🙂

Let’s say you have a team of five developers.  You will only have one board for one week before software needs to be finished.  We need to have a week for testing, right?

What are you as a software developer to do?

Interestingly enough, this solution also makes the development process much quicker.  Introducing…

Docker Hardware Emulation

Here’s a real-world use case.

A team at one of my previous companies had a similar scenario as the above.

Being the very bright team that they are, they anticipated this problem.

The code runs on a Power PC chipset, so it does not just automatically compile for x86.  The first step (and this was a long-term project) was for a team to make the PPC code able to be compiled by x86 (using standard GNU make).

Fortunately, this had already been done before this project started.  Some smart people had done some appropriate planning!

Planning

Being able to compile this code on the x86 platform allowed developers to write and run unit tests on their local developer machines without having hardware.

In addition, running the entire system was desired.  After unit testing passed, the code was plopped into a Docker container.  Docker hardware emulation was used to run this code within a container as if it was running on the actual hardware.

So rather than connecting a debugger to a physical board, a Docker command was run to launch the code.  Testing and debugging was done on this container.

Surprise Benefits

The main benefit to Docker hardware emulation is the ability to develop without hardware.  This allows parallel development of both hardware and software.

More unexpected benefits came from this though.

Connecting a hardware debugger to a board costs a lot of time every time you want to test a change.

Perhaps 1 or 2 minutes to load code from the developer’s machine to the board through a hardware debugger.  Another 2-5 minutes for the board to boot once the code made its way onto the board.

Contrast that to Docker containers.  They boot in seconds!

So consider having to test a code change 20 times.  20 * 5 minutes per time you load the code onto the board = 100 minutes, or 1 hour and 40 minutes.

Let’s say it takes 5 seconds (it’s likely a lot less than this) to start a Docker container with your code in it.  20 * 5 seconds = 100 seconds, or 1 minute and 40 seconds.  That’s a savings of over an hour and a half!!!

Docker hardware emulation just made your development team blazing fast.
Fast Car

Don’t get me wrong: you are still going to need to test on the board once the software is finished.  But you only have to do that 1 or 2 times vs. the 20 times you had to do it before.

I can just tell you as a software developer… being in this spot is AWESOME!  You don’t want to wait all this time, sitting there bored while code is loading.  This makes you lose focus.  You might web browse for 5 minutes (or whatever else suits your fancy while waiting).

Now instead, you can steamroll through this as fast as you can code/test.  It’s amazing!  And it yields much faster software with much higher quality!

The End Result

The final result of all this emulation was on-time delivery.  When the hardware eventually arrived, the software “just worked”.  Yes, there was perhaps a day or two of debugging.  For the most part, the whole application JUST WORKED!

Magic Wand

To those not too familiar with software development, this may not seem like that big of a deal.  It’s just software, right?  I can’t tell you how many times I have heard that phrase.  It’s very demeaning and ignorant of how software development works.

If you are more familiar with software development, this is a huge feat.  It is extremely impressive to be able to emulate hardware and have, for the most part, working software.  This allows parallel hardware and software development.

This allows companies to be much faster.  You can now do more things in parallel.

Conclusion

This is a great feel-good story.  There are some points that you might notice.

  1. Being able to do this took a great deal of planning and foresight by some very bright people.
  2. This took a lot of time devoted to infrastructure.  It did not pay off from a pure profit perspective.  This means people had to be given time to do this.  They couldn’t be 100% busy on business objectives 100% of the time.
  3. The dividends paid off 2, 3, 4, or 5-fold in terms of delivery speed and quality.  Very little time was spent debugging, and the software “just worked”.

Do you want a similar success story for your business?

You need to invest in infrastructure.  Smart people need to plan wisely.  They need to have time to come up with this type of infrastructure.  These investments will end up making lots of money over time, just as though you were to invest in good stock.

Money

Great companies realize the benefits of this.  They are able to develop much quicker and bring products to market much faster.  This means if they are competing directly against you… you are going to get obliterated in terms of quality and time to market.

Make smart investments in your infrastructure!  The dividends will pay out time and time again.

Leave a Reply

Your email address will not be published.