RAYPCB · ENGINEERING GUIDE
Custom Arduino PCB: Move from a Working Prototype to a Defined Product
A custom Arduino PCB can preserve the useful software and development workflow of a prototype while replacing temporary wiring and unnecessary hardware with a controlled product design. The migration needs more than copying header labels. Power, pin assignments, libraries, programming and physical interfaces must still agree after the prototype becomes a different board.
This page addresses that migration task. The pin worksheet flags repeated declared physical identifiers and unknown startup states, helping organize the review before layout. It does not translate an Arduino sketch into a schematic or validate a chosen MCU. For the anatomy of the published UNO R3, use the separate Arduino UNO reference guide.
Freeze what the prototype actually demonstrates
Record the board model and revision, attached modules, wiring, supply, firmware and configuration used for the working prototype. Describe the functions that have been exercised and the conditions that have not. A successful bench demonstration is useful evidence, but it is not a complete product requirement.
List the behaviors the final design must retain: sensor timing, output states, communication, user inputs and recovery. Identify which parts of the development board support them indirectly. A USB bridge, regulator, reset circuit or bootloader may be doing essential work even when it is absent from the application block diagram.
Keep optional features separate from requirements. Removing a status LED or unused header can be reasonable, but removing a programming or observation path can make later diagnosis much harder. Choose what remains based on the product and test workflow, not only on reducing the component count.
Reconcile software names with physical resources
Map each application signal from its software identifier to the actual MCU peripheral and physical package pin. Include timers, interrupts, analog channels, communication ports and debug or programming use. Two libraries can compete for a resource even when their external connectors look unrelated.
The worksheet accepts a declared physical pin, its function and startup state. The example intentionally repeats GPIO_A and includes an unknown state. Those are teaching identifiers, not a valid Arduino or AVR pinout. Resolve the real resource allocation using the selected device and software configuration.
Keep shield-header labels, Arduino numbering and package-pin numbers distinguishable. If the product moves to another MCU or board core, reassess library assumptions, voltage behavior and peripheral availability. Source code compiling successfully does not establish that the resulting physical pin assignment is correct.
| Review item | What to establish |
|---|---|
| Prototype baseline | Board, wiring, supplies, software and demonstrated functions. |
| Resource map | Software names reconciled to real peripheral and package pins. |
| Hardware boundary | Module, discrete MCU or external board responsibilities. |
| Product behavior | Power, output defaults, physical connections and recovery. |
| Release evidence | Custom-board tests, approved files and assembly scope. |
Pin allocation and startup conflict review
Pin allocation and startup conflict review
Use the current inputs and keep the assumptions
Load the example to learn the worksheet, then clear it before entering your project values. Blank fields are not silently converted to zero. Units and selected conventions belong to the result, so review them together with the numbers. Editing any input invalidates the previous result and disables its download until you calculate again. Edited example data remain labeled as an illustrative example.
This tool runs locally on the values you enter. It does not open a schematic, select approved components, measure signals or inspect a physical board. Keep the exact component documents and a record of measurements with the design. Downloading the text report does not send an enquiry or populate the Contact form. Attach it manually if it helps explain a specific engineering question; completing the worksheet is optional.
| Input | What to establish before using it |
|---|---|
| Review reference | Use a nonconfidential revision reference. |
| Declared pin map · CSV | One physical identifier per intended assignment. Example names are fictitious, not a valid device pinout. |
Choose the hardware architecture deliberately
Decide whether the custom board carries a complete module, the selected MCU and support circuit, or an interface to an external development board. Each boundary assigns different responsibilities for power, clock, programming and mechanical support. Record which portions are retained and which are newly designed.
For an ATmega328P implementation, the device layout guide concentrates on the exact package and supporting power, clock, reset and programming circuit. It is a narrower task than converting an entire prototype. Other Arduino-compatible targets need their own documentation and cannot inherit that circuit automatically.
Review signal-level compatibility with every retained peripheral. A library working on the prototype does not make a sensor electrically compatible with a different voltage domain. Include partial-power and external-connection conditions, particularly when the final product has more than one possible supply.
Replace temporary power assumptions with a power design
Trace the prototype's real power path, including USB, external supplies and module regulators. Identify the source and limits for the final board and account for simultaneous load states. A bench supply set to a convenient voltage is not a specification for the product's input interface.
Specify startup and disabled behavior for outputs connected to real loads. Motors, relays, heaters and other actuators require an appropriate drive circuit and defined inactive state. Do not treat a microcontroller pin as a general-purpose load supply. The PCB controller state guide develops this behavior separately.
Review regulator dissipation and transient requirements using the actual circuit. Removing a development-board regulator can change noise or startup behavior elsewhere. Keep the power tree and component choices connected to the measurements the product needs, rather than assuming the software will compensate for an unstable rail.
Design the physical interface for repeated use
Replace loose wiring with connectors, mounting and protection appropriate to the intended environment. Define orientation, retention, access and the assembly sequence. A prototype connector selected for convenience may not suit the enclosure or expected service action.
If a card-edge interface is chosen, use the edge connector fit worksheet with the actual mating part. If a conventional connector is used, review its complete mated connection and permitted loading. Mechanical fit and electrical behavior remain separate requirements.
Preserve readable identification for assembly and service. Mark the actual intended connector and switch functions where useful, but keep drawings and the controlled pin map as the authority. Silkscreen cannot carry every condition, and an ambiguous label should not be relied upon to prevent incorrect wiring.
Keep programming and test in the board design
Choose how blank devices are programmed and how a failed update is recovered. Identify the required contacts, power source and image identity. A bootloader-based workflow and a direct programming interface may have different prerequisites; document the actual chosen method.
Define functional tests around the product's tasks, not only a blinking LED. Use known sensor inputs or simulated signals, observe output behavior and exercise relevant communication. Preserve the fixture connections and expected responses with the release so repeated builds can use the same scope.
Keep the prototype result separate from the custom-board result. The new board may use the same firmware while changing physical behavior. Record the exact hardware and software combination that produced each observation, including unresolved differences from the original prototype.
Turn the migration into a clear enquiry
Provide the current schematic, fabrication outputs, BOM, placement data, quantity and programming or test requirements for a RAYPCB review. If only the prototype exists, identify the design work still open rather than describing it as a released manufacturing package.
State whether modules and programmed devices are supplied or sourced as part of the assembly scope. Flag approved alternatives and parts whose substitutions would affect firmware or performance. Those details help procurement compare a consistent deliverable.
The worksheet report can accompany a focused question about the pin or startup assumptions. It does not upload files, approve the circuit or place an order. A controlled migration record gives the manufacturing discussion a more useful starting point than an unsupported claim that the prototype is already production-ready.
Retain the boundary between a reference and your implementation
Record the exact reference hardware and document revision used for each part of the design. Identify what is retained, what is removed and what is changed. A compatible software environment or matching connector arrangement does not establish that electrical, mechanical and startup behavior are unchanged.
Give each intentional difference an appropriate review or test. Keep the evidence attached to the actual board, fitted parts, firmware and operating setup. This is particularly useful when a development prototype becomes a custom carrier or product board: the earlier demonstration remains valid for its original setup, while the new implementation needs its own observations. A manufacturing enquiry should include the released derivative files and its agreed scope, not ask the receiving team to reconstruct the intended changes from a reference link and informal notes.
Standards, source context and limits
The referenced manufacturer documentation supports specific devices, interfaces or design methods. Apply the version and operating conditions appropriate to the actual part. A similar product name is not evidence that pin functions, voltage tolerance, startup behavior or package dimensions match. Worked examples illustrate reasoning and arithmetic; they are not released schematics or independent hardware test results.
For fabrication scope and the agreed construction requirements, see PCB manufacturing.