Diff: source/nRF5xGap.h

Revision:

482:0efda47cc288

Parent:

481:1762975cb3cb

Child:

488:a30b397a5b5d

--- a/source/nRF5xGap.h	Thu Nov 26 15:02:39 2015 +0000
+++ b/source/nRF5xGap.h	Wed Dec 02 10:31:00 2015 +0000
@@ -26,11 +26,7 @@
 #include "ble/GapScanningParams.h"
 
 #include "nrf_soc.h"
-
-extern "C" {
 #include "ble_radio_notification.h"
-}
-
 #include "btle_security.h"
 
 void radioNotificationStaticCallback(bool param);
@@ -113,84 +109,12 @@
 #endif
 
 private:
-    bool    radioNotificationCallbackParam; /* parameter to be passed into the Timeout-generated radio notification callback. */
-    Timeout radioNotificationTimeout;
-
-    /*
-     * A helper function to post radio notification callbacks with low interrupt priority.
-     */
-    void postRadioNotificationCallback(void) {
-#ifdef YOTTA_CFG_MBED_OS
-        /*
-         * In mbed OS, all user-facing BLE events (interrupts) are posted to the
-         * MINAR scheduler to be executed as callbacks in thread mode. MINAR guards
-         * its critical sections from interrupts by acquiring CriticalSectionLock,
-         * which results in a call to sd_nvic_critical_region_enter(). Thus, it is
-         * safe to invoke MINAR APIs from interrupt context as long as those
-         * interrupts are blocked by sd_nvic_critical_region_enter().
-         *
-         * Radio notifications are a special case for the above. The Radio
-         * Notification IRQ is handled at a very high priority--higher than the
-         * level blocked by sd_nvic_critical_region_enter(). Thus Radio Notification
-         * events can preempt MINAR's critical sections. Using MINAR APIs (such as
-         * posting an event) directly in processRadioNotification() may result in a
-         * race condition ending in a hard-fault.
-         *
-         * The solution is to *not* call MINAR APIs directly from the Radio
-         * Notification handling; i.e. to do the bulk of RadioNotification
-         * processing at a reduced priority which respects MINAR's critical
-         * sections. Unfortunately, on a cortex-M0, there is no clean way to demote
-         * priority for the currently executing interrupt--we wouldn't want to
-         * demote the radio notification handling anyway because it is sensitive to
-         * timing, and the system expects to finish this handling very quickly. The
-         * workaround is to employ a Timeout to trigger
-         * postRadioNotificationCallback() after a very short delay (~0 us) and post
-         * the MINAR callback that context.
-         *
-         * !!!WARNING!!! Radio notifications are very time critical events. The
-         * current solution is expected to work under the assumption that
-         * postRadioNotificationCalback() will be executed BEFORE the next radio
-         * notification event is generated.
-         */
-        minar::Scheduler::postCallback(
-            mbed::util::FunctionPointer1<void, bool>(&radioNotificationCallback, &FunctionPointerWithContext<bool>::call).bind(radioNotificationCallbackParam)
-        );
-#else
-        /*
-         * In mbed classic, all user-facing BLE events execute callbacks in interrupt
-         * mode. Radio Notifications are a special case because its IRQ is handled at
-         * a very high priority. Thus Radio Notification events can preempt other
-         * operations that require interaction with the SoftDevice such as advertising
-         * payload updates and changing the Gap state. Therefore, executing a Radio
-         * Notification callback directly from processRadioNotification() may result
-         * in a race condition ending in a hard-fault.
-         *
-         * The solution is to *not* execute the Radio Notification callback directly
-         * from the Radio Notification handling; i.e. to do the bulk of the
-         * Radio Notification processing at a reduced priority. Unfortunately, on a
-         * cortex-M0, there is no clean way to demote priority for the currently
-         * executing interrupt--we wouldn't want to demote the radio notification
-         * handling anyway because it is sensitive to timing, and the system expects
-         * to finish this handling very quickly. The workaround is to employ a Timeout
-         * to trigger postRadioNotificationCallback() after a very short delay (~0 us)
-         * and execute the callback in that context.
-         *
-         * !!!WARNING!!! Radio notifications are very time critical events. The
-         * current solution is expected to work under the assumption that
-         * postRadioNotificationCalback() will be executed BEFORE the next radio
-         * notification event is generated.
-         */
-        radioNotificationCallback.call(radioNotificationCallbackParam);
-#endif /* #ifdef YOTTA_CFG_MBED_OS */
-    }
-
     /**
      * A helper function to process radio-notification events; to be called internally.
      * @param param [description]
      */
     void processRadioNotificationEvent(bool param) {
-        radioNotificationCallbackParam = param;
-        radioNotificationTimeout.attach_us(this, &nRF5xGap::postRadioNotificationCallback, 0);
+        radioNotificationCallback.call(param);
     }
     friend void radioNotificationStaticCallback(bool param); /* allow invocations of processRadioNotificationEvent() */