I am currently using the XMOS XK-Voice-SQ66 development board and working with the xvf3800_intdev-lr16-sqr-spi firmware. As part of my development, I am trying to send azimuth data from one module to another and need some guidance.
Specifically, I want to transmit data from:
File: sources\modules\fwk_xvf\modules\xvf\src\data_plane\audio_task.c
Code Segment:
buffers[MUX_USER_CHOSEN_CHANNELS].buf[0] = buffers[MUX_ALL_USER_CHANNELS].buf[audio_task_params.current_selected_channels[0]];
To this location:
File: sources\modules\fwk_xvf\modules\xvf\src\control_plane\io_expander.c
I am relatively new to the XMOS architecture and would appreciate your help in understanding how to use chanend_t for this purpose. Advice on setting up communication between tasks would be extremely helpful.
Thank you for your time and assistance.
Best regards,
Praveen
Assistance Required for Sending Data Between Tasks in XMOS XK-Voice-SQ66 Board
-
- Junior Member
- Posts: 7
- Joined: Wed Oct 23, 2024 12:00 pm
-
Verified
- Active Member
- Posts: 39
- Joined: Wed May 22, 2024 2:36 pm
Hey Praveen, apologies for the slow reply.
This is one of the more complicated things to do in this application. I will try and describe what I think is required to achieve what you want. The complication here is that io_expander is running in a freeRTOS thread which cannot safely communicate via channels, only via freeRTOS primitives. However, audio_task.c is running in a baremetal thread which cannot use the freeRTOS primitives to communicate. Also it is very tight on timing so any blocking communication will not work.
I think a simple option will be to spawn a freeRTOS task which calls "send_read_cmd_to_servicer" to read from `AUDIO_MGR_RESID`, if you are trying to read the current_selected_channels then the cmd id will the `AUDIO_MGR_RESID_AUDIO_MGR_SELECTED_CHANNELS`.
Huw
This is one of the more complicated things to do in this application. I will try and describe what I think is required to achieve what you want. The complication here is that io_expander is running in a freeRTOS thread which cannot safely communicate via channels, only via freeRTOS primitives. However, audio_task.c is running in a baremetal thread which cannot use the freeRTOS primitives to communicate. Also it is very tight on timing so any blocking communication will not work.
I think a simple option will be to spawn a freeRTOS task which calls "send_read_cmd_to_servicer" to read from `AUDIO_MGR_RESID`, if you are trying to read the current_selected_channels then the cmd id will the `AUDIO_MGR_RESID_AUDIO_MGR_SELECTED_CHANNELS`.
Huw
XMOS Software Engineer
-
- Junior Member
- Posts: 7
- Joined: Wed Oct 23, 2024 12:00 pm
Hi Huw,
Thank you for your detailed explanation and suggestions—it’s much appreciated!
I wanted to let you know that I have already managed to achieve this functionality. In Main Tile 1, I created a new bare-metal task and used a channel to send the azimuth value from the audio manager task to this new task, which is defined in io_expander.c. From there, I shared the data with the FreeRTOS task using global variables, enabling seamless communication.
Thanks again for taking the time to share your insights. Let me know if there are any best practices or further optimizations you’d recommend!
Regards,
Praveen
Thank you for your detailed explanation and suggestions—it’s much appreciated!
I wanted to let you know that I have already managed to achieve this functionality. In Main Tile 1, I created a new bare-metal task and used a channel to send the azimuth value from the audio manager task to this new task, which is defined in io_expander.c. From there, I shared the data with the FreeRTOS task using global variables, enabling seamless communication.
Thanks again for taking the time to share your insights. Let me know if there are any best practices or further optimizations you’d recommend!
Regards,
Praveen