Diff: nordic/nrf-sdk/s110/ble.h

Revision:

56:a1071b629aa3

Parent:

37:c29c330d942c

--- a/nordic/nrf-sdk/s110/ble.h	Fri Jul 25 10:33:52 2014 +0100
+++ b/nordic/nrf-sdk/s110/ble.h	Tue Sep 02 15:50:05 2014 +0100
@@ -164,7 +164,7 @@
  */
 typedef struct
 {
-  ble_gatts_enable_params_t  gatts_enable_params; /**< GATTS init options @ref ble_gatts_enable_params_t. */  
+  ble_gatts_enable_params_t  gatts_enable_params; /**< GATTS init options @ref ble_gatts_enable_params_t. */
 } ble_enable_params_t;
 
 /** @} */
@@ -188,16 +188,16 @@
  * @param[in] p_dest Pointer to buffer to be filled in with an event, or NULL to retrieve the event length. This buffer <b>must be 4-byte aligned in memory</b>.
  * @param[in, out] p_len Pointer the length of the buffer, on return it is filled with the event length.
  *
- * @details This call allows the application to pull a BLE event from the BLE stack. The application is signalled that an event is 
+ * @details This call allows the application to pull a BLE event from the BLE stack. The application is signalled that an event is
  * available from the BLE Stack by the triggering of the SD_EVT_IRQn interrupt (mapped to IRQ 22).
  * The application is free to choose whether to call this function from thread mode (main context) or directly from the Interrupt Service Routine
  * that maps to SD_EVT_IRQn. In any case however, and because the BLE stack runs at a higher priority than the application, this function should be called
- * in a loop (until @ref NRF_ERROR_NOT_FOUND is returned) every time SD_EVT_IRQn is raised to ensure that all available events are pulled from the stack. 
+ * in a loop (until @ref NRF_ERROR_NOT_FOUND is returned) every time SD_EVT_IRQn is raised to ensure that all available events are pulled from the stack.
  * Failure to do so could potentially leave events in the internal queue without the application being aware of this fact.
  * Sizing the p_dest buffer is equally important, since the application needs to provide all the memory necessary for the event to be copied into
  * application memory. If the buffer provided is not large enough to fit the entire contents of the event, @ref NRF_ERROR_DATA_SIZE will be returned
  * and the application can then call again with a larger buffer size.
- * Please note that because of the variable length nature of some events, sizeof(ble_evt_t) will not always be large enough to fit certain events, 
+ * Please note that because of the variable length nature of some events, sizeof(ble_evt_t) will not always be large enough to fit certain events,
  * and so it is the application's responsability to provide an amount of memory large enough so that the relevant event is copied in full.
  * The application may "peek" the event length by providing p_dest as a NULL pointer and inspecting the value of *p_len upon return.
  *
@@ -219,7 +219,7 @@
  *          The application has two options to handle its own application transmission buffers:
  *          - Use a simple arithmetic calculation: at boot time the application should use this function
  *          to find out the total amount of buffers available to it and store it in a variable.
- *          Every time a packet that consumes an application buffer is sent using any of the 
+ *          Every time a packet that consumes an application buffer is sent using any of the
  *          exposed functions in this BLE API, the application should decrement that variable.
  *          Conversely, whenever a @ref BLE_EVT_TX_COMPLETE event is received by the application
  *          it should retrieve the count field in such event and add that number to the same
@@ -228,11 +228,11 @@
  *          application packets available in the BLE stack's internal buffers, and therefore
  *          it can know with certainty whether it is possible to send more data or it has to
  *          wait for a @ref BLE_EVT_TX_COMPLETE event before it proceeds.
- *          - Choose to simply not keep track of available buffers at all, and instead handle the 
- *          @ref BLE_ERROR_NO_TX_BUFFERS error by queueing the packet to be transmitted and 
+ *          - Choose to simply not keep track of available buffers at all, and instead handle the
+ *          @ref BLE_ERROR_NO_TX_BUFFERS error by queueing the packet to be transmitted and
  *          try again as soon as a @ref BLE_EVT_TX_COMPLETE event arrives.
  *
