Appearance
Work with Equidna on hardware and firmware #
Equidna helps connect the hardware design to the software that will run on it. Ask it to identify a board, read a schematic or netlist, trace a signal to a header pin and Linux interface, or work through how a container should use that hardware and communicate through the Dataplicity agent.
Start a private conversation with Equidna from the specialist chooser. You can keep the wider hardware discussion with colleagues in Casa del Pingüino and invite the specialists offered in that room's invitation chooser.
Establish the exact board first #
Provide the manufacturer, full model, board revision, processor or module, and operating-system image. Add a clear photograph, the manufacturer's product link and the relevant schematic or netlist. For a custom design, include connector labels and the part of the circuit involved in the question.
We have a Waveshare carrier board with a Raspberry Pi Compute Module. Here is the exact product link and a photograph of the revision marking. Identify the board and matching schematic. Before suggesting wiring, tell us which revision you are using and what you still need to confirm.
Similar-looking boards can expose different pins, power paths or interfaces. Ask Equidna to tie its answer to the specific drawing and revision, with a reference you can check.
Trace a signal from the schematic to software #
Ask for the complete path rather than only a GPIO number:
Trace net SENSOR_IRQ from the sensor connector to the processor. Give the connector pin, any intervening components, signal voltage, processor pin, GPIO mapping and expected Linux interface. Cite the schematic sheet or netlist entries and mark any part you cannot confirm.
A useful answer distinguishes physical header numbering, processor GPIO numbering and Linux line names or offsets. It also identifies whether the interface needs a driver, device-tree configuration, pull-up, level shifting or another part of the design.
For an unfamiliar circuit, ask Equidna to explain the purpose of the relevant components and what you should measure before connecting the sensor. You can also ask it to help plan EMC considerations around cabling, grounding, filtering and interfaces for your product's intended environment.
Review the mapping against your actual hardware. Equidna provides design-phase guidance; use your schematic and PCB editor to change the design and your engineering validation process to qualify it.
Work out what the container needs #
Once the hardware path is understood, explain what the application must do and ask for the software requirements:
This gateway reads the sensor every second and reports level and fault state. Outline the container integration: CPU architecture, dependencies, driver and device-tree prerequisites, Linux device access, permissions, persistent state, logs, startup and restart behaviour. Explain how it publishes data and handles controls through the Dataplicity agent. Give us a minimal bench-test checklist.
Use the answer to settle the integration details:
| Concern | What to establish |
|---|---|
| Runtime | Target CPU architecture, base image and required libraries |
| Hardware interface | The verified Linux device or interface, driver and host configuration |
| Access | Required device mappings, user/group permissions and privileges |
| State | What can be recreated and what must survive a restart or update |
| Agent integration | Device Class channels, settings, actions and reported outcomes |
| Operations | Useful logs, health evidence, restart policy and recovery |
| Delivery | How to build, release, install and verify the image |
Ask for a sample container definition or implementation outline once those requirements are clear. Check generated examples against the target architecture and installed runtime. Keep the hardware configuration explicit; broad container privileges should not substitute for identifying the interfaces the application needs.
See Software workspace and delivery, what runs on the device, and the device data and control contract for the implementation paths.
Bring the result back into the product design #
Share the confirmed interface and device behaviour with Nutria when planning the customer workflow, and with Pingüino when troubleshooting the running system. For example, “no reading” may mean a sensor fault, stale data, an application failure or loss of connectivity. Model those states explicitly so the customer view and support tools can distinguish them.
Finish the bench test by checking a real measurement, a restart, a connection outage and recovery. Record what the hardware did and what the app reported. That gives your team evidence to build on when moving from one board to a deployed product.