





















The ATmega328P is the chip on the Arduino Uno. The same chip goes into a product on a custom board built around it. Taking the design into production means a custom board that carries the bare ATmega328P with only the parts the product needs around it. The firmware carries over unchanged. The work is all in the board, the programming, and the cost at volume.

The Arduino Uno is a bench tool. It carries a USB port, a programming chip, a voltage regulator, a row of headers, and an LED, all to make the microcontroller easy to load and to wire. A prototype uses every one of those. The board turns an idea into running code in an afternoon. The work that follows is to keep the running code and shed the parts a product does not need. The USB-to-serial chip lets a laptop talk to the board and reset it to load code. The regulator takes a seven-to-twelve-volt input and makes the five volts the chip runs on. The headers break every pin out for a jumper wire. The auto-reset capacitor lets an upload start on its own. Each of these serves the prototype. A product reviews each one and drops the ones it does not use. The product keeps the ATmega328P at the center and asks of every other part whether the design still needs it.
A product wants a board with only what it uses. A custom board carries the ATmega328P, its decoupling, its power, and the circuit for the job, and nothing more. The USB, the regulator a battery product does without, the headers, and the second chip all come off. The board shrinks to the size the product allows. The cost drops to the parts that are left. A product board can be a fraction of the Uno’s size, a small rectangle that fits the enclosure. It can run from a coin cell, a battery, or the mains supply the product already has. It drops the USB chip, the regulator, the headers, and the row of sockets the bench used. The bill of materials falls to the chip and the few parts the application needs.
The chip on the custom board is the same ATmega328P. The same flash, the same RAM, the same EEPROM, and the same peripherals run the same firmware. A sketch built in the Arduino tools runs on the bare chip with no change to the logic. The move is a board move. The code rides along, and a team keeps its tested firmware while it rebuilds the hardware under it. The ATmega328P holds thirty-two kilobytes of flash, two kilobytes of RAM, and a kilobyte of EEPROM, the same on the Uno and on the custom board. The timers, the ADC, the serial port, and the SPI and I2C blocks are the same registers the sketch already drives. A move that keeps the part keeps the whole programming model. The team debugs on the bench and ships the same binary.
The board gave the prototype a few things the product replaces. The Uno powered the chip from USB, so the product adds its own supply. The bootloader and the USB link loaded the code, so the product adds a programming header or a set of pads. The on-board crystal set the clock, so the product chooses its own clock source. Each convenience the board provided turns into a small decision on the custom board. The supply decision picks a regulator, a battery, or a direct rail. The programming decision picks an ISP header, a set of test pads, or a kept bootloader. The clock decision picks the internal oscillator or a crystal. None of these is hard once the product’s needs are clear. The custom board is the chip plus the one answer the product needs to each question.
The whole move is mechanical once it is planned. A schematic captures the minimal circuit. A layout places the chip, the decoupling, and the connectors. A programming step at the factory replaces the bootloader load. A cost sheet replaces the price of a whole dev board with the price of a chip. The prototype proves the idea. The production board carries it to volume. A first custom board is itself a prototype, built to prove the minimal circuit before the run. The team loads the firmware over ISP, checks the board against the bench unit, and fixes any layout issue. A second spin, when it is needed, comes cheap and early. The board that passes that check is the board the factory builds by the thousand.
A bare ATmega328P needs little to run. It needs power and ground on its pins, with a decoupling capacitor close to each supply pin. It needs a pull-up resistor on the reset pin to hold it high. It needs a clock, from an internal source or an external crystal. With those few parts in place, the chip runs its firmware from power-on. The decoupling is a hundred-nanofarad capacitor at each of the chip’s power pins, with a larger bulk capacitor on the rail. The reset pull-up is a ten-kilohm resistor from the reset pin to the supply. The AVCC pin that feeds the ADC ties to the supply, often through a small filter. These few passives are the whole support circuit a basic design needs. Each bypass capacitor sits as close to its power pin as the layout allows, with a short trace to ground. A board that skips the decoupling risks a glitch in the field on a noisy supply. The few cents of passives buy a clean reset and a steady rail. The reset pull-up keeps the chip out of reset through normal noise, so the board starts once and stays running.
Everything the Uno added for the bench comes off the product board. The USB chip and its connector go, since the product programs another way. The on-board regulator goes when the product runs from its own supply. The headers and the power LED go. What is left is the chip, a handful of passives, and the connector the product needs. The auto-reset capacitor the bootloader relied on comes off with the bootloader. The crystal comes off when the design runs the internal oscillator. The board keeps the reset pull-up, the decoupling, the power, and the I/O the product uses. A board stripped to those parts is small, cheap, and quick to place. A two-layer board holds the whole circuit, with the chip on top and the passives around it. A design with no USB and no regulator routes in a small area. The bare-board cost stays low. The simpler board also goes together faster on the line.
| Item | Arduino Uno board | Production board |
|---|---|---|
| MCU | ATmega328P on the board | The same ATmega328P, bare |
| Programming | USB bootloader | ISP header or test pads |
| Power | USB or barrel, with a regulator | The product’s own supply |
| Clock | 16 MHz crystal | Internal 8 MHz or a crystal |
| Extras | Headers, LED, USB chip | Only what the product uses |
| Unit cost | A whole board | The chip plus a few passives |
The clock is the first fuse-level choice. The Arduino runs a 16 MHz crystal, set by the board and the fuses. A product that does not need the speed can run the internal 8 MHz RC oscillator, which drops the crystal and its two capacitors from the board. The internal oscillator holds a few percent of tolerance, enough for ordinary timing. If the timing has to be exact, for a precise UART or a tight timebase, the crystal stays. If it does not, the internal oscillator saves the crystal, its capacitors, and two pins for other use. The factory calibrates the internal oscillator, and the chip trims it at startup to sit near eight megahertz. The CKDIV8 fuse can divide it down for a low-power run. A sixteen-megahertz design needs the external crystal, since the internal oscillator does not reach that speed. The clock choice sets a fuse, a part count, and the timing budget the firmware works to. A sketch built for a 16 megahertz crystal runs at half the rate on the 8 megahertz internal clock. The firmware rebuilds for the new speed. The delays and the baud rate then hold. The Arduino tools carry board definitions for the internal-clock setup. The clock fuse and the build match the part the board runs. A mismatch shows up as a garbled serial port or a long delay. The clock setting is the cause.

