Why All Device Drivers/Modules are Not Created Equally
A driver or module is a critical component in the effectiveness of any programmer and the efficiency of any integrated system. As in the world of computing, drivers and modules are an essential part of connecting software to hardware.
Simply put, drivers provide easy access to hardware functions without needing to know the precise details of the equipment on the other end. For example, when a software application invokes a hardware based function such as “print,” the application is not talking directly to a specific printer make and model. Instead, it relies on a driver issuing commands to the printer and processing data received from the printer to successfully carry out a print function. The same is true for other peripherals like cameras, scanners, sound cards, etc. The ability to interface different manufacturers’ products using a common set of functions relies on drivers to translate the generic commands into the specific language or API of the device.
Applying this model to the world of AV control and system programming, drivers (also known as modules or plugins depending on the nomenclature used by different control system manufacturers) are used by programmers to easily integrate third party manufacturers’ equipment, such as audio DSPs, video CODECs, displays, switchers, shades, lighting, and more, without having to navigate through the complex details of their API. The availability of device drivers provides significant benefit to the productivity of a programmer, efficiency of a project, cost savings for client, marketability of a device, and peace of mind for a manufacturer knowing that their product will work as expected and be able to be seamlessly and easily integrated.
It is important to note that all drivers for AV devices are not created equally. Some are purpose-built only providing a subset of features to solve a specific need. Others are more comprehensive intended to be used by programmers to serve a variety of needs and applications from project to project. Typically, support for the entire range of API functions would not be required. However, a fully-featured driver would contain the bulk of functions needed to address a vast majority of product applications.
In addition to the features and functionality provided, device operation and driver design can vary significantly from developer to developer or platform to platform. While there are best practices or guidelines for design and development of device drivers established by the control system manufacturers, they are loosely adhered to and differ amongst control platforms making it a challenge for product manufacturers to ensure consistency in device operation, client satisfaction, and support requirements.
Rather than leaving a product’s destiny up to chance and relying on drivers to be developed by unfamiliar parties who may not share the same vision and standards, it is important for product manufacturers to incorporate drivers into their go-to-market strategy.
Third party device manufacturers who work with a single software developer for all their driver needs across various platforms not only have control over the requirements of the deliverable and have a single point for support, but can also overcome the challenges of having their device perform differently with different control platforms.
Another differentiator for drivers is their architecture. While it seems logical to develop one comprehensive, monolithic driver per device, there are important benefits to a component model offering a collection of functionality-specific drivers that can be mix and matched to meet the desired needs of the project. While monolithic drivers provide an all-in-one solution, the component model provides flexibility in design, supports the ability to easily add and subtract pieces for scalability, avoids large the overhead of unused or unnecessary functionality, and provides driver developers the ability to add, modify, isolate, or troubleshoot parts without having to change the entire driver.
Control Concepts has developed a proven approach to driver, or module, development that can be adapted to any product type and complexity. Included in this solution is a software structure that offers features like a heartbeat for active communication status, debug tools, configurable parameter fields that provide the ability to make adjustments without recompiling, dynamic enabling and disabling of components, device status on a subscription or polling basis, and support for secure communications where needed.
We are glad to share further details about our approach to driver development or how we help solve a need. Please reach out to projects@controlconcepts.net.
