Virtual Communication Port Driver for Embedded SPS Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
There is a need for a method and apparatus to provide an interface between application software and a satellite positioning system (SPS) sub-system embedded in location-enabled devices, as existing solutions assume the SPS control software runs on a separate processor, whereas in embedded systems, it executes on the same CPU as the application software, causing compatibility issues.
Innovation Solution
A location-enabled device with an SPS receiver, a hardware communication port, a CPU, and memory that stores program code including application software, SPS control software, and a driver to create a virtual communication port between the application software and the SPS control software, allowing seamless communication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the SPS receiver is embedded within a location-enabled device and shares the CPU with application software, then power consumption is reduced and device integration is improved, but compatibility issues arise because application software expects to communicate with SPS control software via a hardware communication port
Solution Approach 1:
A driver program is introduced as an intermediary component that runs on the CPU and provides a virtual communication port. This driver intercepts communication requests from application software intended for a hardware port and redirects them to the SPS control software, thereby mediating between the application layer and the embedded SPS subsystem. This resolves the compatibility issue while maintaining the integrated architecture.
Solution Approach 2:
The driver creates a virtual copy of the hardware communication port interface. Instead of requiring physical hardware separation, the driver replicates the communication protocol and interface behavior of a hardware port in software, allowing application software to interact with the embedded SPS receiver as if it were an external device connected via hardware port.
2Ease of manufacture
If application software is designed to communicate with external SPS receivers via hardware communication ports, then communication protocols are simplified, but the software cannot interface with embedded SPS systems running on the same CPU
Solution Approach 1:
The driver program provides a universal interface layer that handles multiple communication scenarios. It can route communication requests to either embedded SPS subsystems or external receivers depending on configuration, making the system adaptable to different deployment scenarios while maintaining a consistent software interface paradigm.
Data Source
AI summary
Method and apparatus for providing an interface between application software and an SPS sub-system embedded in a location-enabled device is described. In one example, the location-enabled device includes a satellite positioning system (SPS) receiver, a hardware communication port coupled to the SPS receiver, a central processing unit (CPU), and a memory. The memory stores program code for execution by the CPU. The program code includes application software, SPS control software, and a driver. The application software is configured to communicate using the hardware communication port. The SPS control software is configured to control the SPS receiver. The driver is configured to provide a virtual communication port between the application software and the SPS control software.