Consider that the hardware team will take 2 months to develop some hardware, but by that time I will need to have the software ready.

My question is that how can I write the software and test it without having the hardware?

Is there any standard/s to be followed? How do you do it?

  • \$\begingroup\$ Depending on how complex the hardware gets, you could try a simulator. That's quite doable if it's only a micro-controller with simple peripherals. More than that and you're out of luck on that route. \$\endgroup\$
    – Mast
    Feb 7, 2016 at 15:31
  • 6
    \$\begingroup\$ Try to find development boards for the micro and any other peripheral devices you're using, and try to connect them all up in a way which most closely resembles your hardware team's design. It will be big & ugly, but you should be able to put together a system which is close enough to the real thing - at least as far as your firmware can tell ... \$\endgroup\$
    – brhans
    Feb 7, 2016 at 17:52
  • \$\begingroup\$ At worst, if you can't properly simulate the hardware, have a way of disabling it. Just a couple weeks ago I wanted to test network communication with another program, only to find that it would exit() because it tried to mmap hardcoded addresses in /dev/mem. \$\endgroup\$
    – isanae
    Feb 7, 2016 at 18:49
  • 1
    \$\begingroup\$ It's actually preferable, in many cases, to use a simulator for embedded software development -- much easier to debug. The problem, of course, is that you need a decent simulator. Sometimes there's a generic one that can be adapted, sometimes a clever intern can write one in a caffeine-fueled coding frenzy. \$\endgroup\$
    – Hot Licks
    Feb 7, 2016 at 23:39

6 Answers 6


Not having hardware during the initial stages of firmware development happens. Common strategies to deal with this are:

  1. Spend time up front architecting the system carefully before you write any code. Of course you should do this anyway, but in this case it's even more important than usual. It's much easier to debug well thought out software than a pasta-based mess.

  2. Properly modularize everything, minimizing the interfaces between modules. This will help contain bugs to individual modules, and allow easier testing of individual modules.

  3. Write code bottom-up, hardware-touching drivers go first, high level application logic last. This allows discovering inconveniences imposed by the architecture early on. Don't be afraid to change the architecture as hardware realities come to light, but make sure all the documentation is updated accordingly.

  4. Simulate. Most microcontrollers companies provide software simulators of their microcontrollers. These can only go so far, but can still be very useful. Simulating the inputs and measuring the outputs of the hardware may be difficult, but checking higher level logic this way shouldn't be too hard.

    This is where the modular design helps again. If you can't reasonably simulate some low level hardware interactions, you use a different version of the module that touches that hardware but that passes its own simulated actions to the upper levels. The upper levels won't know this is happening. You won't be checking the low level module this way, but most everything else.

In short, use good software desing practices, which of course you should be doing anyway.

  • \$\begingroup\$ Would like to add: get dev boards (yes, multiple, because you will probably kill at least one...) in ASAP and get the low level drivers in place. Unit test as much of your code as you can. Yes, you can unit the hardware-touching code. No, you can't completely simulate the hardware, but you can get 90% of the functionality correct even before flashing for the first time. I did all of the above on a recent project, and we had 99% functionality in place and working when the real hardware came in. It was magnificent. \$\endgroup\$
    – CHendrix
    Sep 20, 2016 at 15:27

Without any insight into what it is you're developing, or which family of microcontrollers your hardware will eventually be based on, most families of microcontrollers have low cost development systems available that have a suite of common peripherals on them, which may allow you to simulate at least some of your eventual target hardware.

  • 1
    \$\begingroup\$ Agreed. I would word it more strongly. In a situation like this where the software has to be finished at the same time as the hardware, I would only use a microcontroller that had a suitable development or evaluation board. \$\endgroup\$
    – Steve G
    Feb 7, 2016 at 15:36
  • \$\begingroup\$ Even if you did have insight into what the OP is developing, most microcontroller families still have simulators available. \$\endgroup\$ Feb 7, 2016 at 16:06
  • \$\begingroup\$ I use both methods. However I additionally keep an eye on the production line test equipment required. You can get together with the production engineers and design hardware to test your drivers which can then form part of production testing. If your lucky they may even build hardware for a development board / prototype so they get ahead of the process too. It's all down to how you pitch the request for help... \$\endgroup\$
    – Spoon
    Feb 7, 2016 at 17:43
  • \$\begingroup\$ This is the best answer to this question, as I always have a dev board to program the core functionalities first before trying it on the pcb. \$\endgroup\$
    – lucas92
    Feb 7, 2016 at 22:46

Depending on how hardware dependent the application is going to be, you could just start implementing the project on a standard pc (Windows, Linux...). Most peripheral access should be abstracted anyways, so it's not a big deal to implemented some dummy functions, that are going to be replaced later. If it's not possible to simulate some behaviour, you could at least do a mockup of the system (API...), so the actual implementation is going to go a lot faster and clearer, as soon as the hardware is ready.

