You retarget the C library's low-level output function to a hardware transport. The standard library's printf formats its string and ultimately calls a low-level write primitive, in newlib that's _write (or you implement putchar/_putchar), which by default does nothing useful on bare metal. You override it to send the bytes somewhere: most commonly out a UART to a serial terminal, or over SWO/ITM (the Cortex-M single-wire trace output) to the debug probe, or into a RAM ring buffer that a tool like SEGGER RTT reads over JTAG/SWD, or via semihosting which routes the output through the debugger to the host console. Once you implement _write to push bytes to, say, your UART driver, every printf in the program flows there. The choice of transport is a real engineering decision because they differ enormously in speed and intrusiveness: UART is universal but slow and ties up a peripheral, SWO is fast but needs the trace pin and probe support, RTT is very fast with minimal intrusion and no extra pin, and semihosting is trivial to enable but halts the core on every call. So "printf on embedded" is really "retarget _write to a transport you've chosen for the right speed/intrusiveness tradeoff."
Debugging & Toolchain · Interview question
On an MCU with no console, how does printf produce output?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
printf Debugging & Logging
Where does printf go on a chip with no console, and what does it cost? Retargeting output to UART/SWO/RTT (vs slow halting semihosting), intrusiveness, and leveled, deferred, compile-gated logging.