Developers & Platforms

Choose boards, components and software tools through interfaces, electrical limits, reproducible builds and failure recovery.

A development board is one part of a complete experiment. Define the measurement, interfaces, power and software environment so someone else can reproduce the result.

Choose the experiment and environment

Microcontrollers

Plan firmware, pin assignments and behaviour during resets.

Single-board computers

Include the operating system, storage, services and updates.

Tools and libraries

Pin versions and keep a small known-working example before adding integrations.

Explore the complete development workflow

Boards and prototyping

Choose the exact board revision around its interfaces, memory, power and supported software. Record the pinout and required accessories before connecting a module. A board family name or a working demonstration on another revision does not establish that your wiring and library combination is supported.

Microcontroller boards · Single board computers · Development kits · Breadboards · Enclosures · Debug probes.

Open the microcontroller boards guide →

Components and electronics

Read the component and board documentation together, including supply voltage, signal levels, connection requirements and intended environment. Keep the first experiment within a documented low-voltage learning setup. Have a qualified person handle mains electricity, hazardous equipment and installation work.

Sensors · Actuators · Wireless modules · Power modules · Displays · Cables · Connectors · Battery systems.

Firmware and embedded systems

Map boot, configuration, sampling, communications and error handling before selecting libraries. Keep the build environment, target board and configuration in a reproducible record. Plan how a device reports its version and recovers from an interrupted operation instead of treating a successful upload as the whole project.

RTOS · Embedded Linux · Device drivers · Bootloaders · OTA libraries · Power optimization · Embedded languages.

Open the firmware and embedded systems guide →

SDKs APIs and integrations

Match an official SDK or API reference to the exact platform and version. Record authentication, supported operations, data formats and error behaviour. Keep credentials out of public examples and check the limits and support of any third-party package before making it a dependency.

Device SDKs · Cloud SDKs · REST APIs · Webhooks · Protocol libraries · Authentication libraries.

Open source and automation

Evaluate the project documentation, licence, maintenance and integration support for the intended task. Start with a small known-working flow and retain its configuration and dependencies. An open repository or community example does not establish that a deployment is maintained or suitable for every workload.

Home automation platforms · Flow automation · Message brokers · Device dashboards · Low-code IoT tools · Community projects.

Testing and observability

Define observable expected behaviour and retain logs or sample outputs for both normal and missing-input conditions. Choose instruments and methods appropriate to the signal and work safely within their documented limits. Keep a simulator result, bench observation and field measurement clearly identified.

Multimeters · Oscilloscopes · Logic analyzers · RF test tools · Simulators · Device test rigs · Telemetry observability.

Architecture and engineering

Document the power and data path, ownership, operating environment and recovery behaviour alongside the prototype. Review support, manufacturing and service requirements before treating a bench demonstration as a production design. Preserve assumptions and unresolved constraints for the next engineering decision.

Reference architectures · Power budgets · Connectivity planning · Data models · Reliability engineering · Manufacturing readiness · Device lifecycle design.

A practical example

For a proposed temperature logger, record the sensor model, wiring, units, sampling interval and timestamp source. Keep a sample output file and check disconnected-sensor behaviour before connecting the readings to a dashboard.

Questions to resolve

Are the electrical and protocol interfaces compatible?
Can the build be recreated without undocumented local settings?
What happens after a restart or interrupted update?

Use the evidence

The category map describes technologies and product types. It does not establish that a particular model is available, tested or compatible. Check the exact model, region, documentation and support arrangements before buying.

Work through the connected-technology buying checklist

Primary embedded-software references

Zephyr: device firmware upgrade concepts distinguishes image management from the transport that delivers it. Espressif: ESP32 OTA and rollback documentation describes platform-specific update behaviour. These references illustrate engineering responsibilities; always select documentation matching the actual SDK release, board and configuration.

Evidence: Category guide. Reviewed 2026-10-18. By Admin.