TASK_APP and TASK_GTL coexistance

⚠️
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.wsdof.com/support. We’ll be fixing bugs / optimising the searching and tagging over the coming days.
4 posts / 0 new
Last post
Sun, 2019-02-10 04:55
#1
Nishal
Offline
Last seen:2 years 2 months ago
Joined:2017-05-25 06:51
TASK_APP and TASK_GTL coexistance

Hi Dialog Team,

I am working on DA14585 with external host mode, and BLE in scanner/observed mode configuration. I am using ST32F4 for external host with UART interface.

I want to add additional functionalities on BLE upon special requests from host.
我已经发布了类似的问题
https://support.dialog-semiconductor.com/comment/22363

Since I haven't received any solution on that, I am thinking if I can have APP_TASK and GTL_TASK coexist. By this approach I was thinking that
commands can be sent, and If I can reroute
MCU(GTL_TASK)------------->BLE(APP_TASK)-----------ke_msg_forward----->Stack(TASK_GAPM)
response can be rerouted as
Stack(TASK_GAPM)------------->BLE(APP_TASK)-----------ke_msg_forward----->MCU(GTL_TASK)

By this I can achieve my custom tasks as well, where there is no BLE stack intervention
MCU(GTL_TASK)------------->BLE(APP_TASK) for LED blink
BLE(APP_TASK)---------------->MCU(GTL_TASK) for gpio_read

Please let me know if this is realizable, and some pointers for the same.

Looking forward for immediate help.

提前谢谢!

Keywords:
TASK_APP and TASK_GTL coexistance
Device:
DA14585
Tue, 2019-02-12 16:17
PM_Dialog
Offline
Last seen:2 days 12 hours ago
Staff
Joined:2018-02-08 11:03
Hi Nishal,

Hi Nishal,

The procedure that you have described is realizable and thanks for your information. Let me share you same tips might help you:

  1. In the ROM configuration table, rom_cfg_table_var of the jump_table. C file you should add the TASK_APP and then you should accomplish what you mentioned in your post.

ke_task_id_t prf_get_task_from_id_func(ke_msg_id_t id)

{

…

TASK_APP, // 11. app_main_task_pos

}

You should midify the prf_get_task_from_id_func as below. Otherwise, to will get an UNKNOWN_TASK error.

ke_task_id_t prf_get_task_from_id_func(ke_msg_id_t id)

{

ke_task_id_t task = TASK_NONE;

uint8_t idx = KE_IDX_GET(id);

uint8_t i;

id = KE_TYPE_GET(id);

// find if profile present in profile tasks

for(i = 0; i < BLE_NB_PROFILES ; i++)

{

// check if profile identifier is known

if(prf_env.prf[i].id == id)

{

task = prf_env.prf[i].task;

break;

}

}

if (id == TASK_ID_APP)

{

task = TASK_APP;

}

return KE_BUILD_ID(task, idx);

}

Thanks, PM_Dialog

Mon, 2019-02-18 07:43
(Reply to #2)
Nishal
Offline
Last seen:2 years 2 months ago
Joined:2017-05-25 06:51
Hi PM_Dialog,

Hi PM_Dialog,

Thanks for the input.

I have few questions
1. Is GTL thread always created by default irrespective of embedded/host processor mode?
2. Can I use empty_peripheral_template or empty_template_ext example as a starting point?
-If I use empty_peripheral_template , I dont understand how MCU messages are received.
-If I use empty_template_ext , then I have to solve dependencies with CFG_APP (build time macro or embedded / external processor)

提前谢谢!
Nishal

Tue, 2019-02-19 16:25
PM_Dialog
Offline
Last seen:2 days 12 hours ago
Staff
Joined:2018-02-08 11:03
Hi Nishal,

Hi Nishal,

Regarding you first question let me check in order to be sure. Regarding you second question, I would suggest to use the empty_template_ext.

Thanks, PM_Dialog