Test using the base BLE_HeartRate example to see the effect of increasing the "ticker" rate on stability (intending to do AnalogIn around 1ms rate)
Dependencies: BLE_API mbed nRF51822
Diff: main.cpp
- Revision:
- 1:259fe4d2ab16
- Parent:
- 0:ec36dec086bb
- Child:
- 2:7de236382497
--- a/main.cpp Mon Sep 29 10:33:30 2014 +0000
+++ b/main.cpp Mon Sep 29 11:17:04 2014 +0000
@@ -34,6 +34,13 @@
#define DEBUG(...) /* nothing */
#endif /* #if NEED_CONSOLE_OUTPUT */
+// Sample interval (uS)
+volatile uint32_t sampleIntervalUs = 1000;
+
+// Timer to do the sampling etc
+Timer intervalTimer;
+Timeout sampleTimeout;
+
const static char DEVICE_NAME[] = "HRMonitor";
static const uint16_t uuid16_list[] = {GattService::UUID_HEART_RATE_SERVICE,
GattService::UUID_BATTERY_SERVICE,
@@ -47,21 +54,33 @@
ble.startAdvertising();
}
+static volatile int callbackCount = 0;
void periodicCallback(void)
{
- led1 = !led1; /* Do blinky on LED1 while we're waiting for BLE events */
-
- /* Note that the periodicCallback() executes in interrupt context, so it is safer to do
- * heavy-weight sensor polling from the main thread. */
- triggerSensorPolling = true;
+ callbackCount++;
+ if (callbackCount == 1000)
+ {
+ callbackCount = 0;
+ led1 = !led1; /* Do blinky on LED1 while we're waiting for BLE events */
+ /* Note that the periodicCallback() executes in interrupt context, so it is safer to do
+ * heavy-weight sensor polling from the main thread. */
+ triggerSensorPolling = true;
+ }
+
+ sampleTimeout.attach_us(periodicCallback, sampleIntervalUs);
}
int main(void)
{
led1 = 1;
indicatorLed2 = 1;
- Ticker ticker;
- ticker.attach(periodicCallback, 1);
+
+ // Start timer and sampling
+ intervalTimer.start();
+ sampleTimeout.attach_us(periodicCallback, sampleIntervalUs);
+
+// Ticker ticker;
+// ticker.attach(periodicCallback, 1);
DEBUG("Initialising the nRF51822\n\r");
ble.init();