⚠️ 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, i have question about the main loop. I can't find the function which return callback functions such as: app_on_init , app_on_system_powered... i'm reading example ble_app_peripheral in SDK 5.0.4
All the callback function are located into user_callback_config.h header file. The in the .app_on_init is registered the user_app_init() callback function. The source code can be found in user_peripheral.c file. In the .app_on_system_powered in the ble_app_peripheral example of the SDK, none callback is registered that’s why is NULL. However, you can register your own callback function.
thanks for your answer. But i can't find the reference of function rwip_schedule() in the project. Is it in the BLE stack?
And in the function schedule_while_ble_on(), in the example, i see that user_app_main_loop_callbacks.app_on_ble_powered = Null in the beginning. So the main loop will go out the do-while loop and try to sleep. what can make the function poiter user_app_main_loop_callbacks.app_on_ble_powered != Null so the system will stay active?
The source code of rwip_schedule () is in the ROM so that you are not able to find it. In the active part of the main loop, the kernel will be granted control with a call to rwip_schedule() and it will keep the control for as long as messages and events need to be handled. The call to rwip_schedule()happens in schedule_while_ble_on() since the kernel requires the BLE hardware to be active to process messages. Within schedule_while_ble_on() the application is also granted control through the user_app_main_loop_callbacks.app_on_ble_powered function pointer. The application can force the main loop to stay within the schedule_while_ble_on() given that the BLE remains active according to the return value of app_on_ble_powered. If both application and kernel allow scheduler_while_ble_on() to return, the control will be granted again to the application via the app_asynch_proc() function and the user_app_main_loop_callbacks.app_on_system_powered function pointer. Please refer to section 7.1 Main Loop and Sleep Modes inUM-B-051 : DA14580 Software Platform Reference (SDK5)document.
thanks, i have been already reading the document, and i'm trying to understand it clearly. i want to ask about a function arch_printf_process(). is it in the Rom?
Hi Thanhtu131,
All the callback function are located into user_callback_config.h header file. The in the .app_on_init is registered the user_app_init() callback function. The source code can be found in user_peripheral.c file. In the .app_on_system_powered in the ble_app_peripheral example of the SDK, none callback is registered that’s why is NULL. However, you can register your own callback function.
Thanks, PM_Dialog
thanks for your answer. But i can't find the reference of function rwip_schedule() in the project. Is it in the BLE stack?
And in the function schedule_while_ble_on(), in the example, i see that user_app_main_loop_callbacks.app_on_ble_powered = Null in the beginning. So the main loop will go out the do-while loop and try to sleep. what can make the function poiter user_app_main_loop_callbacks.app_on_ble_powered != Null so the system will stay active?
Hi Thanhtu131,
The source code of rwip_schedule () is in the ROM so that you are not able to find it. In the active part of the main loop, the kernel will be granted control with a call to rwip_schedule() and it will keep the control for as long as messages and events need to be handled. The call to rwip_schedule()happens in schedule_while_ble_on() since the kernel requires the BLE hardware to be active to process messages. Within schedule_while_ble_on() the application is also granted control through the user_app_main_loop_callbacks.app_on_ble_powered function pointer. The application can force the main loop to stay within the schedule_while_ble_on() given that the BLE remains active according to the return value of app_on_ble_powered. If both application and kernel allow scheduler_while_ble_on() to return, the control will be granted again to the application via the app_asynch_proc() function and the user_app_main_loop_callbacks.app_on_system_powered function pointer. Please refer to section 7.1 Main Loop and Sleep Modes inUM-B-051 : DA14580 Software Platform Reference (SDK5)document.
Thanks, PM_Dialog
thanks, i have been already reading the document, and i'm trying to understand it clearly. i want to ask about a function arch_printf_process(). is it in the Rom?
Hi Thanhtu131,
The source code of arch_printf_process() API can be found in arch_console.c which is located under sdk\platform\core_modules\arch_console SDK path.
Thanks, PM_Dialog
谢谢你的解释。我有一个nother question: What is the operation of the function SetWord16() and SetBits16()? I can't find their reference and defination in the SDK.
Hi Thanhtu131, It's to set a word and abit into as 16 bit register. Thanks, PM_Dialog
Thanks alot