视觉画布设计
canvas-design
基于设计原则创作静态视觉作品,用于海报与品牌图形。
electronics【文档与办公】Design, review, prototype, measure, and troubleshoot electronic circuits using component evidence, worst-case calculations, interface contracts, and staged bench verification. Use for component selection, analog or digital building blocks, power and protection, sensor conditioning, schematic-to-wiring review, instrumented diagnosis, and I2C electrica…
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Turn a desired physical behavior into a justified circuit and an observable verification result. Treat the schematic, components, layout, power source, load, measurement setup, and environment as one system. A plausible schematic or successful simulation is an intermediate artifact, not proof of a working assembly.
Load only the references needed for the current decision. Each reference contains assumptions, worked reasoning, failure patterns and acceptance guidance; templates turn that reasoning into reviewable artifacts.
| Task | Reference | Artifact |
|---|---|---|
| Choose or replace a component | Component selection | Component contract |
| Bound a ratio, threshold, accuracy or loading error | Tolerance and error budgets | Calculation record |
| Review a supply, switch, driver, clamp or heat problem | Power, thermal and protection | Component contract and calculation record |
| Review amplification, thresholds, logic and interface behavior | Analog and digital building blocks | Component contract |
| Integrate or calibrate a sensor | Sensors and conditioning | Calibration plan |
| Translate a schematic into physical connections | Schematic to bench | Schematic review |
| Choose or interpret a measurement | Measurement and instrumentation | Measurement plan |
| Review I2C electrical behavior and transaction evidence | I2C integration | Bus electrical budget |
| Localize a fault | Fault isolation | Fault ledger |
| Accept an assembly and its observed behavior | Assembly and verification | Assembly acceptance |
Record what the circuit must do and what failure would mean. Identify supplies, loads, signal ranges, timing or bandwidth, duty cycle, environment, allowable error and operating modes. Distinguish a component, a module with additional circuitry, and a complete board. A photograph can suggest identity but cannot establish pinout, rating, isolation or health.
Request only missing inputs that affect the decision. Label each as blocking, useful for confidence, or unnecessary for the current calculation. If specifications conflict, surface the conflict and present feasible changes rather than selecting a nominal compromise silently.
Use the actual topology. Include parallel paths, source/load impedance, bias/leakage, power-up states and temperature dependencies where material. State whether an error budget is a guaranteed bound or a statistical estimate and why the combination method is valid. Do not combine correlated systematic errors as independent noise.
Evaluate component and instrument limitations together. A meter or probe changes the circuit it observes. A low DC error does not establish settling, stability, bandwidth or noise performance. A protection device must survive the relevant fault waveform and leave the protected device inside its own limits.
Record the controlling corner and margin, then identify assumptions whose uncertainty could reverse the decision. Prefer a simple independently checked model over an elaborate simulation with undocumented component models.
Trace current loops, return paths, polarity, reference nodes, connectors and power sequencing. Check schematic connectivity against the real breadboard or assembly. Identify paths that can back-power an unpowered device. Separate board logic pins from load power paths; driver and protection choices depend on the actual load and fault conditions.
Do not treat generic layout advice as a verified PCB design. Trace the relevant coupling or current-return mechanism, consult the actual component's guidance, and specify how the proposed arrangement will be tested.
Start with appropriate unpowered inspection and continuity/resistance checks, then controlled power and progressively enabled functions. Meter mode, lead jack, probe rating, reference connection and energy source must be correct for the measurement. A current limit is not a substitute for understanding stored energy or the instrument grounding path.
For connected hardware, retain target identity, instrument configuration, initial state, expected result, observation and restoration steps. A bus scan is an active transaction and may change a device; an ACK is not an identity or functional test.
Conclude with one of: accepted for the stated conditions; rejected with the controlling failure; conditionally acceptable under named assumptions; or inconclusive with the smallest decisive next test. Separate modeled, simulated and physically measured evidence. Record design/firmware revision when software affects the circuit.
For a measurement diagnosis, include a compact evidence row even in a short answer: quantity/test point, stated instrument configuration, model prediction, reported observation, interpretation and next check. Mark supplied readings as user-reported and unperformed measurements as planned; do not turn a prediction into a claimed observation. Use the measurement template for larger tasks.
For troubleshooting, stop after three non-converging passes and summarize the evidence, eliminated hypotheses, remaining uncertainty and next specialist or artifact needed. Do not keep swapping components or repeating scans without a new hypothesis.
esp32-development skill. This skill still owns the electrical model and measurement reasoning for the attached circuit; do not duplicate framework instructions here.fpga-development skill. Electrical compatibility remains part of this skill's scope.The requested decision has a concrete artifact; assumptions and unknowns are visible; calculations and units are reproducible; chosen operating conditions are justified; relevant measurements or outstanding tests are recorded; and the conclusion matches the strength and scope of the evidence. An analysis task can finish with a sound conditional result. A hardware verification task cannot finish on calculation or simulation alone.