Writing Hardware Drivers in Simulink -- Good Idea?

Hey all, I was hoping to get some feedback on a design philosophy that may or may not be a good idea. For context, I'm an embedded software engineer who's new to Simulink but fairly experienced with writing hardware drivers in C/C++.

I've got a large new project at work (bare metal) that is taking a model based design approach and one engineer (very experienced with Simulink), is advocating strongly for writing the HW drivers in Simulink. I've messed around with embedded coder a little bit and see how that could be possible, but my question is: Is this a good idea?

The argument is that by doing everything in Simulink we can take full advantage of the analysis tools built into the product to increase our confidence level in the software correctness, which is actually a very important thing we need in this project. I like the idea of that, however I haven't seen many references elsewhere on the internet where this is done.

[Lorenz]

Hey @Brandon

we’re currently facing a very similar architectural decision in our company.

So far, our workflow has been based on generating C code from Simulink models and integrating it into a manually developed OS framework that also handles all hardware interfaces.

We are now considering a shift in architecture: moving hardware driver integration directly into Simulink to achieve a more unified, model-based workflow.

I’d be very interested to hear more about the path you chose:

• How did you integrate hardware drivers into Simulink (e.g., custom blocks, S-Functions, or other approaches)?
• What challenges or trade-offs did you encounter during the transition?

Any insights or lessons learned would be greatly appreciated.

Thanks in advance, and best regards,

Lorenz

[Brandon]

My company ultimately went the same route your company is currently on. Partially this was due to cost as it would take a very long time to recreate our existing vetted embedded infrastructure and we only have a few developers we could give licenses. Our system also requires dissimilarity, so we'd be multiplying that cost by 2x at a minimum.

I never ended up writing a full hardware driver in simulink. Instead I focused on what memory read/writes would look like (that is the fundamental building block of a driver after all) and quickly found it to be verbose, hard to reason about, and fundamentally unsuitable to our project constraints.

You could do it, but IMO it'd be extremely frustrating/time consuming. If you're doing it just to "unify the workflow", it's probably not the right choice. Simulink would shine if you need to take advantage of the unique test generating/verifying capabilities, but that's it's only real draw for low level development from my perspective.

Answer 1

[Yash]

Hi @Brandon, you can try going through these resources to take a call on writing hardware drivers in Simulink:

• Device Drivers: Integrating existing C (or C++) device driver functions into Simulink models by using the Legacy Code Tool. This will allow you to combine usage of C/C++ and Simulink.
• Simulink Device Drivers: Step-by-step guide and examples for developing Simulink Device Driver Blocks.
• Development of Hardware Driver for MATLAB/Simulink Real-Time Simulation: https://ieeexplore.ieee.org/document/5072832
• Writing A Simulink Device Driver Block: A Step by Step Guide: https://www.scribd.com/document/456195737/DriverGuide
• Device Driver Blocks: Specialized MATLAB System block that generates custom C/C++ device driver code when deployed to an ARM® Cortex®-A derived hardware board.

[Brandon]

Thanks for the links, these are informative.