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();