bit-banging
/ BIT-bang-ing /
Suppose you need to send a message in Morse code with a flashlight, but you have no automatic flasher — so you manually switch the light on and off, holding each blink for the right duration by counting in your head. Bit-banging is the software equivalent: generating a communication protocol by manually toggling ordinary output pins in code, bit by bit, with your program controlling the exact timing, instead of letting a dedicated hardware peripheral do it.
Most MCUs have hardware peripherals for common serial protocols — a UART for serial, an SPI controller, an I2C controller. These peripherals do the work in silicon: you hand them a byte and they clock the bits out on the pins at the right speed and shape, while your CPU does other things. Bit-banging is what you do when you DON'T use such a peripheral: you take plain general-purpose I/O pins and write code that drives them through the protocol by hand. To bit-bang SPI, for example, your code manually sets the data pin to each bit's value, then pulses the clock pin high and low, for all eight bits, timing the pulses with short delays. The CPU is busy doing this the entire time. People bit-bang for a few honest reasons: the chip lacks a hardware peripheral for the protocol you need; all the hardware peripherals are already in use; the pins you must use are not wired to a peripheral; or you need an unusual or non-standard protocol that no peripheral implements.
It matters as a fallback that gives you total flexibility — you can speak almost any protocol on almost any pins — and as a teaching tool that makes a protocol's bits visible. The honest trade-offs are significant: bit-banging ties up the CPU (it cannot do much else while banging bits, whereas a hardware peripheral runs in the background), it is usually slower and the timing is less precise (an interrupt arriving mid-bang can stretch a pulse and corrupt the signal, so people often disable interrupts during a critical bang, which hurts real-time latency), and it burns more power. The rule of thumb is honest and simple: use the hardware peripheral when one exists and fits; bit-bang only when you must. Reaching for bit-banging by default, when a perfectly good peripheral is sitting idle, is a common beginner inefficiency.
// Bit-bang one SPI byte by hand on plain GPIO pins (mode 0): for (int i = 7; i >= 0; i--) { write_pin(MOSI, (byte >> i) & 1u); // present this bit write_pin(SCLK, 1); short_delay(); // clock high (slave samples) write_pin(SCLK, 0); short_delay(); // clock low } // The CPU is fully occupied here; a hardware SPI block would do // the same in the background while the CPU runs other code.
Driving each bit and clock edge in software. A hardware peripheral would clock the same byte out in the background, freeing the CPU.
Bit-banging ties up the CPU, is slower, and is timing-fragile (an interrupt mid-bang can corrupt the signal). Use a hardware peripheral when one exists and fits; bit-bang only when you genuinely must.