TI CC2540 – Part II
A Bit About GAP and GATT
The entire BLE stack uses HAL to communicate with the hardware and the associated peripherals such as LED’s, LCD, and push buttons. The OSAL layer is the glue that lets different tasks and layers of software to interact with each other. The innards of the Bluetooth LE protocol is largely divided into two software layers:
GAP (Generic Access Profile)
GATT (Generic Attribute Profile)
The combination of those two layers implement the connectivity and the inter-device communication standards of the Bluetooth LE protocol. These two layers define what it is to be a bluetooth device, and by doing so, it ensures interoperability across various bluetooth-enabled devices that are built using the same specifications.
The CC2540 masks most of the underlying details of the link layer. The specifics of the wireless characteristics of bluetooth such as frequency hopping, secure pairing, and subsequent encryption process, are all implemented within a closed-source compiled library. This library is provided as a linkable binary only for IAR Workbench. And for this reason, the development for CC2540 is only possible with IAR Workbench. With open source code, it would have been possible port the software stack for other compilers such as SDCC.
Mind the GAP
The GAP layer defines specific set of roles each BLE device can assume. In the wireless device-to-device connection stage, each node can take one of the following roles (or profiles):
Without going too much into detail, it’s helpful to remember that the Observer/Central are the ones that will look for devices to connect to – they act as the master nodes in the pairing process. On the other hand, the Broadcaster/Peripheral node is the one that will sit there and advertise its existence, acting as the slave. The only difference to note among these profiles is that both Broadcaster and Observer are non-connectable.
Here are the major noteworthy API functions in the GAP layer.
The GATT layer sets up standards for data and inter-node communication flow between the nodes. It’s this layer that enables various bluetooth devices to share information with one another in a common “language”. Without this common language, devices manufactured by different vendors will speak their own langauges and will not be interoperable. The GATT specifications give definition and structure to both the data and functions each node in the connection can perform. Within this paradigm, any Bluetooth LE device can discover the identity and the functionality of any other Bluetooth LE devices.
Here are the commands necessary to start receiving data from the heartrate monitor GATT profile.
* discover characteristic by UUID
Characteristic UUID = 37:2A (from HEARTRATE_MEAS_UUID define below)
* heart rate sensor comes back with “10 11 00 37 2A”
– 10 : means notify only
– 11 00 (0×0011) : is the handle for characteristic value
– 37 2A (0x2A37) : is the UUID
* in order to enable notifications, client need to write 0×0001 to
server characteristic config descriptor. The handle for this
config descriptor immediately follows the characteristic value’s
handle. So in this case, it is: 0×0012
– chracteristic value handle : 0×0012
– enter into write text box : 01:00
– once the write succeeds, the heart rate is transmitted