I'm developing for the NRF52 DK (nRF52832) using VisualGDB (which uses SDK v11.0.0).
Right now I'm facing two problems:
1. How do I properly handle interrupts while using Event Queue?
This is how I use the interrupt functionality:
//defining the interrupt pin:
InterruptIn interrupt(p16);
//this part is insite main function:
interrupt.rise(&interruptEvent); //inside interruptEvent a flag is set true
This is how I use the Event-Queue:
//initializing the queue:
EventQueue* eventQueue = mbed_event_queue();
//this part is inside the main function:
ble.onEventsToProcess(scheduleBleEventsProcessing);
ble.init(bleInitComplete);
eventQueue->dispatch_forever();
All BLE functions are taken from existing examples that work like a charm, no problems there. After some research I found the priority-list which shows that BLE is above everything else I use. This itself is not really the problem as I don't have to react to the interrupts immediately (a human should still feel like it is instant, but that should not be too hard to achieve). The problem here if there are interrupts in my system they come at 100Hz (it's a data-ready interrupt from a sensor connected through I2c and the interrupt pin). So I'm wondering if there is a function hidden somewhere to handle interrupts like there are functions that can handle the BLE connection / disconnection / advertising etc.
//like these:
ble.gap().onDisconnection(disconnectionCallback);
ble.gap().onConnection(connectionCallback);
and even if I start to ignore any Interrupt after the first one for a while (which does not make a difference to my system), isn't the way I'm doing this interfering with the Queue/BLE functions as it is a separate thing from them? As a interrupt could occur even during sending/receiving data via BLE.
2. How long can events take in the queue?
Some of my functions that get thrown into the queue might take some time (up to a few ms) and should not be interrupted by anything (communication via I2C, writing to internal flash). I tested this with a wait function and it works no matter how long I wait within one task in the queue. But this raised my suspicion that the BLE functions simply interrupt anything else, do their thing and than continue where they left off.
Note: everything I'm using in my program works independently from each other, using BLE with the queue alone works fine including simple tasks like measuring battery voltage and sending it to a phone. Communication via I2C works fine, reading the location sensor too. Problems only occur if I combine those two together and of what I can see the problems occur due to timing issuses .
