Camera library breaking change: fix embedded code that won't compile

Your sketch compiled yesterday. Today the same file stops on its third line with error: 'CameraClass' does not name a type, and nothing in your repository changed. That is the signature of a breaking change inside a board package's camera library: the platform shipped new headers, and your code is now calling an API that no longer exists. This walkthrough is for engineers building cameras into embedded boards on dev-style cores. You will confirm the diagnosis in 10 min, port the code in an afternoon using the library's own bundled example as the reference, pin the package version so the break cannot happen silently again, and decide when the better fix is architectural: moving the sensor driver out of your compile entirely.

The symptom: the compiler is correct, the header changed

The error text is precise, so read it as evidence rather than noise. 'CameraClass' does not name a type means that identifier was never declared in anything included above line 3. Did you mean 'CameraWire'? means the new headers do declare a similarly named type, and the compiler offers the nearest match. Both halves together say the class left the API — not that you mistyped it.

One build detail rules out the obvious suspect: the same project failed on two different IDE generations, the classic 1.8.x editor and the 2.x rewrite. When the editor is not the variable, the shared dependency is. Both IDEs pull the same board platform package, and the camera API ships inside that package. Version 2.8.0 of it carried an undocumented rework of the camera subsystem, so any install from 2.8.0 onward, including a fresh 3.0.1, no longer declares CameraClass.

The reason tutorials break is structural. The getting-started sketch for this camera shield was a copy of the CameraCaptureRawBytes example bundled with the library. The package update rewrites the bundled example; your copy in your repository stays frozen. Your sketch is a snapshot of an example that moved on without you.

Rank the likely causes, then test each

Work down this list in order; the first cause explains almost every occurrence of this exact error.

1. The package moved past a breaking release. Your code is fine; the headers changed under it. Test: compile the bundled CameraCaptureRawBytes example exactly as your installed package ships it. If the example fails too, stop — the problem is below your code (see cause 3).
2. Your sketch is a pre-update copy. It compiled before because the old API existed then. Test: the same bundled-example compile separates this from cause 1 — the example represents the new API, your sketch the old one.
3. Wrong board target or a damaged install. The camera class is declared for the camera-equipped core only, or the package half-updated. Test: reselect the board target and rebuild; if the bundled example still fails, reinstall the package at a chosen version.
4. A near-miss name. Least likely when the code compiled last week, but the suggestion is a lead: 'did you mean CameraWire?' points at a type that does exist in the new headers. Open that header and read the class list — it is the fastest map of the new API.

Library-level compile breaks are not a camera peculiarity — the same reproduce-with-the-library's-example triage is documented for troubleshooting Teensy MIDI controller library compile errors. The desktop-side twin, a camera SDK upgrade breaking a build, has its own walkthrough in Fixing camera SDK build errors after a library upgrade.

Porting the CameraCaptureRawBytes sketch to the 2.8.0 camera API

The inputs

• The error, from your build log: CameraCaptureRawBytes:3:1: error: 'CameraClass' does not name a type; did you mean 'CameraWire'?
• The versions, from the boards manager: release 3.0.1 installed; the camera subsystem rework shipped in release 2.8.0.
• The scope of the change, from the core repository: the camera subsystem commit of 07 Mar 2022 shows +1,616 added and 988 removed lines, with the sensor drivers rewritten against a new abstract ImageSensor class.
• The reference implementation, from the IDE's examples menu: the bundled CameraCaptureRawBytes example that ships with your installed package.

The rule

The bundled example is the only authoritative statement of the new API. Port call by call against it, and copy names from it — never reconstruct a name from what the old code looked like. The commit message tells you the shape of the port before you open a file: an abstract ImageSensor class with common sensor functions now sits between your code and the driver, drivers were rewritten against it, and the camera auto-detects and initialises the image sensor. That last point retires the manual sensor-select and init calls a tutorial-based sketch usually contains.

The arithmetic

1,616 + 988 = 2,604 changed lines in one subsystem commit. Set that against a sketch-sized program of 200-300 lines: the change surface is roughly ten times your entire file, so no sequence of find-and-replace renames can cover it. This is where the threshold call comes from: a camera-subsystem diff above about 1,000 changed lines is an API replacement, so plan a porting session of 4 h for a sketch, or a full 8 h day once hardware tests are included. Below that line, the diff usually hides one or two renames you can fix in minutes. At 2,604 lines, this case sits at 2.6 times the threshold.

The result

The port reduces to three mechanical moves, each copied from the updated example:

1. Delete the manual sensor selection and initialisation block; auto-detection now does that work.
2. Recreate the camera object exactly as the updated example declares it, verbatim.
3. Move the frame buffer to the allocation the example uses.

// OLD — valid on packages before 2.8.0 only
CameraClass cam;              // line 3: this declaration no longer exists

