I mean, if binary code is already generated by PC, wouldn't it be possible to just take this binary code, transfer it to a specific place in flash memory via specific bus, for example Serial Wire, and it would work?

Why is a programmer usually required in an embedded toolchain?

  • 8
    \$\begingroup\$ What exactly is "Serial Wire"? RS-232? UART? USB? JTAG? Something proprietary? \$\endgroup\$
    – Lundin
    Jan 3, 2022 at 9:29
  • 3
    \$\begingroup\$ @Lundin Serial Wire Debug (SWD) is a two-wire debug and programming standard supported by most ARM microcontrollers. developer.arm.com/architectures/system-architectures/… \$\endgroup\$
    – user4574
    Jan 4, 2022 at 0:26
  • 1
    \$\begingroup\$ @user4574 Ah yeah I always say SWD without considering what it stands for :) Anyway, it's basically "JTAG light". \$\endgroup\$
    – Lundin
    Jan 4, 2022 at 7:19
  • 1
    \$\begingroup\$ And how would you call the specific device that "transfers [the binary code] to a specific place in flash memory via specific bus, for example Serial Wire"? I know... Let's just call it a programmer, right? \$\endgroup\$
    – dim
    Jan 6, 2022 at 12:43

6 Answers 6


That's what the programmer does.

It takes the binary output from the compiler and stores it in the MCU's Flash EPROM, usually over a serial bus.

Flash EPROM requires a programming algorithm to store data in it, with any erases first. The programmer carries out this algorithm. It's not like writing data to RAM. This is very well documented and explained on the Internet.

  • 5
    \$\begingroup\$ 34 seconds ahead of me. Same answer, different words. No surprise :-) . \$\endgroup\$
    – Russell McMahon
    Jan 3, 2022 at 9:27
  • 2
    \$\begingroup\$ By the way, is there any other way of programming in embedded than by programmer or off-board programming(in older MCUs) ? \$\endgroup\$
    – yeuop
    Jan 3, 2022 at 9:39
  • 7
    \$\begingroup\$ @yeuop yes, but these are literally questions that looking at a microcontroller product page would have answered in seconds. \$\endgroup\$ Jan 3, 2022 at 9:47
  • 7
    \$\begingroup\$ There are plenty of microcontroller boards that effectively have a programmer built-in so you can program the device via the board's USB port. \$\endgroup\$ Jan 3, 2022 at 18:42
  • 2
    \$\begingroup\$ Even if there was no need for explicit erasing, you'd probably still want to be able to both read and write, to define the address of memory you're going to write and maybe have some checksumming on the transfer. Those things need to be transmitted to the device in some defined way too, and there you have a protocol that needs to be implemented on the writing end. (On top of something like SPI or UART serial or whatever. If you dropped those, you could of course just make a loader that just shifted bytes from SPI to flash, starting at address 0 on reset and going from there, bar timing issues) \$\endgroup\$
    – ilkkachu
    Jan 3, 2022 at 19:27

A programmer is the implementation of " via specific bus,". Some devices have inbuilt bootloaders (may be hardware or software or firmware) that allow the use of a port of some sort to load code.

Whenever a feature is included in a device that is not utilised during normal operation it adds an unproductive overhead. On very large and capable systems this overhead may be small and unimportant. On very small systems it may occupy enough program space or hardware to represent a significant degradation of device capability. When processors get into the cents per unit range every last piece of capability is worth having. (A 2 cent processor that becomes a 3 cent processor due to added little used capabilities may matter. )

  • 6
    \$\begingroup\$ Yep. If you sell 10 million sensors, you need 10 million MCUs, but only one programmer. Why would you force your customers to pay for 10 million programmers when you are the only one who needs it? \$\endgroup\$ Jan 5, 2022 at 8:26

transfer it to specific place in flash memory via specific bus

This is exactly what flash programmer devices do. They just don't use something slow and archaic like RS232, but instead nowadays usually JTAG/SWD. Often translated to/from USB.

A high speed bus like JTAG is required to enable two things:

  • Somewhat accurate real-time debugging, including things like "cycle stealing", instruction trace and other such tricks that debuggers might be using.
  • To avoid long programming times.

For example in the dark ages where one built everything from scratch, I recall things like RS-232 bootloader with 9600bps and handshaking, then EPROM programming times on top of that. It could take as long as 20 minutes just to program a single MCU.

Before the early 2000s, pretty much every MCU family had its own special snowflake programming interface, which was far from standardized. These were horrible, horrible things. Then came various proprietary single-wire debugger interfaces and eventually JTAG/SWD which became industry standard with the advent of PowerPC and ARM.

