Extensible Auxiliary Display Architecture for Hardware Customization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Device manufacturers face challenges in customizing hardware to function as full-featured auxiliary displays while also adding desired functionalities, as existing methods require extensive code integration with existing firmware, making it difficult to differentiate their devices.
Innovation Solution
A computing architecture with layered code structure, including a hardware abstraction layer (HAL) and a common language runtime (CLR), allows device manufacturers to extend and customize hardware components with minimal firmware changes, enabling reuse of existing software and providing an extensible mechanism for communication between device software and the main computer system.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If device manufacturers customize hardware to add desired functionalities, then device versatility and differentiation are improved, but device complexity and firmware integration effort increase
Solution Approach 1:
The firmware is segmented into a framework portion and a manufacturer extension portion. The framework provides core auxiliary display functionality, while the extension portion allows manufacturers to add custom functionalities (GPS, audio, messaging) without modifying the core framework. This segmentation enables independent development and integration of custom features.
Solution Approach 2:
The framework is designed to be universal and support multiple types of auxiliary devices with different functionalities. It provides a common infrastructure that can accommodate various hardware configurations (display-only, GPS-enabled, audio-capable, messaging-enabled) through a standardized interface and event-driven architecture.
2Adaptability or versatility
If manufacturers write extensive code to integrate hardware with existing firmware, then device functionality is achieved, but development time and effort increase
Solution Approach 1:
The framework portion is pre-configured with all necessary infrastructure for auxiliary display functionality, including event handling, communication protocols, and hardware abstraction layers. Manufacturers only need to add their specific functionality on top of this prepared foundation, rather than building everything from scratch.
Solution Approach 2:
The framework acts as an intermediary layer between the manufacturer's custom code and the underlying hardware/platform. It provides standardized interfaces and abstractions that simplify integration, allowing manufacturers to write less code while achieving full functionality.
3Reliability
If a standardized firmware is used across different devices, then consistency and quality are improved, but device customization and differentiation are limited
Solution Approach 1:
The firmware is divided into a standardized framework portion that ensures quality consistency and a customizable extension portion that enables device differentiation. The framework handles core functionality uniformly across all devices, while extensions allow each device type to have unique features.
Solution Approach 2:
Different parts of the firmware have different levels of standardization. The framework portion maintains high standardization for reliability, while the extension portion allows local customization for each device type. This enables quality consistency in core functions while allowing differentiation in manufacturer-specific features.
Data Source
AI summary
Described is a system and method by which an auxiliary computing device having an auxiliary display platform that displays information corresponding to data that originated on the main computer system may be extended by a device manufacturer. Extended hardware is added to the device, such as a radio receiver and/or an audio decoder. The auxiliary display platform is layered and extensible at each layer, and includes an extensible hardware abstraction layer that is extensible to support extended hardware if needed, and a driver layer that is extensible by adding driver code for the extended hardware. A runtime layer is also extensible to support the extended hardware as needed, as are libraries, the auxiliary shell program and other managed code. The client API is also extensible to allow applications on the main computer system to communicate with extended hardware via the device runtime layer.