Can I develop an embedded system; starting with prototyping by using an arduino board. Then extract the hex code that I verified on the arduino board and load it on to a microcontroller. (Of course the target controller must be the same as the one on the board).

It comes to me as a sensible approach, may be this is the way that everyone follows. I want to learn if it is plausible or nonsense? Any cons and pros.


  • \$\begingroup\$ The main problem is that all Arduino libs are adapted to that specific hardware, meaning that your own board would not only have to use the same MCU but probably also the same hardware. Professional developers use more conventional evaluation boards which are pretty bare hardware-wise, the cad their custom PCB and run the code from there ASAP. \$\endgroup\$
    – Lundin
    Feb 27 '19 at 7:30
  • \$\begingroup\$ You not only can, it tells you right on the Arduino site how to do so. However, in the long run you may not want to use the Arduino software stack in a product, for a wide variety of reasons on the fact/opinion divide. \$\endgroup\$ Feb 28 '19 at 21:03
  • \$\begingroup\$ @Lundin - there isn't much accessory hardware on basic Arduino boards, apart from the power regulator and clocking in fact it has less than the majority of "professional" evaluation boards, which are typically loaded up with extras the vendor wants to sell. Obviously a custom board would need to support whatever the application needs, but it does not have to match the original circuit - and one is free to try the internal oscillator on a board which supplies an external crystal if targeting such usage. Further, these variations are already supported in the Arduino build options. \$\endgroup\$ Feb 28 '19 at 21:08

Generally this would be possible, but not the best way. But first things first. The so called microcontroller is already on the the so called Arduino Board. Arduino is nothing more than a marketing trademark for microcontrollers. For example the Arduino nano is essentially a PCB with an Atmega328 with a little peripherial - the same microcontroller you would later put on your custom PCB in an embedded system.

For the migration from the prototyping stage to some production embedded system some things have to be considered.

  • If you want to flash the already compiled hex file to your custom board, its important to choose exact the same microcontroller as the prototyping Arduino platform for production. This means that not the general name (for example Atmega328) but the full name of the controller has to be chosen. For example the Atmega328 has more than 50 variations which differ in packaging, pin numbers and peripherial. Flashing the same hex on a slightly different controller can result in different register numbers in the controller and could lead to unforseen behaviour of the controller, which leads to the next point.

  • Don't use your Arduino hex in production. The Arduino IDE and libaries are great for prototyping and getting a fast proof-of-concept but are bad for production level. Arduino is so easy and fast to develop because a lot of things are handled in the libaries which are build on each other. The deeper concepts of register and hardware handling are buried under the so called hardware abstraction layer(HAL). The HAL often generates a lot of overhead because its designed to be as universal and easy as possible. This means on the other hand not specifially suited for your particular application. Its more memory and runtime efficient to rewrite the code in plain C and do all the low level stuff on your own and application tailored. And of course you can compile your program for the controller you choose and not vice versa.

  • 6
    \$\begingroup\$ Hello Dennis, I am by no means a fan of Arduino, but do you have any tangible, quantitative proof for your second bullet point? Intuitively, I think that 99% of application would not be impacted by the usage of Arduino library, and on top of that I would not trust the average Joe to write better code than what is in the library. \$\endgroup\$ Feb 27 '19 at 8:03
  • \$\begingroup\$ @VladimirCravero Most common example: digitalRead() and digitalWrite() are pretty slow, because they have to resolve pin numbers to ports and bit numbers. They can usually be replaced by much faster direct port access. \$\endgroup\$
    – user39382
    Feb 27 '19 at 8:20
  • 1
    \$\begingroup\$ @duskwuff "pretty slow" is not quantitative at all. I understand that using a library adds overhead and makes things slower, but the statement "Don't use Arduino hex in production" is quite bold and final, and I think it needs to be backed by more than anecdotal "proof". What is acceptable in production depends on the application, I am sure that the Arduino library is not used in a jet aircraft controller (or is it...?), but a home thermostat? Why not? \$\endgroup\$ Feb 27 '19 at 8:29
  • \$\begingroup\$ This starts out well, but your claims about package variations reflection the compiled software are just about entirely incorrect. Inside they are really all the same die, it is only which signals are bonded out to pads which differ. Sometime like the ATmega328 vs 328p vs 328b do have some functional difference, but not always ones which would prevent software from running; similarly, code for a 168 may work fine on a 328 unless it does things specific to flash size. \$\endgroup\$ Feb 28 '19 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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