{"id":6870,"date":"2016-04-29T09:00:37","date_gmt":"2016-04-29T13:00:37","guid":{"rendered":"https:\/\/blogs.mathworks.com\/pick\/?p=6870"},"modified":"2016-12-22T11:37:25","modified_gmt":"2016-12-22T16:37:25","slug":"device-drivers","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/pick\/2016\/04\/29\/device-drivers\/","title":{"rendered":"Device Drivers"},"content":{"rendered":"
\r\n \r\n\r\n

Richard is a Consultant at MathWorks focused on the Embedded Coder product for code generation, primarily in the Aerospace\r\n industry.<\/i><\/p>\r\n

Richard<\/a>'s pick this week is Device Drivers<\/a> by Giampiero Campa<\/a>.\r\n <\/p>\r\n <\/introduction>\r\n

Pick<\/a><\/h3>\r\n

My pick this week is Developing Simulink Device Driver Blocks: Step-by-Step Guide and Examples<\/a><\/b> .\r\n <\/p>\r\n

<\/p>\r\n

One of the many capabilities of Simulink is the ability to generate code for an embedded application. However, when hardware\r\n is involved, the complexity goes up exponentially. As with any embedded system, the core algorithm must interface with hardware\r\n components to be effective. These can range from simple I\/O, to complex sensors such as a GPS. In addition, there are myriad\r\n communication channels that can be used such as serial, A2D\/D2A, and other communication protocols (i.e. I2C). In all of\r\n these cases, there are some low-level hardware routines that provide a bridge between the hardware and the core algorithm\r\n - device drivers.\r\n <\/p>\r\n

That being said, the issue then becomes how do you call these low-level routines? One way would be to write all of the code\r\n by hand. This is not very efficient and not recommended. Another would be to write the base code for the application by-hand,\r\n including the interface to the hardware, and calling the algorithmic code produced via Simulink. In reality, this is an approach\r\n adobted by many users, particularly where it is a highly complex system with many aspects, with a limited number being generated\r\n from Simulink. However, for our case, we want to be able to generate code from our Simulink model and run it directly on\r\n our hardware, especially if we are using the Run on Target Hardware feature in Simulink rather than using one of the Coder\r\n products. To do this, we need a block in Simulink that will translate into a call to the appropriate device driver.\r\n <\/p>\r\n

That is where this post comes into play. This post walks you through the steps needed to create these device driver blocks.\r\n In particular, the post provides information on the various approaches that can be used such as S-Function blocks and MATLAB\r\n Function blocks, and the pros\/cons of each approach. The post provides examples for creating blocks for an Arduino board,\r\n but the approach is applicable to any board. This is supported by the number of additional posts that were inspired by this\r\n post for a wide range of boards and applications.\r\n <\/p>\r\n

Once a device driver block is created, the user can place it in a Simulink library for reuse. In this way, various device\r\n driver blocks can be packaged and shared for use in different applications. Many of the Target Support Packages leverage\r\n this capability.\r\n <\/p>\r\n

Comments<\/a><\/h3>\r\n

If you need to interface with hardware, this post can provide the necessary guidance to allow you to create a set of hardware\r\n specific blocks. Give it a try and let us know what you think here<\/a> or leave a comment<\/a> for Giampiero.\r\n <\/p>