Onboarding

From your PCB to verdicts.

What it actually takes to get your board onto the Oracova bench: the hardware, the documents, and the bring-up. Two paths, depending on whether you already have working firmware.

STEP 1

The hardware

A custom DUT board is made for your microcontroller and goes onto the Oracova base board. DUT designs are open source.

Oracova base board

The world, in real time

Plays your sensors and loads protocol-exact and runs the physics models. The world responds like the product's world does.

Analog front-end modules

Voltages and currents, first-class

DAC and ADC modules come in different resolutions and speeds; you pick the ones your signals need. Unusual signal? A module can be built for it.

Custom DUT + debug probe

Your microcontroller's seat

Built for your part, every pin routed to the base board. Your code runs on your real silicon, not a substitute part. The probe flashes, resets, and inspects the target while it runs.

Benches are cheap to replicate. One per PR, one per agent, as many as your team runs in parallel.

STEP 2

The documents

Next is collecting information: your actual PCB, its schematics, datasheets, pin assignments, and a description of how the product works. This is what the bench will stand in for.

STEP 3

The bring-up

Now the world comes up. An AI agent does the work, with your confirmation along the way.

On either path, expect some questions about your hardware and its physics, or documentation that answers them. The agent asks, it does not guess.

If you have working firmware

01Read the source The AI learns the world your firmware expects: peripherals, protocols, what it drives and senses.
02Write the world It writes the I/O behavior and the physics models.
03Run and compare Your unmodified binary runs on the DUT, the debug probe watching internal state, behavior compared against the field.
04Iterate to golden Until your firmware runs on the bench the way it runs in the product. That recording is golden; the suite builds on it.

If you do not have working firmware yet

01One peripheral at a time The bench and the firmware grow together, interface by interface.
02Both sides together The firmware driver on the DUT and its counterpart in the world, brought up as a pair.
03Proven before the next Each peripheral passes on the bench before the next one is added.
04The suite is the record By the time the firmware is whole, the regression suite already exists. There was never an untested part.
The open-source marketplace

The world rarely starts from zero. Common peripherals, a gyro, an LCD, a hall encoder, come as validated models from Oracova's open-source marketplace, already proven against real firmware on other benches. The AI builds what is unique to your product and pulls the rest. And what you build, you can contribute back.

Where the boundary sits
  • Emulated: everything your microcontroller senses and drives. Digital buses (GPIO, PWM, UART, I2C, SPI, CAN) connect directly; analog signals go through front-end modules built for your board.
  • Not emulated: your power stage. High voltage and high current stay off the bench. Your firmware still sees the same signals it would see in the product.
  • Proven today: the closed loop runs on real silicon now: motor commutation, servo, pump, thermal, and unmodified Betaflight.

Want to walk through it on your board?

Bring your schematic to the call. 15 minutes, no deck.

Book 15 minutes