MoreRSS

site iconDaniel MangumModify

I am a principal software engineer at Upbound.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of Daniel Mangum

How AI on Microcontrollers Actually Works: Registering Operators

2025-07-14 15:41:34

We started this series with a look at operators and kernels, the “instructions” used by models and the implementation of those instructions on the available hardware. We then explored the computation graph, which defines the sequence of operators for a given model, and explored how different model formats opt to include the explicit computation graph in the distributed file, or defer it to the inference application. With tflite-micro and the .

How AI on Microcontrollers Actually Works: The Computation Graph

2025-07-07 15:41:34

In our last post we explored operators and kernels in Tensorflow Lite, and how the ability to swap out kernels depending on the hardware capabilities available can lead to dramatic performance improvements when performing inference. We made an analogy of operators to instruction set architectures (ISAs), and kernels to the hardware implementation of instructions in a processor. Just like in traditional computer programs, the sequence of instructions in a model needs to be encoded and distributed in some type of file, such as an Executable and Linkable Format (ELF) on Unix-based systems or Portable Executable (PE) on Windows.

How AI on Microcontrollers Actually Works: Operators and Kernels

2025-06-30 15:41:34

The buzz around “edge AI”, which means something slightly different to almost everyone you talk to, is well past reaching a fever pitch. Regardless of what edge AI means to you, the one commonality is typically that the hardware on which inference is being performed is constrained in one or more dimensions, whether it be compute, memory, or network bandwidth. Perhaps the most constrained of these platforms are microcontrollers. I have found that, while there is much discourse around “running AI” (i.

Just Barely Fitting a Full Wi-Fi Stack on the nRF9151

2025-02-17 15:41:34

In my last post on the Nordic Semiconductor Thingy:91 X IoT prototyping platform, I outlined the features and architecture of the device. The combination of wireless protocols on the Thingy:91 X (Bluetooth LE, LTE-M, Wi-Fi) make it a compelling foundation for a wide variety of applications. However, there are a few intricacies to the protocol support. Namely, the primary stated purpose of the Wi-Fi support is for network-based positioning (i.e. scan for local access points, send them to a server, get approximate location back).

Accessing the Qualcomm Modem over USB on the RAK5010

2025-01-30 15:41:34

I have recently been working with the RAKwireless RAK5010 development board. It includes the popular Nordic nRF52840 MCU for running applications on its Cortex-M4 CPU that can leverage the integrated 2.4 GHz multiprotocol support, as well as the LTE and GNSS support offered by the on-board Quectel BG95-M3 module. The micro-USB port on the board is connected to USB on the nRF52840, which allows for viewing serial output, but is not a mechanism for flashing new firmware.

VPR: Arm and RISC-V Inter-Processor Communication

2024-12-31 15:41:34

In our last post, we explored the Nordic VPR RISC-V processor through the lens of the peripheral processor (PPR) on the nRF54H20. While we demonstrated how the application processor can configure and start a VPR processor, we stopped short of demonstrating any further communication between them. Most meaningful use-cases of the PPR and the FLPR, involve communicating with the controlling processor. Nordic uses two different hardware peripherals for inter-processor communication (IPC) on the nRF54H20: VEVIF (VPR Event Interface) and BELLBOARD.