Arduino
Enable an AI agent to recognise an Arduino development board, assess its electrical and programming state, and determine which connections, firmware changes and operating actions are appropriate.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
recalled by Codex without web access - no source was read
Researched by: Codex
Purpose and description
Enable an AI agent to recognise an Arduino development board, assess its electrical and programming state, and determine which connections, firmware changes and operating actions are appropriate.
Arduino denotes an open-source electronics prototyping platform whose programmable development boards connect a processor to input/output interfaces for sensing and controlling physical systems; in this physical-object sense, the term covers the board family rather than the associated software or organisation.
It can be Identify the board variant and obtain its matching pinout, schematic and programming target.; Check a proposed power supply, shield or peripheral connection against the board's documented limits.; Select a compatible board package, upload route and firmware build.; Read available diagnostics and observe execution without treating a successful upload as proof of correct application behaviour.; Upload, reset or recover firmware while accounting for connected actuator behaviour and existing program preservation.; Assess whether the board can support a proposed sensing, control or communication task..
Distinguishing features
Identify the specific board design from markings, layout and documentation; an Arduino name alone does not establish processor, pinout or electrical limits.
Distinguish an official Arduino board from a third-party compatible board using documented manufacturer and product identity; compatibility does not establish official provenance.
Distinguish a development board from a bare microcontroller by its board-level power, connection and programming facilities.
Distinguish hardware identity from Arduino software support: being programmable through an Arduino toolchain does not by itself identify a board as an Arduino product.
Treat a named board variant as a kind and its individual physical copy as a unit whose installed firmware, damage and modifications can differ.
Scope
+ Board identity, revision and relationship to an Arduino board design or compatible implementation
+ Processor, memory and peripheral capabilities that constrain sketches and connected hardware
+ Power inputs, logic levels, pin functions and electrical operating limits
+ Boot, programming, firmware execution and communication states
+ Shield and peripheral compatibility, physical condition and readiness for a proposed use
- Arduino as a company, trademark owner or community
- IDE, compiler, board-package and library internals, except their compatibility with the board
- Complete robots, instruments and other systems built around a board
- Sensors, actuators, shields and power supplies as independently modelled things
- Application source code and its intended behaviour, except its relationship to firmware installed on the board
Characteristics
- Board design and revision
- Documented product name, board identifier and hardware revision; unknown where unverified Determines which pinout, schematic, electrical limits and programming instructions apply.
- Manufacturer and compatibility relationship
- Manufacturer; referenced Arduino design; official product, third-party compatible implementation or unresolved Separates provenance from electrical, mechanical and software compatibility.
- Processor configuration
- Processor part identifiers, architecture and roles of application, communication or auxiliary processors Constrains compilation targets, peripheral availability and recovery procedures.
- Memory capacity
- Bytes of program, volatile and nonvolatile storage, with reserved and usable amounts distinguished Helps judge whether a sketch and its runtime data can fit.
- Power-input limits
- V and A for each documented input path, with recommended operating ranges distinguished from absolute limits Supports selection of an appropriate supply and assessment of simultaneous power connections.
- I/O electrical limits
- Logic voltage and permitted input voltage in V; per-pin and aggregate current limits in mA Determines whether peripherals need level translation, buffering or separate drivers.
- Pin and peripheral assignment
- Board-labelled pins mapped to processor functions, buses, shared resources and connected devices Exposes conflicts between GPIO, analogue input, communication and shield use.
- Analogue and timing capability
- ADC or DAC resolution in bits where present; reference voltage in V; clock and applicable PWM frequencies in Hz Constrains sensing precision and waveform generation without assuming identical capabilities across boards.
- Firmware identity
- Installed image or build identifier linked to source, target configuration and upload evidence; unknown if unavailable Connects observed behaviour to a reproducible program.
- Programming and execution state
- Unpowered, booting, programming, executing, held in reset, fault suspected or unknown Determines which diagnostic and recovery actions are meaningful.
- Mechanical interface
- Board dimensions, mounting positions and connector geometry in mm Supports enclosure and shield fit checks independently of electrical compatibility.
- Physical condition
- Inspection observations for connectors, headers, solder joints, contamination, heating damage and modifications Determines whether documented capabilities remain plausible for the particular unit.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 17 findings · 27 questions.
Board identity and compatibility Establish which physical Arduino board kind is represented and which documentation applies.
Arduino spans multiple board designs, and appearance or software support alone cannot establish their capabilities.
Design identification
Resolve product identity and hardware revision from physical and documentary evidence.
Board design evidence
Record markings, processor identifiers, connector layout and the documentation they support, retaining uncertainty when these disagree.
- Which product and hardware revision match the board's markings, processor and connector layout? definition
- Which manufacturer document or schematic supports that identification? provenance
Compatibility boundaries
Separate official product identity from compatibility with a design or toolchain.
Compatibility dimensions
Assess mechanical fit, pin assignment, electrical behaviour and programming support separately.
- Is the board an official Arduino product, a documented compatible implementation or a board with Arduino software support only? boundary
- Which claimed compatibility dimensions are documented, and which remain untested? provenance
Power and pin electrics Describe permissible power paths and electrical interactions through the board's connectors.
A connection that physically fits can still exceed an Arduino variant's voltage or current limits.
Power paths
Identify supply entry points, regulation and interaction between attached supplies.
Supply path selection
Record operating limits and protection behaviour for each available power input without assuming all boards share the same power-selection circuit.
- Which USB, connector or header paths may power this board, and what operating voltage and current constraints apply to each? measurement
- May the proposed supplies be connected simultaneously, and what evidence establishes backfeed or power-selection behaviour? action
Signal electrical limits
Determine whether connected signals and loads are electrically compatible.
Pin loading and levels
Relate pin-specific voltage tolerance, current limits and grounding requirements to the proposed circuit.
- What input-voltage, output-current and aggregate current limits apply to the pins being used? measurement
- Which proposed connections require level translation, a driver, a shared reference or an independently powered load? action
Sketch execution and programming Connect the board's processor and memory to its build, upload and execution lifecycle.
A sketch must match a specific target and upload route, and programming success does not establish application correctness.
Execution target
Establish the resources and software target needed to build a runnable image.
Target and resource fit
Record processor architecture, available memory and target settings relevant to the proposed sketch.
- Which processor, board package and target settings correspond to this board revision? definition
- How much program and runtime memory remains available after platform reservations and the proposed build? measurement
Upload and recovery
Identify programming interfaces, installed firmware evidence and recovery options.
Firmware transition control
Describe how firmware can be identified, replaced and recovered, including reset behaviour and effects on connected outputs.
- What evidence identifies the installed firmware, bootloader where applicable and last successful upload? provenance
- Which upload or recovery procedure applies, and what must happen to connected loads before reset or reprogramming? action
Pins, shields and peripherals Represent how board resources are exposed and shared by connected hardware.
Arduino projects depend on pin mappings and expansion conventions whose details vary across designs.
Pin function allocation
Map board labels to available functions and shared processor resources.
Multiplexing and resource conflicts
Track selected pin functions and dependencies between buses, timers, analogue functions and libraries.
- Which board-labelled pins provide the required GPIO, analogue, PWM and communication functions? definition
- Do the selected libraries and peripherals compete for pins, timers, bus addresses or other shared resources? boundary
Expansion fit
Check shields and modules against the particular board's physical and functional interfaces.
Shield and module matching
Assess connector alignment, pin usage, supply demand and software support as distinct requirements.
- Do the proposed shield's connector geometry and pin assignments match this board revision? measurement
- What adaptations are required for the shield or module to operate within the board's electrical and software constraints? action
Condition, diagnostics and use readiness Assess whether a particular board can perform a proposed task and how faults can be isolated.
Documented board capabilities do not establish the condition of a unit or the behaviour of its attached circuit.
Board fault isolation
Interpret observations across power, host connection, upload and application execution.
Diagnostic evidence
Use physical inspection, supply measurements and interface observations to narrow faults without assuming every board exposes the same indicators.
- What do inspection, supply-rail measurements and available indicators reveal about the board's present state? measurement
- Which checks can distinguish a cable or host-interface problem from a boot, firmware or attached-circuit fault? action
Application readiness
Relate observed operation and documented limits to the intended deployment.
Readiness and system boundary
Record evidence for required sensing, timing and output behaviour while assigning enclosure, load protection and system-level compliance to the assembled system.
- Which observations demonstrate that the installed sketch meets the proposed task's timing, sensing and output requirements? measurement
- Which environmental limits and product approvals apply to the bare board, and which requirements must be assessed for the completed assembly? boundary
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Check these first
Recalled without web access and unsourced; every item is a lead to verify.
- The recorded name is ambiguous between the platform, organisation and hardware; this description selects the hardware-family sense suggested by PHY.OBJ.
- Electrical limits, dimensions, processors and connectivity vary substantially by model and revision; the measurements given are explicitly scoped examples.
- No sources were consulted. Applicable conformity requirements and certification claims require verification for the exact board and destination market.
- Which of these check these first hold for the sense of Arduino this model covers, and on what evidence? provenance
Kinds and varieties
Recalled without web access and unsourced; every item is a lead to verify.
- Uno boards
- Nano boards
- Mega boards
- MKR boards
- Due boards
- Portenta boards
- Which of these kinds and varieties hold for the sense of Arduino this model covers, and on what evidence? provenance
Identifiers and schemes
Recalled without web access and unsourced; every item is a lead to verify.
- Arduino board model and revision - Arduino Uno Rev3 - Identifies a board design and revision, not an individual physical unit.
- Arduino Fully Qualified Board Name (FQBN) - arduino:avr:uno - Identifies a software build target for the Uno in the Arduino AVR Boards package; it is not a hardware serial number.
- Which of these identifiers and schemes hold for the sense of Arduino this model covers, and on what evidence? provenance
Real-world use
Recalled without web access and unsourced; every item is a lead to verify.
- Teaching programming, electronics and embedded systems
- Prototyping sensor acquisition and data logging
- Controlling robots through external motor drivers
- Building interactive installations and physical user interfaces
- Prototyping connected monitoring and automation devices
- Which of these real-world use hold for the sense of Arduino this model covers, and on what evidence? provenance
Typical measurements
Recalled without web access and unsourced; every item is a lead to verify.
- Digital logic voltage - 3.3 or 5, depending on board; input tolerance must be checked separately - V
- Processor clock frequency - 16 for Uno Rev3 and Mega 2560 Rev3; 84 for Due - MHz
- Uno Rev3 board outline - 68.6 × 53.4 - mm
- Which of these typical measurements hold for the sense of Arduino this model covers, and on what evidence? provenance
Failure modes and hazards
Recalled without web access and unsourced; every item is a lead to verify.
- Overvoltage, reversed polarity or incorrect power connections can damage the board.
- Applying 5 V signals to inputs that are not 5 V tolerant can damage 3.3 V boards.
- Driving motors, relays or other substantial loads directly from input/output pins can exceed electrical limits.
- Inductive voltage transients, electrostatic discharge and short circuits can damage components or cause resets.
- Software faults or brownouts can produce unintended actuator behaviour; safety-critical control requires independent protective measures.
- Which of these failure modes and hazards hold for the sense of Arduino this model covers, and on what evidence? provenance
Neighbouring kinds and how to tell them apart
Recalled without web access and unsourced; every item is a lead to verify.
- Microcontroller - A microcontroller is an integrated circuit; an Arduino board packages a processor with supporting circuitry, connectors and a development ecosystem.
- Arduino IDE - The IDE is software used to develop and upload programs, rather than a physical development board.
- Arduino-compatible board - Compatibility describes support for some Arduino interfaces or software; it does not establish that a board is an official Arduino product.
- Shield - A shield is an expansion board that adds functions to a compatible host board.
- Which of these neighbouring kinds and how to tell them apart hold for the sense of Arduino this model covers, and on what evidence? provenance
What the second pass must settle
- Does vr.tr.arduino intend official Arduino hardware only, or also third-party compatible boards? The PHY.OBJ placement supports a board-focused interpretation but does not settle membership.
- Does an existing Vercy world model already cover this board concept, requiring this registry entry to link to that model?
- Which board families and revisions must the initial researched model cover, and which manufacturer documents establish their differing electrical and programming requirements?
- How should hardware with Arduino toolchain support but no claim to Arduino board identity relate to this entry?
- Which board-specific environmental ratings, conformity declarations and recovery procedures can be verified from primary documentation?