There are of course many things that can't be simulated, like real time behaviour or complex hardware drivers. On the other hand, a interrupt driven ADC can easily be simulated using a thread that reads values from a file or a network port.

Of course all this highly depends on various factors:

  • Can you use the same/similar toolchain on controller and pc (e.g. gcc)?
  • How hardware dependent is the system?
  • How experienced are you with pc programming?

I, for one am designing pretty much every firmware module on a pc first.

  • \$\begingroup\$ Same here. Some differences between compilers (intrinsics, special keywords, closed source OS and network stack not quite compatible with BSD) and bugs (with C++) forcing heavy use of file specific pre-included files and preprocessor, but code itself can be almost identical between DSP and PC. For PC version I can use strong and heavy runtime error checking (CodeGuard) and its debugging capabilities cannot be matched on embedded platforms. Additional bonus is that I can have few extra virtual devices for any network and load testing. \$\endgroup\$
    – TMSZ
    Feb 8, 2016 at 11:53
  • \$\begingroup\$ With availability of Raspberry Pi and BeagleBone, your development environment could just as easily be your runtime environment -- no issues with toolchain, etc. Plus, you can use valgrind/helgrind, gdb, etc. \$\endgroup\$
    – jhfrontz
    Feb 8, 2016 at 17:19

Try to get a simulator for your chip. You should simulate all expected inputs and some unexpected ones also. Modularize/abstract as far as you can and write unit tests. If you can, those tests can become part of your actual code and they turn into a feature (board self-test).

If you can't get a simulator, abstract as much as you can through a HAL (hardware abstraction layer). All drivers get behind it. Try to abstract all platform-specific assembly behind some C function call and think of those as drivers too. Write the rest as portable C/C++ code and make a thin HAL for x86 and run it on your machine with all test cases.

That way, when you get the hardware you'll only have to debug the HAL. The thinner it is, the faster you'll debug it and have everything working. Remember that if you use platform-specific assembly for faster ops, you DO WANT VERY MUCH to get bit-exact tests.

  • \$\begingroup\$ Bit-exactness is specially important if using fixed-point DSP. \$\endgroup\$ Feb 7, 2016 at 22:55
  • \$\begingroup\$ It may or may not apply to a particular case, but in general bit exactness has its price. QEMU recently (2 years ago) decided to implement bit-exact FPU, and it guess what happened to performance? \$\endgroup\$ Feb 9, 2016 at 8:04
  • \$\begingroup\$ Bit exactness isn't that much important when using an FPU. It is extremely important if using fixed-point, though. Specially because software fixed-point need extra checks everywhere. \$\endgroup\$ Feb 11, 2016 at 22:00
  • \$\begingroup\$ Which is a result of poor coding practices. People have learned to take precautions when using a == b comparisons with floats, but they still mindlessly use them with fixed point numbers. \$\endgroup\$ Feb 12, 2016 at 7:24
  • \$\begingroup\$ While poor coding practices are quite a problem, there are many other problems, specially at edge cases. Overflows come to mind quickly, as does precision loss, rounding, saturation and width vs bit-shifting. With all that, it's easy to ignore some precision loss in common test cases. The problem is when your app reaches lesser cases and the errors move from the fractional to the integer bits, which happens if the range is miscalculated. Just check MATLAB's Fixed-Point Designer's features page to see what else could go wrong in a glimpse. \$\endgroup\$ Feb 13, 2016 at 2:57

Your question is a bit broad. Hardware (HW) could mean full custom ASIC / FPGA development, assembler-programmed DSPs, or "only" a typical embedded system based on off-the-shelf microprocessors/microcontrollers/SoC etc. (of course a SoC might also contain a DSP that you might want to program....). For high sale quantities, making it an ASIC is not uncommon.

But for a 2 month project I expect it to be based on some microcontroller:

In any case, you should stress the hardware team to give you a prototype you can start testing your code before the absolute deadline - this just might consist of a generic development board, as some people have mentioned already, but in my opinion it is their job to provide the right one to you, and potentially also some required/similar peripherals for testing.

Simulators are also possible to some extent, but you still might need to characterize some real world sensors / data you might get. Here the hardware team also needs to at least assist you.

Other than that, the software design can be done already and all high level modules can get (and should be) implemented and unit-tested without the real hardware. Ideally, you will also define an API together with the hardware team, and they will provide you with the lowest level functions, so any change they do on the hardware side there (e.g. simply redefining which port pins they use), will be not always be critical to you.

In all cases, communication is key.


Yes, You can Develop your code for your target board before board they get maufactured.

How ?

First you have to know the main objective of that system. So from this you can choose the controller appropriately from vast availablity source like digikey,mouser.

And Choose simulator like Proteus. This will simulate the exact processor/controller now you can start your coding. But you cant expect the accuracy as in hardware.

  • \$\begingroup\$ Why downvote ? May i know the what is the wrong with this answer ? \$\endgroup\$
    – Photon001
    Feb 9, 2016 at 1:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.