You can of course still use bootloaders over USB, CAN, UART etc and many MCUs have built-in hardware support for it even. But these are meant to be used for specialized use-cases and not for production batch programming.

  • 7
    \$\begingroup\$ UART bootloaders are still a thing - very useful if you have to program a whole bunch of 'em, and as you say, that's why we kept them. For "development purposes", standardized debugging interfaces high five. \$\endgroup\$ Jan 3, 2022 at 9:46
  • 1
    \$\begingroup\$ That’s one of the first times I have heard JTAG described as a high-speed bus :-) although perhaps it is compared to micro controllers. \$\endgroup\$
    – Krazy Glew
    Jan 4, 2022 at 1:56
  • 1
    \$\begingroup\$ @KrazyGlew It's basically as high speed as you dare, without short cables etc. And it's high speed compared to the various [rubbish] interfaces we had to endure 15-20 years back. [Edited by a moderator.] \$\endgroup\$
    – Lundin
    Jan 4, 2022 at 7:21
  • \$\begingroup\$ You know JTAG's almost half a century old now, right? \$\endgroup\$ Jan 5, 2022 at 1:16
  • \$\begingroup\$ @ChristopherJamesHuff And RS-232 is from the 1960... I don't think JTAG became successful until PowerPC started using it (?) somewhere late 1990s. Overall we've only had sane programming interfaces present in microcontrollers since somewhere around 2000-2005 and a lot of the older [rubbish] interfaces lived on beyond that. The ARM hype from ~2005 and beyond eventually killed them, good riddance. [Edited by a moderator.] \$\endgroup\$
    – Lundin
    Jan 5, 2022 at 7:31

The ability to self-program has a number of costs, and generally these costs can be avoided by leaving that ability out:

  1. The self-programming MCU can brick itself. Oops...
  2. Security: may add a path for a hacker to be able to modify the device's firmware remotely.
  3. You have to have an external programming interface to get the initial program in, anyway (though this is built-in for some MCUs).
  4. Having to write the software to support self-programming.
  5. Communications interface to receive the new program, memory to buffer the new program, battery backup so power won't drop out in the middle of rewriting its flash, any special voltages, write circuitry, again, software to support all this... See @Russell McMahon's answer.
  6. Speed of programming: using an external programmer may greatly speed up the programming process, especially if the only usually available communications interface is slow.

The other answers were generally good, but didn't necessarilly spell everything out clearly IMHO.

  1. To load a compiled program into a microcontroller, the PC that holds the compiled program needs to be connected directly to the microcontroller in some way that provides a method of bidirectional communication. That's one of the jobs of a programing device: to provide that communication path.

  2. Some microcontrollers - but not all - require high voltages to program. By high voltage, I mean higher than Vcc. Providing that voltage is another important function of the programing device.

Every microcontroller that I have experience with allows the possibility of programming it with a so-called bootloader. On power up (or reset) the bootloader looks on one or more specific communication channels for someone trying to replace the existing firmware with new. If it finds that to be the case, and everything checks out security wise, then the bootloader accepts the new firmware and puts it in the place of the old program. This is very often done with commercial products that allow firmware updates by the user. Note that this requires the bootloader to already have been loaded into flash memory by 'conventional' methods. So we still haven't solved the problem of programming a fresh chip.

In any case, the bootloader takes up some space in flash memory which may or may not be precious.

Having said all of that, some microcontrollers can be programmed without special voltages. The AVR series is a good example. These still need some sort of hardware to connect the software on your computer to the digital pins on your microcontroller (and software on the PC to make it work, obviously.) You can get everything off the Internet to turn an unloved Arduino into a programmer for AVR chips. This takes care of requirement (1) above, and since AVR chips don't have requirement (2), Bob's your uncle.

As a point of interest, I once built an instrument that was controlled by a Raspberry Pi. It turned out the RPI couldn't provide certain signals that I needed with adequate timing requirements. I looked for an existing IC that could do what I needed, but couldn't find anything. So, I used an ATtiny85. I wrote some simple software to make it into my dream chip, and programed it directly through the RPI digital GPIO. No programmer required. It turned out to be both easy and fun. But, circuit design and microcontroller programming are always fun for me


Not all microcontrollers need to be programmed via protocols and connections designated for a debug probe or programmer device.

As an example, the STM32F446RE microcontroller has two boot pins that control if the microcontroller executes the program stored in its (main) flash memory, if it boots from its SRAM, or it it boots the program from its so-called "system memory". This program overwrites the main Flash content with a new main payload program transmitted via UART, CAN, or SPI (where the ports and pins to be used in each case are fixed and can be looked up in the documentation). In this way, the microcontroller can be programmed with a standard USB-to-UART device, via the CAN bus, and so on.

But during development, you often want to use a debug probe anyway, and using that to also program the microcontroller is often more convenient. For firmware updates in the field, the possibility to program from the system memory program can however be useful. It is not possible to overwrite the system memory program as far as I know, so the MCU cannot be bricked in this way.


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.