Hi there,
我试图设置一个特征处理程序，当提供值01时，它开始播放一个循环的音调，直到提供值00。我正在使用ble\u app\u外设作为指南，并修改了LED的开/关状态，以开始我想要的while循环。我需要的帮助是退出while循环的最佳方法，或者是更好的方法。根据我的理解，在while循环中，处理程序实际上不会做任何事情，对吗？
Many thanks in advance
Device:
⚠️
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.
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.
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.
谢谢你的对话
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.
正如您所建议的，问题是当我读取特征并启动while循环进行调谐时，系统被卡在循环中，无法检测特征变化，因此中断了循环。
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
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).
谢谢你的对话
Hi MT_dialog,
Thank you so much, that appears to be exactly what I was looking for.