Event vs Interrupt

[Lakshmikanth Satyavolu]

Hi All,

I am developing a data acquisition system in which my device generates an interrupt for every 5ms upon its data is ready. I store one second long data in local buffer and write it into external flash memory every 1 second. 

I am bit confused with GPIO events and interrupts in nRF. I guess any level change on a input pin is called an event in nRF. If that is true I would like to configure one GPIO as input and configure an event (High to Low in my case) then assign it to an event handler. 

And then, I have read below lines in SDK documentation, 

When a SoftDevice is enabled, it can interrupt the application at any time for a certain amount of time. This can lead to the situation where some pin level changes are missed. If the application must track an input pin that can change its level frequently, PPI should be used with a high-accuracy event together with a TIMER in counter mode to count the detected transitions.

Below are my queries:

1. My interrupt is generated every  5ms infinitely, and I cannot afford any single interrupt to lose. I would like to know how can I configure my interrupt handling mechanism to avoid data loss? 
2. If I use PPI with Timer to count the interrupts I have missed from my peripheral, how can I retrieve data from my device at later point? 
3. What is a softdevice? how it can interrupt the application? 
4. I need some help understanding event. Previously i was using a processor where any GPIO can be configured for external interrupts which is very straight forward. In nRF it seems there is no interrupt concept for GPIO rather they call it as event. 

Any help would be highly appreciated. 

Regards

Laskhmi

[Lakshmikanth Satyavolu]

Hi Einar, 

Here is my requirement.

My sensor samples are 3 bytes wide each. I want to encapsulate 6 samples = 18 bytes and 2 bytes header total 20 bytes.

In ble_hrs_heart_rate_measurement_send(ble_hrs_t * p_hrs, uint16_t heart_rate),I guess the parameter heart_rate is the data, which takes two bytes. Correct me if I am wrong.

To send 20 bytes packet, should I call ble_hrs_heart_rate_measurement_send 10 times with two bytes each?? 

When ATT_MTU is 23, I think I should be able to send all 23 bytes buffer in one ble_hrs_heart_rate_measurement_send API call. Which is bit confusing for me. Please clarify. 

Regards

Lakshmikanth. 

[Einar Thorsrud]

Hi,

Lakshmikanth Satyavolu said:

To send 20 bytes packet, should I call ble_hrs_heart_rate_measurement_send 10 times with two bytes each?? 

No, that would send shorter packets. But it would be in line with the standardized heart rate service (which is what you want in most products).

Lakshmikanth Satyavolu said:

When ATT_MTU is 23, I think I should be able to send all 23 bytes buffer in one ble_hrs_heart_rate_measurement_send API call. Which is bit confusing for me. Please clarify. 

Yes, you could. The only problem is that putting more samples in a long heart rate measurement characteristic, so that you can notify them all at once is not in line with the standard service. If you don't need to be interoperable with anything not made by yourself, then there is no problem doing this. Referring to SDK 16, the implementation in ble_hrs.c already support a heart rate characteristic length of 20 (INITIAL_VALUE_HRM), so there is no need to modify the characteristic length. The only thing you would need to do was to modify ble_hrs_heart_rate_measurement_send() or make a similar function that takes the input as a pointer and length instead of a uint16_t.

[Lakshmikanth Satyavolu]

Hi Einar,

Perfect. At this point interoperability is not an issue for us. I will try implementing new API for this requirement. 

Thanks. 

Lakshmikanth 

[Lakshmikanth Satyavolu]

Hi Einar,

After going through the implementation of ble_hrs_heart_rate_measurement_send  and hrm_encode API,  I realized those are supporting only uint16_t width heart rate measurement. 

Having said that, Do I need to modify hrm_encode() API too for accommodating long measurements ? 

Another observation is INITIAL_VALUE_HRM value has been set as '0" in ble_hrs.c not 20. Please confirm. 

Regards

Lakshmikanth. 

[Einar Thorsrud]

Hi Lakshmikanth,

Lakshmikanth Satyavolu said:

Having said that, Do I need to modify hrm_encode() API too for accommodating long measurements ? 

That is up to you. You could also call it repeatedly.

Lakshmikanth Satyavolu said:

Another observation is INITIAL_VALUE_HRM value has been set as '0" in ble_hrs.c not 20. Please confirm. 

No, it can be any value.

Please note that when doing these modifications your device will no longer implement the standardized HRM service, so you must also change the UUID to a custom UUID in order for the device to be Bluetooth qualifiable.