Drivers, System Software & Real-Time Platforms

What does driver and system-software work cover?

Cross-platform driver development for industrial devices covers middleware and the operating systems that host them.

That means driver development on both sides of the kernel boundary, the packet or transfer path beneath a protocol stack, the scheduler and interrupt behaviour that sets jitter, and the middleware above it. A typical real-time Linux optimisation we deliver runs an 80 µs network cycle at 20 µs jitter with a custom NIC driver. The engagement is usually one of these shapes:

• A Windows driver. NDIS miniport driver development where the device is the adapter, an intermediate driver where it has to sit over one, or a kernel-mode driver for a device that is not a network adapter.
• A Linux kernel driver. Linux kernel network driver development, or device and platform drivers across bulk, serial, network and hybrid FPGA-attached hardware.
• Real-time tuning and validation. Real-time platform tuning and validation, measured under load, with the configuration and the numbers handed over together.
• An RTOS port. FreeRTOS driver porting, eCos RTOS development, Zephyr, micro-C/OS or SYS/BIOS TI-RTOS work, usually after a platform migration.
• A platform migration. Windows IoT Enterprise LTSC migration for a machine builder whose release is out of support.
• Redundancy. High-availability industrial control redundancy, where the requirement is that a node failure is survivable, not merely detected.

The distinction between a typical embedded systems scope and this one is that embedded systems covers the software running on the device’s own silicon, while this service includes the software the host runs to talk to it. Many products need both, and the same engineers often do both, but they are separate disciplines with separate development and failure modes.

Can Windows hold a real-time deadline?

Windows does not hold a deadline in the way the question usually means, and a qualified answer is more useful.

Windows runs a 15.6 ms tick by default and can be configured down to 1 ms. That is timer resolution, not cycle time, and the two are different quantities. For a worked example, openPOWERLINK’s Windows-only platform documents an achievable cycle above 10 ms for a pure-software stack. That 10 ms is not a floor imposed by the timer. It follows from network size and PDO configuration:

So it is a design-input dependent criterion, not a fixed limit.

This is fixed with a hybrid architecture, where the communication controller moves out of Windows entirely onto bare-metal silicon, in this case an FPGA running a soft processor, and Windows samples network data at 1 ms to 5 ms depending on network size while determinism stays in hardware. Extending the same openPOWERLINK example, the Windows platform reaches 250 µs with an external PCIe-based NDIS miniport solution against above 10 ms in pure software. This is a result from an open-source implementation, with published numbers, cited here as confirmation of the architecture.

Which NDIS driver class should my network device use?

It depends on whether the adapter is dedicated or shared, and the two classes trade determinism against flexibility.

• A miniport driver manages the physical adapter directly. It is preferred when the requirement is dedicated real-time performance, because every additional layer in the path is another queue that can hold your frame.
• An intermediate driver is a protocol driver on its upper edge and a virtual miniport on its lower, sitting over a real miniport, which is how several applications can share one adapter. That sharing is the right choice when the requirement is virtualisation.

We deliver both classes.

What does a Windows platform migration involve?

A Windows platform migration is mostly planning the lockdown rebuild, not porting the application.

A machine builder still shipping on a Windows IoT release that Microsoft discontinued typically has that platform because it still works, but it does not receive security updates, and it may fail a customer’s procurement review. A planned phase-out means migrating to Windows IoT Enterprise LTSC, where the dates are the selling point: the 2021 release is supported to 2032 and the 2024 release to 2034. The primary migration target is rarely the application. It is the lockdown configuration that made the old machine behave like an appliance, covering Unified Write Filter, Shell Launcher, Assigned Access, Keyboard Filter, Device Guard and Credential Guard, plus drive encryption where the device holds customer data. That configuration is rebuilt against the new release.

How does real-time Linux differ from Windows?

The difference is architectural: Windows queues deferred work and preempts by priority, while real-time Linux shortens its non-preemptible sections.

On Windows the determinism-critical behaviour (the packet path for both is drawn under What does driver and system-software work cover?) lives in deferred procedure call and interrupt-level queuing, and in how a priority thread is allowed to preempt. Real-time Linux attacks the same problem by shortening the kernel’s non-preemptible critical sections, so what improves is worst-case latency under load; average throughput can be slightly lower as a result. Our measured jitter on a tuned real-time platform is under 20 µs under load, and the OSADL QA farm’s continuous testing under timer, memory, network and filesystem stress is the public corroboration for that class of result. The two directions of the data path are optimised differently. On the receive side, optimisation means moving to a zero-copy mechanism such as AF_XDP, or to poll mode such as DPDK where the hardware or the OS does not support it, trading optimisation against portability. On the transmit side three mechanisms are in current use: launch time on Intel i210 and i225 parts, time-based scheduling as IEEE 802.1Qbv standardised it, and the Linux ETF and taprio queueing disciplines that drive it. The determinism engineering above that layer, covering gate schedules, benchmarking and hop-by-hop verification, is covered on real-time Ethernet.

What is involved in porting a driver to an RTOS?

The same OS driver challenges are solved against a vendor HAL instead of a kernel driver model.

The core device-control logic reuses well. Four things do not carry over:

1. The memory model becomes static instead of dynamic.
2. Interrupt handling becomes chip-specific.
3. DMA descriptor handling is rewritten against the HAL.
4. A change requires a full rebuild and reboot, where a kernel module could have been reloaded live.

The trade is even. There is no kernel-version compatibility churn to track, which is a real saving over a product’s life, and there is vendor HAL lock-in instead, which is a real cost.