I am trying to keep everything synchronous between the client and peripheral. I am also try to make the peripheral code itself synchronous. So on the nRF51 DK, I use a button press to start advertising and then I enter the main loop which I have modified from the example code. The main loop calls the sd_app_evt_wait() method and when an app event happens it loops through the sd_ble_evt_get() method to get the event, and calls the ble_evt_dispatch() method to handle the event.
The peripheral code then goes through connection, pairing/encryption, and getting two descriptors enabled. It then handles writes from the central. These writes consist of commands such as get config data, send stored data, etc, and then finally send any live data. Since the data being sent is much longer than what can fit in a characteristic, the data string is fragmented and sent in hunks. There are no semaphores here so when the send stored data command is received, the peripheral creates the data to be sent, sets a flag saying 'notify data' and returns. This brings one back to the main loop. After the return from the ble_evt_dispatch() method, a call to a send_data() method that does the sd_ble_gatts_hvx(). Since the flag is set, notifications are sent until the TX buffers are exhausted at which time we need to wait for the TX buffer event. So the main loop goes back to the sd_app_evt_wait() and waits for the TX event, etc.
This successfully does all the spin up and sending of stored data synchronously, but now I want to send live data and my app is waiting on the sd_app_evt_wait(). In the real production device, that 'live' data will arrive over a UART event. On the DK, I cannot use that so I use a periodic timer to 'fake' a sequence of live measurements. Now I realize that I could probably call the sd_ble_gatts_hvx() here which will eventually generate an event. But I dont want to do that since it introduces the possibility of asynchronous behavior. Instead I want to prepare the data, set the notify flag, and wake up the sd_app_evt_wait(). It does not matter if the event is one I do not handle; I just need to wake up the loop so the send_data method is called from that loop. That would keep the entire flow synchronous.
Here is the main for-loop code. Hopefully it will make the above rather cryptic description clearer.
/**@brief Function for the main 'embedded' loop. The Nordic SoftDevice is event driven.
* Any method prefixed by sd_* is a SoftDevice method. SoftDevice methods consist of just
* your basic GATT and GAP level calls. The Nordic SDK provides methods to simplify certain
* processes but they all call these sd_* methods. Here we do not use the SDK but only sd_*.
* The key method in the wait loop is sd_app_evt_wait(). This method waits until a Bluetooth
* or system event is triggered. When that happens, the function returns. The application must
* then use the method sd_ble_evt_get() to get the Bluetooth Event that just occurred. It could
* be a read, write, connection, disconnection, etc. The application then must either handle
* the event or ignore it. In this application the event handler is ble_evt_dispatch(). Note
* that after the event is handled one has to call sd_ble_evt_get() again until the method
* returns that there are no more events. One then calls sd_app_evt_wait() and the process
* repeats. But we extend that functionality.
* Note that the loop also contains a call to the application method indicate_data(). It is poorly
* named as it does both indications and notifications. What this method does is check if a flag
* has been set that data needs to be indicated/notified. If it has, the flag will be cleared and
* a hunk of data will be indicated/notified. If it is an indication, the app must wait until
* the indication is confirmed so the data is sent and the position in the buffer is updated by
* the amount of data sent. Then the method returns, and we wait for the confirmation event
* BLE_GATTS_EVT_HVC to occur. If all the segments have been sent, the next procedure occurs. If
* not, the indicate flag is set to true and the next segment is sent.
* If the data is notified, hunks can be sent one after the other without waiting for an event
* until the notification buffers are depleted. When that happens, the application must wait for
* the BLE_EVT_TX_COMPLETE. At that point we can continue. This loopy way of handling sending
* data segments would be equivalent to waiting on a semaphore in a real time OS.
* Recall that the GHS works as follows:
* 1. receive a command on the Control Point
* 2. if the command is to send data (current time, system info, config info, get stored records,
* send live data) the data is notified on the response characteristic until all segments are
* sent.
* Now if the data being sent is measurements, there may be several records, especially when
* transferring stored data. A record consists of all the measurements with a common time
* stamp. When a record is completed, the PHD server sends an indication on the CP saying a record
* has completed. The PHG client shall not send another command yet. The PHD must send a second
* indication on the CP sayong that all records have been sent. Then the PHG can send another
* command.
* The system info, current time info, and config info contain only one long entry. There is
* no record in that case.
* 3. if the PHD does not support the command or the command is to get the number of stored
* records or delete stored data, there is only an indication on the CP with the result or DONE.
* Pairing/bonding. This implementation requires that the client ask the PHDe if the PHD wants to
* pair. If the PHD responds 'yes' on the CP, the cleint begins pairing. To do this none of the
* characteristics or descriptors are secured. However, if the application wants to pair and the
* client does not, all other commands will fail. Probably should put a special error message like
* PHD requires pairing and the PHG did not pair. The device could also disconnect. This is up in
* the air. We do this to keep the agony of pairing as user-friendly as possible as well as synchronous.
* The client will never have to worry about getting a security request or insufficient autherntication
* error while doing something else. GREATLY simplifies cleint code not having to check for this crap.
* In addition, the user does not have to know if the PHD is pairable or unpairable; the user only has
* to discover and connect. Pairing has proved to be a user nightmare in the field.
* Clearly the command values and response codes are all up in the air. To just make this work
* a set of minimal values were chosen.
*/
static void main_loop(void)
{
uint8_t enabled;
uint16_t len;
uint32_t result;
for (;;)
{
indicate_data(); // when flag is set, a set of data is indicated or notified depending upon setup.
// Flag is reset in method
main_wait(); // Contains the sd_app_evt_wait()
while(true)
{
sd_softdevice_is_enabled(&enabled); // Don't do this if disabled, for example when writing flash at the end
if (enabled != 1)
{
NRF_LOG_DEBUG("Restarting application%u\r\n");
while(NRF_LOG_PROCESS());
NVIC_SystemReset();
return;
}
result = sd_ble_evt_get(NULL, &len); // Get size of event
if (result == NRF_ERROR_NOT_FOUND) // If there aren't any, go back to wait
{
break;
}
evt_buf = (uint8_t *)calloc(1, len); // Make space for event. evt_buf is 4-byte aligned
result = sd_ble_evt_get((uint8_t *)evt_buf, &len); // get the event
if (result == NRF_SUCCESS)
{
ble_evt_t *evt = (ble_evt_t *)evt_buf;
ble_evt_dispatch(evt); // dispatch event to handler. This handles only BTLE related events
}
else // Hopefully no error but just in case log it.
{ // Should I do an NVIC_SystemReset() here?
NRF_LOG_DEBUG("PENDING BLE Event return error: %u\r\n", result);
free(evt_buf); // Clean up
break; // back to wait
}
free(evt_buf); // clean up and get the next event
}
}
}
