勛圖tv 繚 ENGINEERING GUIDE
PCB Controller Design: Define Inputs, Outputs and Startup Behavior
A PCB controller connects product inputs to actions through a defined sequence of states. Choosing an MCU is only part of the task. The controller must interpret sensors and commands, drive suitable interfaces, handle unavailable resources and enter an appropriate state during startup, reset or a fault.
This guide focuses on application behavior and hardware boundaries. The pin worksheet highlights repeated physical assignments and unresolved startup states; it does not inspect firmware or certify a control function. For early processor-resource selection, use the separate microcontroller architecture guide.
Describe actions before drawing the processor block
List the inputs the product uses and the outputs it controls. Define valid ranges, timing and the response to missing or contradictory information. A controller requirement should explain what the product does, not merely count how many connectors or GPIO pins it has.
Classify outputs by their physical interface. A logic command, relay drive, motor interface and communication message require different circuitry and evidence. Do not connect an actuator directly to an MCU pin because a demonstration program can toggle that pin. Specify the driver and protection appropriate to the actual load.
Identify functions whose failure has particular consequences and allocate the necessary product-level requirements. A public pin checker is not a functional-safety assessment. Where a regulated or safety-related application is involved, use its applicable engineering and validation process rather than a generic controller checklist.
Write the startup and unavailable-resource states
Define behavior before firmware starts: supply absent, supply rising, reset asserted and reset released. Then define initialization, normal operation and recovery. Record which device or passive network controls each important output while the processor is not yet driving it.
Include the state of attached devices. A powered peripheral can drive an unpowered controller, while a controller can issue a command before the receiving device is ready. Keep supply domains and initialization handshakes visible in the design rather than treating all components as simultaneously available.
For an external setting, decide when it becomes effective. A DIP switch configuration sampled only at startup behaves differently from a continuously monitored setting. The installation instructions, firmware and functional test should describe the same rule.
| Review item | What to establish |
|---|---|
| Actions | Input conditions and required output behavior, including unavailable resources. |
| Startup | Physical ownership before and during firmware initialization. |
| Pin map | Exact identifiers, sharing rules and unresolved states. |
| Interfaces | Conditioning, drivers, power domains and representative loads. |
| Recovery | Trigger, response, resumption conditions and reproducible evidence. |
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. |
Use the pin worksheet to organize ownership
Enter the physical identifier, assigned function and intended startup state. The example map includes a repeated GPIO_A and an unknown state so the tool can demonstrate its warnings. These identifiers are fictitious and do not represent an approved MCU pinout.
Resolve every repeated assignment against the real device and circuit. Sharing may be intentional, but it needs an ownership rule, electrical compatibility and supported timing. The checker cannot infer multiplexing or tell whether a software library reconfigures a pin behind another function's back.
Treat unknown startup entries as questions to answer through documentation or measurement. Changing the text to low does not make the physical circuit low during reset. The purpose of the worksheet is to make assumptions reviewable, not to generate a cosmetic green status for an incomplete design.
Keep input conditioning connected to application meaning
Specify the electrical input and the interpreted value separately. Contact closure, logic level, debounced state and commanded action are different stages. A signal can be electrically valid while being too early, stale or inconsistent for the application's current state.
For analog inputs, define the useful range, filtering and conversion behavior. The signal-conditioner worksheet can express a range-mapping target, while the sensor integration guide addresses placement and physical influences. Neither establishes the controller's complete decision logic.
Test boundary conditions, including startup values, out-of-range signals and disconnection. Use known stimuli and record the observed action. A nominal reading under one condition is insufficient evidence for how the controller handles missing or changing input information.
Design output interfaces and power together
Describe the load, drive polarity, permitted switching behavior and inactive state. Include the source of load power, return path and relevant disturbances. A separate driver does not automatically isolate the controller from power transients or shared-reference effects.
Coordinate output activity with the power tree. Simultaneous loads can change the supply condition seen by sensors and the processor. If the system is powered through Ethernet, bring those conditions into the PoE budget at the correct boundary rather than relying on an average controller consumption figure.
Reserve a practical way to observe critical outputs without forcing risky probing or a production load into every diagnosis. A fixture or representative load can help, but its relationship to the real application must be documented. Keep electrical checks and product-level behavior distinguishable.
Define fault detection and recovery as testable behavior
For each relevant fault, state how it is detected, what action is taken and how normal operation can resume. Communication timeout, sensor failure, supply interruption and processor reset are different events. Avoid one generic error flag that conceals distinct required responses.
If a watchdog or supervisor is used, identify what it observes and what it cannot detect. Resetting a processor is not automatically the correct recovery for every product state. Test the actual resulting outputs and retained information, not only whether a reset event occurred.
Preserve the initial condition and trigger for each recovery test. An intermittent result without the sequence is hard to reproduce. Keep board, firmware, configuration and fixture revisions together so the next build does not silently inherit an outdated recovery assumption.
Prepare a controller release that supports an enquiry
Supply the fabrication package, BOM, placement information, quantity and the intended programming and functional-test scope. Identify customer-supplied loads, fixtures or reference signals and the expected observable responses. State any open design question that affects construction or assembly.
For a modular controller, retain the interface contract for each connected board. For a simple wireless implementation, compare the relevant ESP32 integration or ESP8266 integration guide only after the product requirements have established that device choice.
勛圖tv can review a defined build and its manufacturing questions against those files. The pin report can help explain ownership and startup assumptions, but it does not submit an enquiry, validate firmware or certify the control function. A precise behavior specification is the bridge between a useful prototype and a repeatable assembly request.
Keep the architecture connected to testable requirements
For each functional block, record the requirement it satisfies and the evidence that will show whether it does. A communication link needs a defined message and timing expectation; a power domain needs operating states and limits; an output needs its permitted startup and fault behavior. Assign responsibility for unresolved interactions between blocks.
Keep the architecture document small enough to stay current but precise enough to expose a changed assumption. When an interface, source or processor changes, revisit the affected power, timing, software and test requirements together. A board-level calculation can support that discussion without representing the complete product. The useful manufacturing handoff identifies a coherent revision and agreed scope, with open engineering questions visible rather than concealed behind a generic ready-for-production label.
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.
