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 Thorsrud, 

Thanks for the information. It was very useful to get started. 

Currently  I am using heartrate application. I have below queries. 

In this application,  ble_hrs_heart_rate_measurement_send(&m_hrs, heart_rate)  is used to send the measurement to the central. But it seems it is sending only two byte value (which is heart_rate parameter in this case)when each time it gets called. 

But my application needs to send more data for each time the heartrate_timer expires. 

Assuming default ATT_MTU 23 bytes has been set in this example, how to send a 20bytes packet in one shot?

Is there any internal FIFO available in BLE stack to fill the data to be continuously sent in 20bytes chunks or more by setting ATT_MTU to its max value? Because I have to send real time data continuously. But I am not sure how to use ble_hrs_heart_rate_measurement_send API to achieve this. 

Please help me. 

Regards

Lakshmi

[Einar Thorsrud]

Hi Lakshmi,

Lakshmikanth Satyavolu said:

Assuming default ATT_MTU 23 bytes has been set in this example, how to send a 20bytes packet in one shot?

In that case, you would need to send all this data in one notification. This is because even though an ATT packet can span multiple link layer (LL) packets, there cannot be multiple ATT packets in a single LL packet. But if you do that, your device will not comply with the Heart Rate Profile. So I suspect a better solution is to send several notifications and use a configuration that allows multiple packets per connection event if you really need to get the data simultaneously. It will give you a bit more overhead (unless interoperability is irrelevant for your application).

Lakshmikanth Satyavolu said:

Is there any internal FIFO available in BLE stack to fill the data to be continuously sent in 20bytes chunks or more by setting ATT_MTU to its max value? Because I have to send real time data continuously. But I am not sure how to use ble_hrs_heart_rate_measurement_send API to achieve this. 

There is a FIFO of LL packets, so if you fill it with several packets, it will be sent in one connection interval if there is time (and there are no retransmissions).

Einar

[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.