- *          The API functions that <b>may</b> consume an application buffer depending on 
+ *          The API functions that <b>may</b> consume an application buffer depending on
  *          the parameters supplied to them can be found below:
  *
  *          - @ref sd_ble_gattc_write (write witout response only)
@@ -253,15 +253,15 @@
  * @details This call enables the application to add a vendor specific UUID to the BLE stack's table,
  *          for later use all other modules and APIs. This then allows the application to use the shorter,
  *          24-bit @ref ble_uuid_t format when dealing with both 16-bit and 128-bit UUIDs without having to
- *          check for lengths and having split code paths. The way that this is accomplished is by extending the 
- *          grouping mechanism that the Bluetooth SIG standard base UUID uses for all other 128-bit UUIDs. The 
- *          type field in the @ref ble_uuid_t structure is an index (relative to @ref BLE_UUID_TYPE_VENDOR_BEGIN) 
- *          to the table populated by multiple calls to this function, and the uuid field in the same structure 
- *          contains the 2 bytes at indices 12 and 13. The number of possible 128-bit UUIDs available to the 
- *          application is therefore the number of Vendor Specific UUIDs added with the help of this function times 65536, 
+ *          check for lengths and having split code paths. The way that this is accomplished is by extending the
+ *          grouping mechanism that the Bluetooth SIG standard base UUID uses for all other 128-bit UUIDs. The
+ *          type field in the @ref ble_uuid_t structure is an index (relative to @ref BLE_UUID_TYPE_VENDOR_BEGIN)
+ *          to the table populated by multiple calls to this function, and the uuid field in the same structure
+ *          contains the 2 bytes at indices 12 and 13. The number of possible 128-bit UUIDs available to the
+ *          application is therefore the number of Vendor Specific UUIDs added with the help of this function times 65536,
  *          although restricted to modifying bytes 12 and 13 for each of the entries in the supplied array.
  *
- * @note Bytes 12 and 13 of the provided UUID will not be used internally, since those are always replaced by 
+ * @note Bytes 12 and 13 of the provided UUID will not be used internally, since those are always replaced by
  * the 16-bit uuid field in @ref ble_uuid_t.
  *
  *
@@ -278,11 +278,11 @@
 
 
 /** @brief Decode little endian raw UUID bytes (16-bit or 128-bit) into a 24 bit @ref ble_uuid_t structure.
- * 
- * @details The raw UUID bytes excluding bytes 12 and 13 (i.e. bytes 0-11 and 14-15) of p_uuid_le are compared 
- * to the corresponding ones in each entry of the table of vendor specific UUIDs pouplated with @ref sd_ble_uuid_vs_add 
- * to look for a match. If there is such a match, bytes 12 and 13 are returned as p_uuid->uuid and the index 
- * relative to @ref BLE_UUID_TYPE_VENDOR_BEGIN as p_uuid->type. 
+ *
+ * @details The raw UUID bytes excluding bytes 12 and 13 (i.e. bytes 0-11 and 14-15) of p_uuid_le are compared
+ * to the corresponding ones in each entry of the table of vendor specific UUIDs pouplated with @ref sd_ble_uuid_vs_add
+ * to look for a match. If there is such a match, bytes 12 and 13 are returned as p_uuid->uuid and the index
+ * relative to @ref BLE_UUID_TYPE_VENDOR_BEGIN as p_uuid->type.
  *
  * @note If the UUID length supplied is 2, then the type set by this call will always be @ref BLE_UUID_TYPE_BLE.
  *
@@ -294,7 +294,7 @@
  * @return @ref NRF_ERROR_INVALID_ADDR Invalid pointer supplied.
  * @return @ref NRF_ERROR_INVALID_LENGTH Invalid UUID length.
  * @return @ref NRF_ERROR_NOT_FOUND For a 128-bit UUID, no match in the populated table of UUIDs.
- */                                                 
+ */
 SVCALL(SD_BLE_UUID_DECODE, uint32_t, sd_ble_uuid_decode(uint8_t uuid_le_len, uint8_t const * const p_uuid_le, ble_uuid_t * const p_uuid));