The Broadcom GNSS software is embedded into a customer's processor to complete the GNSS solution. The software is designed to be simple and easy to integrate, yet extensible for the most complex applications.
The figure below illustrates the high level architecture of the Host-based GNSS positioning solution. The minimum configuration of glgps executable (usually as a user mode process) consists of main.c, glhal.lib, glct.lib, and gll.lib.
A UART is the de facto serial interface to the GNSS chipset. It is essential to have full hardware flow control UART with TX, RX, CTS, and RTS lines for glgps to work reliably. Some chipsets additionally support I2C or SPI, or both. Serial interfaces are mutually exclusive, that is, the target platform can only utilize UART, I2C, or SPI. Note that additional bring-up effort on glhal is required for I2C or SPI.
Target platform maker is responsible for providing Broadcom GPIO device driver to control the REGPU or nSTANDBY pin on the GNSS chipset. This enables reliable host interface reset and power savings.
The dotted components are optional. These components such as SUPL, HULA, LBS, etc. can be configured per project requirements. Each one of these components are described in greater details in subsections within this document.
Windows glhal source code is not available for historical reasons.
For a quick start on running the SDK with the Evaluation Kit, see Documentation for Evaluation Kit Users.
The figure below illustrates the top level architecture of the GNSS software in greater details. The core of the software is the GNSS Controller (GLCT). This is a collection of software routines that encapsulate the core GNSS functionality in a way that is adaptable to all platforms.
In order to achieve portability, GLCT does not interface directly with the hardware, nor does it make any use of operating system calls or other platform dependent features. These implementations reside in a platform specific Hardware Abstraction Layer (HAL) which is developed by the customer for his or her own platform. Broadcom provides HAL layers for four different environments: (1) a PC running Windows; (2) a PC running Linux/Cygwin; (3) a Broadcom embedded system utilizing ARM7 and no operating system; and (4) a Macintosh running Mac OS X. These examples provide a starting point to illustrate how platform specifics are accomplished in a wide range of platforms.
The HAL functionality can be divided to three categories. First, as illustrated near the top of the figure, the HAL needs to include a wait-for-event function. This function is called by the GLCT. The function needs to suspend until there is action to perform, and then, when an event occurs return the event to the GLCT. The events to wait for include a timer event, an event indicating incoming data from the GNSS chip, and events indicating application-specific requests. The implementation of the the wait-for-event will vary greatly according to the platform and operating system.
The second HAL functionality consists of callback functions used by the GLCT to interact with hardware. Examples of functions in this layer include a callback function to assert GPIO and a callback function to transmit serial data to the GNSS chip.
The third HAL functionality is callback functions used by the GLCT to respond back to applications with GNSS positioning results. This functionality is platform specific because in general it involves interprocess communications with applications that run in separate threads.
While HAL serves the abstraction of hardware, Application Request Processors (ARPs) serves the abstraction of applications. ARP consists of start-time registration of application modules.
The GLCT is passed an XML configuration file. This file contains settings for the GNSS software, platform specific settings for the HAL, and general purpose configuration fields that can be passed on to applications through the ARP interface.
Another purpose of the XML configuration file is to specify jobs that are carried out by the batch request manager. Broadcom supplies XML configuration files with jobs for the standard tests used in the industry to verify GNSS performance. Thus, once the GLCT is up and running in a new platform it is quick and easy to perform a standard set of functional tests. Customers will find the XML configuration files easy to understand and modify for their own testing needs.
Programming interfaces to the GLCT are described in the GPS Library Control Task (GLCT) Interface
Your GL SW distribution contains the following directories: