Characteristic handler loop

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at//www.xmece.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
5 posts / 0 new
Last post
richbk
Offline
Last seen:2 months 2 weeks ago
加入:2017-04-24 20:24
Characteristic handler loop

Hi there,

我想建立一个处理程序特征when a value of 01 is supplied, it starts playing a tune that loops until a value of 00 is supplied. I'm using the ble_app_peripheral as a guide and have modified the LED on/off state to begin the while loop I want. What I need help on is the best way to exit the while loop or perhaps a better way to approach this. From my understanding whilst in the while loop, the handler won't actually do anything, is that correct?

Many thanks in advance

Device:
MT_dialog
Offline
Last seen:2 months 1 week ago
Staff
加入:2015-06-08 11:34
Hi richbk,

Hi richbk,

I am not sure i fully understand what you are trying to do, you will write a value in a characteristic and this will trigger a handler that will keep the ARM in a while loop (so that the tune will keep on playing) ? Also i am not able to understand what you mean that the "handler won't actually do anything". If you trigger that handler via writing a characteristic and you have a while loop in that handler, the ARM is going to keep on executing the while loop in that handler as long as the while condition returns true. This can caused different kinds of problems depending how much time the while is going to take in order to finish execution. So if you keep the ARM in that while loop, you wont be executing scheduler (rwip_schedule() function) and that means that you are going to lose BLE events, you wont be updating the watchdog (in case you want to use it, but that is the least of your problems). If you would like to play that tune for a large amount of time without having any BLE issues you will have to trigger the operation (the tune playing) and then use either the app_on_ble_powered() or the app_on_system_power() callback functions in order to drive your speaker (please have a look at the UM-B-051 da1458x Software Platform Reference.pdf in paragraph 7.2.1). Anyway since i am not sure that i fully understand your question, let me know if there is anything that i misunderstood.

Thanks MT_dialog

richbk
Offline
Last seen:2 months 2 weeks ago
加入:2017-04-24 20:24
Hi MT_Dialog,

Hi MT_Dialog,

Many thanks for taking the time to reply.

To try and explain a bit more about what I'm trying to do I'm essentially building a device that is linked to a phone. When the phone rings, the device plays a tune using PWM and when the phone stops ringing, the device stops playing the tune. To start the tune playing I'm using a characteristic (like the LED example) that when it is set to 01 it plays the tune and when it is set to 00 it stops playing the tune.

As you've suggested the issue is that when I read the characteristic and start the while loop for the tune, the system is stuck in the loop without a way to detect the characteristic change and therefore break out of the loop.

With that in mind would your suggestion to use app_on_ble_powered() callbacks work for what I need? Would I put the tune loop in the callback function and use flags throughout the tune loop to determine whether the characteristic has changed to stop the tune from playing?

Many thanks

MT_dialog
Offline
Last seen:2 months 1 week ago
Staff
加入:2015-06-08 11:34
Hi richbk,

Hi richbk,

既然你想产生PWM,为什么dont you use the timers of the 580 in order to do so, and just set it up and trigger the timer when the characteristic is written. By toggliing GPIOs into a while loop you wont be able to produce the PWM (i suppose that this is what you would like to do in your while loop with some delay, when the characteristic is written), even if using the app_on_ble_powered you wont be able to control how often the the GPIO toggling will go through that function and also you cant just delay the execution of the code for aquiring the proper timing. If you dont want to use the hardware timers and the PWM functionallity and you would like just to toggle the GPIOs you can also use kernel timers but be aware that they have an accurancy of 10ms and they are not as accurate as the PWM dedicated timers. So my suggestion would be to use timer0 and PWM functionallity and also the exact same scheme is used by the smart_tag project (check the user_proxr_alert_start() function) when the IAS characteristic is written (you will have to disable sleep as well in order not to go in sleep mode when the PWM is triggered).

Thanks MT_dialog

richbk
Offline
Last seen:2 months 2 weeks ago
加入:2017-04-24 20:24
Hi MT_dialog,

Hi MT_dialog,

Thank you so much, that appears to be exactly what I was looking for.