Microchip Just Made Its ML Toolchain Free — Here's Whether It Can Actually Run on Your BLE MCU
Your boss forwards you the announcement: Microchip’s ML tooling is free now. You’re already shipping on a WBZ451, you’ve got the Curiosity board on your desk, and the question in your head isn’t “should we do TinyML someday.” It’s narrower and more useful: can this thing produce inference that actually fits on the part I’m already using, after the BLE stack has taken its cut?
The real question is whether the now-free MPLAB machine learning suite gives you working on-device inference on a BLE-constrained MCU without adding a new vendor to your pipeline or blowing your memory budget.
Assume you know C, you know your flash and RAM numbers, and you’ve seen Edge Impulse and TFLite Micro. Let’s get to the constraints.
What “free” actually includes
The core is the MPLAB Machine Learning Development Suite, which slots into MPLAB X as a plugin. Microchip acquired this from Motion Gestures and Cartesiam and rolled it into the toolchain. As of the current licensing terms (verify against Microchip’s licensing page as of February 2025), the model-generation and code-export flow is free to use, with no per-model fee and no runtime royalty on the generated C.
That last part matters. A free model builder that charges you per deployment is not really free. Confirm the generated inference code ships royalty-free under Microchip’s terms before you commit to it in a BOM.
Here’s the string that’s easy to miss: the generated C still compiles through XC32, and XC32’s optimization tiers are separate. The free XC32 tier compiles fine, but the higher optimization levels (-O2, -O3) sit behind a paid license. Your model will build and run on the free compiler. It may run bigger and slower than the benchmark numbers Microchip quotes, because those often assume full optimization.
The “free ML compiler embedded” label is accurate for the model generation. The compiler that turns it into a binary has a tier system you probably already know about. Check which XC32 tier your license covers before you benchmark anything.
The constraint that matters: memory after BLE
The WBZ451 gives you roughly 1 MB flash and 256 KB RAM on the PIC32CX-BZ2 core (verify exact figures against the PIC32CX-BZ2 datasheet as of February 2025). That sounds generous until the BLE stack shows up.
Microchip’s Harmony BLE stack plus the RTOS and your application logic tends to eat a large slice of both. The stack alone wants 80 to 120 KB RAM once you count connection buffers. The flash cost with app code lands in the 400 to 600 KB zone. These are ballpark figures from Harmony BLE reference projects. Confirm against your own build map file, because your connection count and feature set move them a lot.
What’s left is your real envelope for TinyML on microcontrollers:
WBZ451 memory budget (approx, illustrative, verify Feb 2025)
┌─────────────────────────────────────────┐
│ Flash ~1 MB │
│ ├─ BLE stack + app ~400-600 KB │
│ ├─ ML runtime + model ~20-100 KB │
│ └─ headroom remainder │
├─────────────────────────────────────────┤
│ RAM ~256 KB │
│ ├─ BLE stack ~80-120 KB │
│ ├─ ML tensor arena ~5-30 KB │
│ └─ app + stack remainder │
└─────────────────────────────────────────┘The number to watch is the tensor arena in RAM. That’s the scratch buffer inference runs in, and it’s the thing that collides with your BLE connection buffers. A small motion classifier lives happily in 5 to 15 KB of arena. Push toward audio and you’re looking at 30 KB or more once the feature window and FFT buffers stack up. At that point you’re negotiating with the stack for room.
Flash is the easier side. A generated model plus runtime in the 20 to 100 KB range fits comfortably in the headroom on a 1 MB part. RAM is where edge AI BLE projects actually die. If your arena estimate plus your BLE stack plus your app stack exceeds 256 KB, no amount of flash saves you.
Read the arena estimate the plugin gives you and subtract it from what your linker map says is free. That single subtraction tells you most of what you need to know.
The hands-on path
Board on the desk, here’s the actual flow. This is decision-level detail, not a click-by-click tutorial.
[ Sensor data ] -> [ ML plugin: train/generate ]
-> [ Generated C model ]
-> [ MPLAB project + BLE stack ]
-> [ Flash to WBZ451 ] -> [ Inference @ runtime ]1. Install the plugin. In MPLAB X, add the Machine Learning Development Suite through Tools > Plugins. It pulls in the model builder UI. No separate IDE, which is the whole point of staying in the Microchip pipeline.
2. Point it at data. You can feed it CSV sensor captures or stream from the onboard sensors on the Curiosity board. The friction here is format: the plugin wants labeled, windowed time-series with a consistent sample rate. If your accelerometer logs are ragged or you’ve got mixed sample rates, you’ll spend more time cleaning data than training. Budget for that.
3. Generate and read the readout. After training you get an accuracy number and, more importantly, a size estimate: flash for the model, RAM for the arena. This is your go/no-go. If the arena estimate is 40 KB and you’ve got 30 KB free after BLE, stop here. You’ve saved yourself the afternoon.
4. Integrate the generated C. The plugin exports a C library you drop into a Harmony/MCC project. It links as a normal source module with an init call and an inference call. The conflict to watch is the linker script: the generated model may want a specific memory section, and your BLE stack build already claims regions. If you see a link error about overlapping sections, that’s the collision. You resolve it in the linker file, which is annoying but not hard.
5. Flash and read output. Push it over the programmer, then read inference results over UART for the first pass because it’s simpler to debug. Once it works, wire the classification result into a BLE characteristic and send it up. If you’re pushing results off-device, Hubble’s cloud integration guide for getting device data covers the backend side of moving those inferences somewhere useful.
The honest friction summary: data prep and the linker section conflict are where you’ll lose time. The plugin itself is fine.
What runs, what doesn’t
The neutral verdict by model class, tied straight back to that RAM envelope.
Model class | Verdict on WBZ451
-----------------------|------------------
Motion classification | Runs well
Vibration / anomaly | Runs well
Keyword spotting | Borderline
Vision | Don't botherMotion classification from accelerometer and gyro data is the sweet spot. Gesture recognition, activity detection, orientation states. These models are small, the feature windows are short, and the arena stays under 15 KB. It’s what the underlying tech was built for, and it shows.
Vibration anomaly detection and simple regression run just as well. Bearing fault detection, motor health, a threshold model on a sensor trend. Small input, small model, small arena.
Keyword spotting is borderline and depends entirely on your window length and feature extraction. A one or two word wake-phrase might squeeze in if you keep the audio window tight, but you’re fighting the arena against the BLE stack the whole way. Test it before you promise it.
Vision is a no. Any real image model wants flash and arena you don’t have after BLE. Don’t burn the afternoon.
The pattern is simple: if your input is a short window of low-rate sensor data, it runs. If it’s a wide window of high-rate audio or pixels, the arena eats your RAM and the BLE stack has nowhere to live.
When to use something else
Two cases where you should look past the Microchip tooling.
Edge Impulse if you want a polished data pipeline with proper DSP blocks, versioned datasets, and portability across MCU vendors. If there’s any chance you’ll ship the same model on a non-Microchip part later, the portability alone is worth the extra pipeline.
Bare TFLite Micro if you want full control and zero vendor coupling, and you’re willing to hand-manage the runtime, the ops, and the arena sizing yourself. More manual work, but nothing sits between you and the metal.
The Microchip suite wins on exactly one axis: you’re already in MPLAB and you don’t want another tool in the pipeline. That’s a real advantage, just be honest that it’s the advantage you’re buying.
Making the call in one afternoon
Direct answer: if you’re already Microchip-native and your use case is motion or vibration classification, it’s worth the afternoon. The workflow is decent, the code integrates cleanly enough, and staying in MPLAB is a genuine saving.
Do this before you start. Confirm your XC32 compiler tier, because the free tier changes your size and speed numbers. Then generate a throwaway model and read the arena estimate against your actual linker map file with the BLE stack in place. That one subtraction, arena versus free RAM, decides it.
Skip it if you’re doing audio at any real fidelity, if you need multi-vendor portability, or if you’re not already invested in Microchip’s toolchain. In those cases the switching cost isn’t worth what “free” saves you.
Note for CMS team: two internal-link slots left open per brief. A TinyML fundamentals pillar link belongs in the intro, and an Edge Impulse walkthrough link belongs in Section 5 if one exists. Do not guess URLs. All memory figures flagged “verify Feb 2025” need confirmation against the current PIC32CX-BZ2 datasheet and Harmony BLE footprint docs before publish. Confirm the “free” and royalty-free scope against Microchip’s current licensing page, since it’s the headline claim.
Hubble Network brings BLE connectivity to your devices at satellite scale—no gateways, no extra infrastructure. See how it works →