Event vs Interrupt

RE: Event vs Interrupt

Einar Thorsrud — Wed, 11 Mar 2020 09:22:25 GMT

Hi Lakshmikanth,

[quote user="Satyavolu"]Having said that, Do I need to modify hrm_encode() API too for accommodating long measurements ? [/quote]

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

[quote user="Satyavolu"]Another observation is INITIAL_VALUE_HRM value has been set as '0" in ble_hrs.c not 20. Please confirm. [/quote]

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.

RE: Event vs Interrupt

Lakshmikanth Satyavolu — Tue, 10 Mar 2020 16:49:38 GMT

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.

RE: Event vs Interrupt

Lakshmikanth Satyavolu — Tue, 10 Mar 2020 16:09:58 GMT

Hi Einar,

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

Thanks.

Lakshmikanth

RE: Event vs Interrupt

Einar Thorsrud — Tue, 10 Mar 2020 08:08:06 GMT

Hi,

[quote user="Satyavolu"]To send 20 bytes packet, should I call ble_hrs_heart_rate_measurement_send 10 times with two bytes each?? [/quote]

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

[quote user="Satyavolu"]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. [/quote]

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.

RE: Event vs Interrupt

Lakshmikanth Satyavolu — Mon, 09 Mar 2020 18:18:41 GMT

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.

RE: Event vs Interrupt

Einar Thorsrud — Mon, 09 Mar 2020 14:03:05 GMT

Hi Lakshmi,

[quote user="Satyavolu"]Can you suggest an example application if any, or API to be used for to write into FIFO please? [/quote]

Assuming we are talking about notifications here, just send more notifications, and they will be put in a FIFO in the SoftDevice. This is not something you need to think of, other than handling a full FIFO, where you get NRF_ERROR_RESOURCES returned from the call to sd_ble_gatts_hvx().

If this does not answer your question, then please elaborate exactly what you want (remembering that there is no more than one ATT packet in a single LL packet, as mentioned before).

Einar

RE: Event vs Interrupt

Lakshmikanth Satyavolu — Mon, 09 Mar 2020 12:47:03 GMT

Hi Einar Thorsrud

Can you suggest an example application if any, or API to be used for to write into FIFO please?

Regards

Lakshmi

RE: Event vs Interrupt

Einar Thorsrud — Mon, 09 Mar 2020 08:11:40 GMT

Hi Lakshmi,

[quote user="Satyavolu"]Assuming default ATT_MTU 23 bytes has been set in this example, how to send a 20bytes packet in one shot?[/quote]

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

[quote user="Satyavolu"]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. [/quote]

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

RE: Event vs Interrupt

Lakshmikanth Satyavolu — Sat, 07 Mar 2020 12:33:58 GMT

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

RE: Event vs Interrupt

Einar Thorsrud — Fri, 06 Mar 2020 18:23:27 GMT

Hi Laskhmi,

[quote user=""]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? [/quote]

5 ms is quite a long time, so it should not be a problem to ensure that you never miss any of these interrupts. However, it might be that the interrupt processing is delayed a bit, but that may not be a problem? You can refer to the Interrupt model and processor availability in the SoftDevice documentation to see the maximum time the SoftDevice will delay the application, and as you see that is in any case significantly less, giving you a lot of margin.

[quote user=""]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? [/quote]

That depends on the peripheral. But I do not see this a likely problem since the frequency of the interrupt is so slow.

[quote user=""]What is a softdevice? how it can interrupt the application? [/quote]

A SoftDevice is Nordic's proprietary BLE stack. It needs to have the highest interrupt priority since Bluetooth has strict timing requirements, and several low-level radio interrupts need to be serviced in a timely manner.

[quote user=""]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. [/quote]

You can think of interrupts and events in the same way. When the application gets a. SoftDevice event, it is actually a software interrupt. And when there is a pin change interrupt form a GPIO, the SDK driver you typically use will have it's interrupted routine run, and this will call the applications event handler in the interrupt context. So it is in practice the same. (If you look at the terms used in the ARM documentation, you will also see interrupts and events used. In this case, it is also essentially the same, but some minimal differences. In the nRF peripheral HW context, the difference is bigger, since you can have HW events that trigger interrupts or not, depending on the configuration. But that is probably not relevant for your question in this case.)