• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 204 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CCS/CC2640R2F: Documentation error? (Bluetooth Low Energy Software Developers Guide)

CC2640R2F: CCS/CC2640R2F: Documentation error? ( SimpleLink™︎ CC2640R2 SDK User's Guide for BLE-Stack 3.x.x)

Laur Joost
Prodigy 230 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: BLE-STACK

Hi!

Raising this again:
From dev.ti.com/.../creating-a-custom-bluetooth-low-energy-application.html

This is all well and good...

except it points us to Table 17 at https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_5_10_00_02/docs/blestack/ble_user_guide/html/ble-stack-3.x/stack-configuration.html#stackconfigurablefeatures which still says


So, to get to the bottom of this, do I understand it correctly:

  1. ICall tasks in the app can use ICall to communicate to and synchronise with each other as well as the stack, so ICALL_MAX_NUM_TASKS must be the amount of tasks there;
  2. While on the Stack side, OSAL_MAX_NUM_PROXY_TASKS only refers to tasks on the app side that actually call stack (Bluetooth) functions?
  3. And as on the app side, the BLE-Stack is itself a task, by default ICALL_MAX_NUM_TASKS needs to be OSAL_MAX_NUM_PROXY_TASKS+1.
  4. If we want to add a task that uses ICall to allocate dynamic memory or synchronise with some other task besides BLE-Stack, we have to increase ICALL_MAX_NUM_TASKS, but not OSAL_MAX_NUM_PROXY_TASKS?

Please point out misunderstood points, I guess? And fix the documentation.

  • 0 in reply to Laur Joost
    TI__Mastermind 25810 points

    Hey Laur,

    I apologize this is still open. I've assigned a colleague to look into this and resolve your questions.

  • +1 in reply to Laur Joost
    TI__Guru* 93998 points

    Hi Laur,

    Thank you for taking time to report your findings.

    Laur Joost said:
    ICall tasks in the app can use ICall to communicate to and synchronise with each other as well as the stack, so ICALL_MAX_NUM_TASKS must be the amount of tasks there;

    Correct. Indirect Call Framework (ICall) is a module that provides a mechanism for the application to interface with the Bluetooth low energy protocol stack services (that is, BLE-Stack APIs) as well as certain primitive services provided by TI-RTOS (for example, thread synchronization). ICall allows the application and protocol stack to operate efficiently, communicate, and share resources in a unified TI-RTOS environment.

    Laur Joost said:
    While on the Stack side, OSAL_MAX_NUM_PROXY_TASKS only refers to tasks on the app side that actually call stack (Bluetooth) functions?

    Correct. OSAL_MAX_NUM_PROXY_TASKS refers to the number of tasks that communicate with the stack.

    Laur Joost said:
    And as on the app side, the BLE-Stack is itself a task, by default ICALL_MAX_NUM_TASKS needs to be OSAL_MAX_NUM_PROXY_TASKS+1.

    Correct. ICALL_MAX_NUM_TASKS is defined on the application side. It counts all the tasks that communicate with the stack. Due to the structure of the stack , it should always be equal to OSAL_MAX_NUM_PROXY_TASKS+1.

    Laur Joost said:
    If we want to add a task that uses ICall to allocate dynamic memory or synchronise with some other task besides BLE-Stack, we have to increase ICALL_MAX_NUM_TASKS, but not OSAL_MAX_NUM_PROXY_TASKS?

    Both ICALL_MAX_NUM_TASKS and OSAL_MAX_NUM_PROXY_TASKS should be increased when adding new ICall enabled tasks.

    To finish,

    • ICALL_MAX_NUM_TASKS and OSAL_MAX_NUM_PROXY_TASKS both default to 2. In the out of the box projects, ICALL_MAX_NUM_TASKS is overridden to 3
    • Setting a value too high for ICALL_MAX_NUM_TASKS and OSAL_MAX_NUM_PROXY_TASKS wont break the code. However it will lead to useless resources consumption.

    I am now working on modifying the documentation to avoid future misunderstanding.

    Best regards,

  • 0 in reply to Clément
    Prodigy 230 points
    Clément said:
    Both ICALL_MAX_NUM_TASKS and OSAL_MAX_NUM_PROXY_TASKS should be increased when adding new ICall enabled tasks.

    Even if the ICall tasks don't talk to the stack, only use stuff like ICall_malloc? icall.c is included in the app project and handles malloc, so I don't see why the stack ever needs to care? Or is ICall_malloc an example that doesn't need either of the task counts be incremented, as it's a utility thing that doesn't dispatch anything?

    <rant>
    Is there a definitive list of things that do or don't need registration? ICall_RegisterApp() says:

    This function must be called from the thread
    from which @ref ICall_wait function will be called.

    But ICall_wait is only ever called in the stack, and as far as I can tell, only as a way to catch the stack returning from it's main loop...

    But https://dev.ti.com/tirex/explore/content/simplelink_cc2640r2_sdk_5_10_00_02/docs/blestack/ble_user_guide/html/ble-stack-3.x/the-application.html#heap-allocation-and-management has this to say

    BLE-Stack APIs defined in icall_ble_api.h and other ICall primitive services are not available before ICall registration.

    Heap management is a "primitive service", as described by the documentation...

    I guess I still don't understand what ICall does or why it's there. It seems like a kitchen sink, that at some points duplicates a bunch of TI-RTOS functionality, but even example applications don't utilise the functionality? Like, there's ICall_createTask, but examples use plain old Task_create. It implements it's own heap for some reason. It provides aliases for a bunch of PowerCC26XX_ functions, again, not used in examples. It provides aliases for Timer functions, again unused. ICall_wait is not used, and instead examples simply Event_pend.
    But I guess that's ultimately my lack of perspective on the framework and it's historical considerations, and not relevant to the question at hand.
    </rant>
    I'll accept the previous answer as it answers the immediate question.