Infineon turns sensor data into embedded AI with DEEPCRAFT

Infineon’s DEEPCRAFT software helps developers build or adapt AI models for embedded devices. The portfolio spans custom model creation, conversion of existing models and packaged solutions, with deployment paths into Infineon hardware. The useful starting point is a concrete sensor-driven behavior: what the device should recognize, what resources it can use and what it should do when the input is unclear.

01 / ProductDEEPCRAFT separates building a model from converting one

The AI Suite overview organizes the offer around building custom models, bringing existing models and deploying packaged solutions. Its AI Hub collects tools, models and reference resources. That is a useful map for a buyer: possessing labeled recordings, possessing a trained network and needing a prebuilt feature are different starting positions.

DEEPCRAFT Studio supports classification, regression and computer vision development from time series or image data. Its graph interface represents the modeling workflow, while Studio Accelerators provide starting material such as datasets, preprocessing and model architecture. An accelerator is a development aid; suitability still depends on the data and behavior required by the finished product.

Model Converter takes a different route. It converts, optimizes and validates existing models for supported Infineon devices, with GUI and command-line access. The current page identifies PSOC 6 and PSOC Edge targets and describes validation on the desktop. That distinction matters: agreement with a reference model on a workstation does not establish timing or power use in the shipping device.

Infineon acquired Imagimob, and current Studio materials explain its earlier Imagimob Studio name. Documentation and license pages still use the Imagimob domain. These are parts of the same covered offer, rather than separate companies deserving duplicate blueprints simply because the developer documentation retains its established address.

02 / AudienceA bounded device response is a better fit than open-ended reasoning

The likely reader is an embedded engineer or product team with access to representative sensor recordings and control over the target hardware. A wearable gesture, appliance sound or local presence signal can become a useful feature without a large conversational model. Success can be defined in terms of detected events, missed events, nuisance triggers and the device resources consumed.

A less suitable starting point is a vague request to make an existing product intelligent without a defined input or action. The tools can explore model configurations, but they cannot decide which customer problem is worth solving. Nor does a prebuilt event label establish that the surrounding product meets a medical, safety or security requirement.

The Hailo blueprint offers another perspective on dedicated edge inference acceleration. The Arm blueprint explains the processor-IP layer underneath many embedded designs. Infineon’s relevant distinction here is the combination of model tooling and concrete integration routes into its own device ecosystem.

03 / WorkflowA proposed appliance sound feature begins with the microphone enclosure

Imagine a proposed laundry appliance that distinguishes its own end-of-cycle signal from unrelated sounds and displays a local notification. The first pilot is an assistive convenience feature. It does not identify a person, diagnose a fault or certify that a room is safe. That narrow scope makes it possible to compare model behavior against a straightforward product requirement.

Collect audio with the planned microphone and representative enclosure, rather than relying only on clean recordings from a laptop. Include television audio, speech, doors closing, neighboring appliances and the target signal at different distances. Keep quiet periods as well as difficult sound overlaps. The negative examples determine whether the notification becomes irritating during ordinary use.

Split the data by recording session and physical environment. If training and evaluation contain segments of the same recording, a model can appear robust while learning the room or background. Keep at least one unseen room configuration for the final check, and record the source of every positive label so disputed examples can be reviewed.

Use Studio to define the audio preprocessing and classification task, then inspect which errors remain after training. A confusion matrix can show common label swaps, but the product also needs an event-level view: how often does one real signal produce several notifications, and how often does a short background sound trigger a false event?

Build a small reference set containing the exact input windows around difficult events. Compare the generated model’s outputs against that set before changing the firmware. This gives the team a stable way to distinguish a modeling change from a microphone configuration or buffer-handling change. Retain the preprocessing parameters with the weights and generated code.

The PSOC deployment guide describes using a ModusToolbox example for the chosen board, replacing its model.c and model.h with generated files, building the project and flashing the device. It provides separate audio, motion and radar example routes. Use the example that matches the input modality and verify its sensor assumptions before adapting it to a custom enclosure.

