Running a sketch on both cores of a dual-core vision board

Compact vision boards increasingly ship with a dual-core processor: a fast application core for image handling and a smaller secondary core for deterministic work. Engineers who are used to single-core boards often look for a menu entry to pick a core, do not find one, and conclude the second core is unusable. It is not. Most of these boards are configured with one board entry, and the core split happens inside your project: one sketch is built for the application core, another for the secondary core, and the two talk over a remote procedure call (RPC) channel. The sections below explain what each core should do, how the link works, what a sensible loop budget looks like, and how to deploy both sketches cleanly.

What each core is for

The fast application core runs the acquisition loop, image buffering, your inspection logic and any network interface. The secondary core is often slower and has less memory attached. Its timing predictability depends on interrupt load, memory access and the tasks assigned to it; a second core alone does not guarantee less jitter.

That predictability is the whole point. Trigger handling, encoder counting, latch and clamp sequencing, strobe timing and watchdog refresh belong on the secondary core. Anything that depends on pixel data belongs on the main core. A practical threshold: if a task moves more than a few kilobytes per cycle, keep it on the main core.

If you are still choosing the board itself, the board level camera selection for embedded vision machines guide covers sensor, shutter and interface choices first; the core split is the step after that.

A board like the MV-CB016-10GM-M-W pairs a 1/2.9" sensor, a global shutter and an M12 mount with a GigE interface. In a compatible dual-core host design using such a module, the main core can manage acquisition while the secondary core handles supported trigger and strobe signals. Verify the host interface and camera I/O requirements separately; the camera module does not establish the host's core architecture.

How the cores talk

The standard pattern is an RPC pair: the secondary core sketch registers functions, and the main core sketch calls them. Two details matter more than the API syntax.

First, both sketches must be present when the board package uses separate firmware images. Follow the manufacturer's core-specific example and deployment instructions. If you flash only the main core, a call into an unavailable secondary-core service can block or return an error, depending on the RPC implementation.

Second, the channel is a control plane. Passing trigger counts, setpoints, flags and small results works well. Passing full frames does not. Keep messages fixed-size, keep the shared buffer small, and measure the round trip before you design around it.

A loop budget you can check

Before writing code, put numbers on the cycle. For a sequential implementation without overlapping stages, a rough cycle time is the sum of acquisition, transfer and processing, plus the secondary-core round trip:

Worked example. Suppose your sensor exposes for 5 ms, the frame takes 3 ms to transfer over the bus, and your inspection routine needs 20 ms. The RPC round trip for trigger handshakes is 0.4 ms. Then T_cycle = 5 + 3 + 20 + 0.4 = 28.4 ms, so the estimated limit is about 1 / 0.0284 ≈ 35 frames per second, before additional overhead. If the line runs at 40 parts per second, the available cycle time is 1 / 40 = 25 ms. You must remove at least 3.4 ms from the critical path, plus operating margin. Moving trigger handling alone cannot provide that saving unless measurements show it accounts for enough time.

If your own numbers differ, work them through the same arithmetic. When you are sizing pixels per part instead, use the camera resolution calculator.

Deployment models compared

The middle column is what you are setting up when you deploy a sketch to each core. The right column is what you get when the board vendor's SDK already manages the second core; it is worth checking whether your board package does this before hand-rolling the split.

How to deploy both sketches

1. Confirm the board package supports a secondary-core target. Look for core-specific RPC examples in the installed examples; their names usually name the core.
2. Write the secondary-core sketch first: register the functions the main core will call, keep them short and non-blocking.
3. Write the main-core sketch: call those functions with timeouts, never without.
4. Upload each sketch using its documented build target and the manufacturer's required upload order. On boards with a single menu entry, target selection may live in the example or build settings.
5. Follow the documented reset and secondary-core startup sequence. Some systems require the application core to start the secondary core explicitly.
6. Verify with a sketch that prints which CPU it is running on; do this before adding application logic.
7. Measure the RPC round trip with a counter swapped between cores and the arithmetic from the section above.

If the board is not detected at all during step 4, work through camera module interface compatibility checks before suspecting the core split — cable and power faults mimic firmware faults.

For stereo or dual-sensor heads, the LS-BCM-0043 offers 1.3 MP resolution, a 1/2" format, USB3 and a global shutter with an M12 mount. In a compatible host design, a secondary core may coordinate supported exposure signals while the main core processes both streams. Confirm synchronization support in the camera documentation rather than assuming it follows from having two sensors or two processor cores.

Checks before you commit

• Flash both cores and reset; confirm the RPC call returns within its timeout.
• Power-cycle, not just soft-reset, at least once: some boot faults only appear cold.
• Check trigger jitter on the secondary core with a scope across a thousand cycles.
• Watch main-core heap and stack use; the RPC layer adds buffers on both sides.
• Test what happens when the secondary core is deliberately held busy — the main core must time out and recover, not hang. Run this fault test on an isolated bench setup with motion and hazardous outputs disabled through the machine's approved procedures.

The wiring side matters too: camera GPIO wiring: prevent damage and triage power faults covers protecting the I/O lines your secondary core will drive.

When a second core is the wrong answer

If your bottleneck is pixel throughput or a network stack, a secondary core will not save you unless it can take over work on that critical path; you may need a faster main processor or a host. For multi-camera cells, an external controller is often simpler: the vision controllers category lets you compare camera connections, processing resources and light outputs without depending on a shared-chip firmware split.

The MV-VC2140-128G40-1T vision controller provides 8 GB of memory and 4 built-in light channels. It offloads the whole application rather than sharing one chip.

Also watch bus saturation: if several modules share one host interface, the constraint is the bus, not the core. The board camera evaluation checklist helps organize interface and acquisition tests before you commit to the hardware.

Short checklist

• Both sketches uploaded, documented startup sequence completed, RPC verified with a CPU-ID print.
• Timeouts on every cross-core call, watchdog independent on the main core.
• Cycle budget calculated and compared against line speed with margin.
• Fallback behaviour defined for a secondary-core failure. Reject affected inspection results and use the machine's approved fault response when trigger or sequencing state becomes uncertain; ordinary core-to-core communication is not a safety function.

If you are building the hardware side from scratch, start at the board-level cameras category or the camera finder, then step through the camera configurator to match sensor, mount and interface. And if a sensor in an existing board goes end of life, the board level camera replacement when a sensor goes end of line guide covers the swap without rewriting the firmware split. For anything unusual, our contact page is the route to the applications team.