Link zum Forum

Support finden Sie jederzeit in unserem Forum.

Aktuelle Beiträge

Windows IoT Meets FreeRTOS: Real Time CAN Communication on the i.MX93

For our own board based on the NXP i.MX93, running Windows IoT LTSC 11, we rely consistently on the official NXP BSP. It is proven, well maintained, and covers most interfaces reliably. But for the CAN interface, we reached a point where the supplied driver no longer met our requirements. As soon as packet rates increased and the application processor was under heavy load at the same time, performance dropped noticeably. It was the fact that the entire communication ran through the application processor and its Windows scheduler. Under load, when other applications, I/O, and background processes compete for CPU time, a non real time operating system is inherently at a disadvantage for time critical bus protocols.

The idea: process CAN where real time belongs

Our answer was to move the entire CAN processing to the previously unused Cortex M33. A FreeRTOS program we developed runs there and drives the FlexCAN controller directly, with a fixed, high interrupt priority, fully decoupled from the Windows scheduler and its load. A core that previously had no function at all now handles exactly the task it is best suited for: deterministic real time response to bus events.

How the two worlds work together

To let the M33 communicate with the Windows side, we use two mechanisms the i.MX93 provides for exactly this purpose:

• The Messaging Unit (MU1) as a hardware interrupt channel between the cores. No polling, just genuine event driven notification in both directions.
• A shared memory region with two lock free ring buffers, one per direction, used to exchange CAN frames as a compact 20 byte structure. The buffers are designed so that the write and read indices are each modified by only one side, a deliberately simple and robust design that avoids the need for additional locking.

On the FreeRTOS side, this is handled by dedicated, clearly separated tasks. A receive task passes frames from the FlexCAN interrupt routine through an internal queue into the shared memory ring and triggers an interrupt on the Windows side through the MU registers. A transmit task, in turn, is woken by an MU interrupt as soon as Windows has placed a frame on the bus. A third task continuously monitors the connection status along with counters for sent, received, and faulty frames, so the state of the bridge is observable at all times.

On the A55 side we developed our own KMDF driver, canmu.sys, which maps the MU registers and the shared memory region and exposes a simple IOCTL interface to the application layer for sending frames, receiving frames, and querying status. Anyone who wants to use CAN on our board never has to deal with the complexity of the core to core communication underneath. They simply talk to the driver through DeviceIoControl, exactly as our own test application, CanTestAPI, demonstrates.

The result

With this architecture we specifically addressed the weaknesses of the original solution:

• Stable performance even under high system load, because time critical bus processing is now fully decoupled from the Windows scheduler.
• Deterministic, real time capable behavior, since FreeRTOS on the M33 runs with a fixed interrupt priority and without competing for CPU time with other Windows processes.
• Optimal use of existing hardware, since a processor core that was previously unused now makes a real functional contribution, without any additional components.
• A simple, stable interface for application development that fully encapsulates the underlying complexity.

The real highlight: two worlds, one seamless system

What makes this solution stand out for us is not just that we moved CAN processing onto the M33. It is that the entire result stays fully connected to and controllable from Windows IoT. A real time operating system and a general purpose operating system are fundamentally different worlds, with different scheduling models, different guarantees, and different ways of thinking about time. Bringing them together so closely that an application developer on the Windows side simply calls DeviceIoControl and never has to think about FreeRTOS, interrupt priorities, or shared memory ring buffers at all is exactly the kind of integration we have extensive experience in. FreeRTOS delivers the real time guarantees the bus needs, and Windows IoT still remains the single point of access for every application built on top of it.