After the model runs, integrate the notification rule. Require a defined amount of evidence over successive windows, decide how long a notification remains visible and provide a reset behavior. A classifier output is not yet a complete user interaction. The event logic should prevent one long tone from looking like repeated independent appliance events.

Measure execution with the display, wireless connection and other firmware functions enabled as they will be in production. Check buffer overruns, memory headroom and the effect of temporary processor load. Record the full time from a sound reaching the microphone to a stable notification. A desktop validation pass cannot establish those physical-device properties.

For a limited pilot, ask users to record missed and unnecessary notifications alongside relevant conditions. Avoid continuously retaining household audio merely because it is convenient for debugging; choose the minimum diagnostic information needed for the evaluation. Expand only when the feature remains useful outside the controlled demonstration environment and the team can reproduce its released behavior.

04 / PricingStudio’s published allowance has a hardware-specific production boundary

The allowance is measured in compute minutes on the service’s specified standard CPU instance, not audio minutes processed by a deployed appliance. Training consumption and on-device inference are different activities. A team should track training jobs and extra service requirements separately from the expected number of manufactured units.

Likewise, the free commercial deployment statement is tied to Infineon MCUs and NPUs. Do not infer unlimited production rights on another vendor’s processor from the broader permission to develop and evaluate models. Packaged Ready Models, separately supplied models and third-party components deserve their own agreement review rather than being silently folded into the Studio allowance.

For the acoustic pilot, the dominant early work may be obtaining representative recordings and integrating the microphone correctly. A free tool does not eliminate engineering cost. Set the initial budget around one working sensor path and a defensible evaluation set, then decide whether additional compute or expert assistance would resolve a demonstrated bottleneck.

05 / DistinctionsThe software spans both model work and the firmware handoff

Infineon’s approach makes the transition from modeling into an embedded project explicit. The generated files and board examples provide a handoff an ordinary firmware team can inspect. That is useful because many failures occur after training: mismatched sample rates, window sizes, scaling or label interpretation can change what a supposedly identical model actually sees.

The PSOC Edge software announcement also documents the expansion of Studio into computer vision alongside its existing time series work. This broadens the set of possible inputs, but it does not make their deployment requirements identical. An audio event feature and a camera detector should have separate resource and data plans.

Our assessment is that the strongest opportunity is a small feature whose behavior can be observed locally. If a project already has a well-trained network, the conversion route may be more direct than rebuilding its training process in Studio. If the team lacks a model but owns good data, Studio offers the more relevant starting point.

06 / QuestionsCheck the distinction between generated-code agreement and field performance

Can the same recorded inputs reproduce the same decisions after code generation?

This is a model-conversion question. Does the installed microphone produce equivalent inputs in a noisy enclosure? This is a system question. Keep separate evidence for each so that a successful desktop comparison is not misrepresented as a complete device validation.

Which target and software version does the deployment example support?

The current integration guide lists specific board workflows, and Model Converter describes its supported hardware scope. A general statement that models can be built for MCUs should not override a particular tool’s compatibility requirements.

How will the device behave when the sensor is blocked, disconnected or saturated?

Define a visible unavailable state and avoid interpreting an absence of valid input as a negative classification. These are proposed product acceptance checks, not documented failures in Infineon software. They make the feature easier to maintain after installation.

07 / DecisionChoose Infineon when the model is one part of an embedded feature

Infineon belongs in an AI-related shortlist through its embedded processors and DEEPCRAFT development offer. For the reader, its value is practical: a route from sensor data or an existing model to a firmware artifact with explicit commercial and hardware boundaries. This is an editorial inclusion based on that relevance, not a numerical ranking.

Start with one event, one representative sensor path and one target board. Move forward when the generated model and the full product agree on realistic inputs, the alert behavior is acceptable and production rights match the intended processor. That evidence is more useful than choosing a larger model before the acoustic problem is understood.