The Arduino loads code through a bootloader over USB. A production board can keep the bootloader for a serial update path, or it can drop it and program the chip directly. Dropping the bootloader frees the flash it used and removes the boot delay at every reset. A product that never updates in the field programs once at the factory and runs straight from reset. The Arduino bootloader takes about half a kilobyte of flash. At every reset it spends a short delay listening for an upload. If the field will ever need a new firmware load, the bootloader stays for a serial update path. If it will not, dropping the bootloader returns that flash and starts the chip the instant power is good. The decision is set once, before the run. If the product is simple and fixed, dropping the bootloader is the clean path. If it ships into a connected system, a load path stays, either the bootloader or a small custom routine. The flash freed by dropping it becomes room for the application.
Direct programming uses the in-system programming port, the same six signals an ISP programmer drives: power, ground, reset, and the three SPI lines. A production board brings those signals to a small header or to test pads at the edge. A programmer on the line writes the flash, the EEPROM, and the fuses in one pass. Arduino documents the standalone setup, the bare chip on a board, on its breadboard ATmega page. The three SPI lines are MISO, MOSI, and SCK, shared with the I/O the firmware uses. A low-cost programmer such as a USBasp, or a vendor tool such as the Atmel-ICE, drives the port. An Arduino board itself can program a first bare chip. The header takes a few cents of board space and serves every unit on the line. The same port reads the chip back for verification, so the line confirms each part holds the firmware it was given.
The fuses set the chip’s hardware options. They pick the clock source, the brown-out level, the watchdog, and whether the reset pin stays a reset. A wrong fuse can lock the chip out of further programming, so the factory writes a verified fuse set and checks it. The fuses go in once with the firmware and stay untouched after that. A fuse calculator turns the chosen options into the bytes the programmer writes, and it guards against a setting that bricks the part. Two fuses deserve care: the one that disables the reset pin and the one that enables debugWIRE, since either can cut off ISP access. A lock bit can protect the firmware from a read-out once the part is programmed. The verified fuse set goes into the production script with the firmware image. A brown-out fuse set near the supply voltage holds the chip in reset through a sag. The hold protects a write in progress. The watchdog setting and the reset behavior round out the set. A documented fuse map travels with the design, so a later build writes the same bytes.
Volume programming runs on the line. A gang programmer writes many chips at once before they reach the board, or an in-circuit step programs each board as it passes. A serial number or a calibration value goes in at the same step. A test then confirms the board runs before it ships. The programming a bootloader did by hand becomes one station in the line. An in-circuit fixture drops onto the test pads, programs the chip, and runs a functional check in one pass. The line logs the serial number and the result against each board. A board that fails the check never ships. The click that loaded one prototype becomes an automated step that repeats on every unit. A failed unit drops out at the test station with its serial number logged, so the line tracks its yield. The record ties each shipped board to the firmware and the fuses it carries. A field return then traces back to its build.
The cost drops from a whole board to a chip and a few parts. A bare ATmega328P costs a few dollars in single quantities and far less in volume. A production board pays for that chip, a handful of passives, and its own bare PCB. At volume the unit cost lands far below the price of a finished dev board. The saving per unit is the point of leaving the Uno behind. A production board pays for the bare chip, a few passives, and a piece of bare PCB, all a small fraction of a finished board’s cost. A product shipping in the thousands counts that saving on every unit. The board around it carries the cost down to the parts the product uses. A reel of bare chips and a panel of small boards turn the bench prototype into a line item measured in cents.
Production moves to a different package. Production uses a surface-mount ATmega328P, the TQFP or the QFN that a pick-and-place line places. The same silicon runs in every package, with the same firmware and the same fuses. A design picks the surface-mount package its assembly line runs and lays the board out for it. The DIP-28 part suits a socket and a hand-built prototype. Production uses the TQFP-32 or the QFN-32 for a reflow line, and those packages bring out two ADC channels beyond the DIP. A design moving to surface mount checks the pinout, since the TQFP numbering differs from the DIP. The footprint and the fuses are set once for the production package. The TQFP-32 and the QFN-32 bring out 32 pins, four more than the DIP-28, with two extra ADC inputs and a separate analog supply pin. A design that needs every channel reads the pinout for the chosen package against its schematic. The package is fixed before the layout starts.
Supply matters once a product ships in volume. The ATmega328P is a mainstream Microchip part, stocked wide and made for years. A design checks the stock and the lifecycle of the exact package and grade before it commits. A pin-compatible alternative noted early guards the line against a shortage. The chip that carried the prototype carries the product, once the board around it is built for volume. The part comes in industrial and automotive grades for a wider temperature range, named in the part number. A buyer subscribes to the change notices and confirms a long-term supply for a product with a long life. The datasheet and the lifecycle page tell a design what it is committing to. A part this mainstream rarely surprises a design that watches it. Microchip lists the active part numbers, the packages, and the lifecycle status on its product pages. A design records the exact ordering code it qualified, down to the package, the speed grade, and the temperature range. The order book then matches the board the factory builds. A second approved source, qualified on the same footprint, keeps the line moving if the first one runs short.
The ATmega328P runs on its own with a few parts around it. It needs power, a decoupling capacitor, a reset pull-up, and a clock source. A custom board carries the bare chip and the circuit for the product, with none of the Arduino extras. The firmware from the Arduino prototype runs on the bare chip unchanged.
It needs power and ground with a decoupling capacitor at each supply pin. It needs a pull-up resistor to hold the reset pin high. It needs a clock, either the internal RC oscillator or an external crystal with two capacitors. With those parts in place, the chip runs its firmware from power-on.
The internal 8 MHz RC oscillator runs the chip with no crystal and holds a few percent of tolerance, enough for ordinary timing. If the timing has to be exact, for a UART or a tight timebase, the crystal stays. A fuse picks the clock source. Dropping the crystal saves the part, its two capacitors, and two pins.
A production board brings the six ISP signals to a header or to test pads. A programmer on the line writes the flash, the EEPROM, and the fuses in one pass, and it can write a serial number at the same step. A gang programmer can load chips before assembly. A test confirms the board before it ships.
Keeping the bootloader leaves a serial path to update the firmware in the field. Dropping it frees the flash the bootloader used and removes the boot delay at every reset. A product that programs once at the factory and never updates runs straight from reset with no bootloader. The choice follows whether the product needs a field update.
The bare ATmega328P is the same silicon as the chip on the Uno, so the compiled sketch runs on it unchanged. The one thing to watch is the clock: a sketch built for a 16 MHz crystal runs at a different speed on the internal 8 MHz oscillator. Setting the clock fuse and the build to match keeps the timing right.
{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Can I use the ATmega328P without an Arduino board?","acceptedAnswer":{"@type":"Answer","text":"The ATmega328P runs on its own with a few parts around it. It needs power, a decoupling capacitor, a reset pull-up, and a clock source. A custom board carries the bare chip and the circuit for the product, with none of the Arduino extras. The firmware from the Arduino prototype runs on the bare chip unchanged."}},{"@type":"Question","name":"What does a bare ATmega328P need to run?","acceptedAnswer":{"@type":"Answer","text":"It needs power and ground with a decoupling capacitor at each supply pin. It needs a pull-up resistor to hold the reset pin high. It needs a clock, either the internal RC oscillator or an external crystal with two capacitors. With those parts in place, the chip runs its firmware from power-on."}},{"@type":"Question","name":"Do I need the crystal or can I use the internal oscillator?","acceptedAnswer":{"@type":"Answer","text":"The internal 8 MHz RC oscillator runs the chip with no crystal and holds a few percent of tolerance, enough for ordinary timing. If the timing has to be exact, for a UART or a tight timebase, the crystal stays. A fuse picks the clock source. Dropping the crystal saves the part, its two capacitors, and two pins."}},{"@type":"Question","name":"How do I program the ATmega328P in production?","acceptedAnswer":{"@type":"Answer","text":"A production board brings the six ISP signals to a header or to test pads. A programmer on the line writes the flash, the EEPROM, and the fuses in one pass, and it can write a serial number at the same step. A gang programmer can load chips before assembly. A test confirms the board before it ships."}},{"@type":"Question","name":"Should I keep the Arduino bootloader in production?","acceptedAnswer":{"@type":"Answer","text":"Keeping the bootloader leaves a serial path to update the firmware in the field. Dropping it frees the flash the bootloader used and removes the boot delay at every reset. A product that programs once at the factory and never updates runs straight from reset with no bootloader. The choice follows whether the product needs a field update."}},{"@type":"Question","name":"Does my Arduino sketch run on the bare chip?","acceptedAnswer":{"@type":"Answer","text":"The bare ATmega328P is the same silicon as the chip on the Uno, so the compiled sketch runs on it unchanged. The one thing to watch is the clock: a sketch built for a 16 MHz crystal runs at a different speed on the internal 8 MHz oscillator. Setting the clock fuse and the build to match keeps the timing right."}}]}