// NEW — copy the declaration and the start-up calls verbatim from the
// bundled CameraCaptureRawBytes example of your installed package;
// the rework auto-detects the sensor behind the abstract ImageSensor class

The test that proves the port: the bundled example and your sketch compile with zero errors in the same session, against the same package version, and then a live capture delivers frames at the expected resolution.

The decision

A 2,604-line diff means port, not patch: budget the session, and pin the package at the version you validated until the ported sketch passes its functional test. Do not bend the old code into the new headers with preprocessor tricks — at a ten-to-one change surface, reading the example is faster than archaeology on your own file.

Pin the package version while you port

A break like this is silent by default: the package updates whenever the IDE or a setup step asks for the latest, and nobody reads a changelog on the way. Make the version a project decision instead.

• In the boards manager, install a specific platform version rather than the latest — the release your port was validated on.
• In any scripted or CI build, declare that version in the build configuration. The two-IDE detail from the symptom section is the argument: a pin that lives in one person's IDE settings is not a pin.
• Record the validated version in the repository next to the code, with the date it passed your functional test.

This is the same discipline as pinning one library version across a container build (Docker build SDK version mismatch: pin one library version everywhere) and as holding an SDK steady on a deployed edge device (Edge inference device crashes: fix with SDK version pinning). Version discipline on the device side extends to camera firmware too — the camera firmware update workflow runs a release from approval to readback for exactly this reason. And porting working production code onto a changed API is its own craft: the approach used when refactoring legacy LabVIEW code without breaking production carries over directly — test harness first, then one call at a time.

Lift the pin only deliberately: install the next package, compile the bundled example, port what moved, run the full test, then update the recorded version. An unpinning nobody scheduled is how the next Monday starts with this same error.

When churn is the design: move the sensor boundary out of your compile

If platform updates break you once, they will break you again — dev-core packages move fast and carry no deprecation cycle. The durable fix is to put the sensor driver where those updates cannot reach it: in camera firmware, behind a versioned interface.

With a GigE Vision or USB3 Vision module, your carrier board no longer compiles a camera library against platform headers. The module's firmware owns the sensor; your application consumes frames over a standard protocol, and a sensor change arrives as a camera firmware release you schedule, not as a broken header on a Tuesday. The failure boundary you just spent an afternoon repairing moves out of your build entirely.

Three modules cover the common cases: a global-shutter USB3 module for motion, a rolling-shutter GigE module for static scenes, and a compact global-shutter GigE module for tight spaces.

For motion, the LS-BCM-0003 is a 3.1 MP USB3 board camera built on a 1/1.8" global-shutter IMX252 sensor at 120 fps, with a C-mount. For static scenes, the LS-BCM-0020 pairs a 6.3 MP IMX178 sensor with GigE at 18 fps, rolling shutter, CS-mount. For tight spaces, the MV-CB016-10GM-M-W is a 1.6 MP mono GigE board-level camera with a global-shutter IMX296 sensor behind an M12 mount.

Before swapping the interface, check the plumbing that changes with it — cable, power, mounting, host driver support — in Camera module interface compatibility: what to verify, and match the module to the machine with Board level camera selection for embedded vision machines. If your camera hangs on a MIPI bus instead of USB or Ethernet, driver trouble has its own playbook: MIPI camera driver install fails on a third-party carrier board.

On the compute side, a vision controller keeps the acquisition stack on hardware built for it. The MV-VC2140-128G40-1T pairs an Intel N-series N97 processor with 8 GB of RAM plus a 128 GB SSD and a 1 TB HDD, 3-4 LAN ports, 2 USB 3 ports and 4 built-in light channels, so the moving parts reduce to camera firmware and SDK versions — both of which you pin on your own schedule.

Size the module and the compute together in the camera configurator, browse board-level cameras or vision controllers, or filter by interface in the camera finder.

Checks before you call it fixed

1. The bundled example compiles clean on the exact installed package version and board target. This proves the toolchain before it proves your code.
2. Your sketch compiles with zero errors against the same version — no commented-out includes, no local copies of old headers kept around.
3. A live frame arrives. Compile-clean proves names, not runtime; capture a real frame and check its dimensions and content before you sign off.
4. The pin is written down: the validated package version recorded in the repository, dated, and declared in any build script or CI job.
5. The upgrade rule is agreed: before the next package update, read the camera subsystem's diff first. Its size against the 1,000-line threshold tells you whether the upgrade is a minutes-long rename or a scheduled port.

Run the bundled-example compile today; in 10 min it tells you whether your afternoon is a rename or a port. If the verdict is that platform churn, not your code, is the real defect, start the architectural fix from the pages above, or bring the design to the applications team through the contact page. More triage walkthroughs like this one sit on the systems topic page.