• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 781 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS: SYSBIOS semaphores

Guy Mardiks
Genius 4135 points


Tool/software: TI-RTOS

Hello,

I would like to create several semaphores but i need to do it in the C source code and NOT using the config file.

Can you please give a working example of how to do that (i have some idea after seeing partial generic description but most of the doc and help about semaphores uses the .cfg file)

about the semaphore params - the semaphore creates expect a pointer to the params struct but i could not find whether this pointer should be pointed to a global struct that is "connected" to the created semaphore or if it is only used to read the desired params and they are copied to the created semaphore, and after the call the params struct is not needed anymore?

Can you also  explain what exactly it the role of the eb in semaphore create - is it really needed of NULL should be sufficient?

Thanks

Guy

  • 0
    TI__Guru 55685 points
    Hi Guy,

    You can use BSP OSAL semaphore implementation: PROCESSOR_SDK_VISION_03_04_00_00\ti_components\drivers\pdk_01_10_00_08\packages\ti\drv\vps\include\osal\bsp_osal.h.

    Regards,
    Rishabh
  • 0
    TI__Guru* 96960 points
    Hi Guy,

    Here's a discussion of static vs runtime (both construct and create) creation. It has an example of Semaphore_create. processors.wiki.ti.com/.../TI-RTOS_Object_Creation_Comparison

    A couple key points about the Params. The Semaphore_Params_init() initializes the structure to default values that you can then change. The structure must not be persistent since the create (and construct) code copies the information it needs.

    The eb block was an attempt to provide more information when a failure occurred. For example, it includes a line number and file name. In hindsight, it was overkill. We have not seen an much usage of it. If you supply NULL and an error occurs, the program is terminated at the error. Great for debugging....horrible for production code. If you pass in a valid (and initialized) eb, when an error occurs, the structure is filled in and returned.

    Since we cannot just remove the parameter from the API (because of compatibility), we've added a Error_IGNORE. If there is a failure (e.g. memory allocation issue) and Error_IGNORE is used, the program does not terminate. The structure is not filled in. So you need to rely on the API return code. Here's an example of Error_IGNORE.
    temperatureHandle = Task_create((Task_FuncPtr)temperatureThread, &taskParams, Error_IGNORE);

    Note: Error_IGNORE was added a year or two ago. So your version may not have it.

    Todd
  • 0 in reply to ToddMullanix
    Genius 4135 points
    Hi, Thanks.

    about the ErrorBlock:
    If i understood you correctly, Error_IGNORE is passed as the parameter for the eb block - is that right?
    if i dont have this Error_IGNORE will it be the same if i'll just allocate ONE errorBlock variable and use it for all the semaphores (so i can ignore the errors without crashing the system)?

    Thanks
  • 0 in reply to Guy Mardiks
    TI__Guru* 96960 points

    Guy Mardiks said:
    Error_IGNORE is passed as the parameter for the eb block - is that right?

    Yes

    Guy Mardiks said:
    if i dont have this Error_IGNORE will it be the same if i'll just allocate ONE errorBlock variable and use it for all the semaphores (so i can ignore the errors without crashing the system)?

    Yes, you can have a global one. Make sure you re-initialize it after all failures though. If there is a failure, it is filled in, so you must call Error_init on the Error_Block again before re-using it.

    Todd

  • 0 in reply to Guy Mardiks
    Genius 4135 points
    Hi Todd , Rishabh, Thanks.

    What is the default settings for the BSP_OSAL_CFG_USE_STATIC macro (true or false) and what do you recommended it to be?

    Regarding the eb block if i understand correctly, it is filled if there is an error when calling one of the API (not if something happens in the background) - is that correct? if so does this mean i need to check the eb after each API call or can i rely on the return value and check the EB only if the returned value indicates a problem?

    Thanks
  • 0 in reply to Guy Mardiks
    TI__Guru* 96960 points

    Guy Mardiks said:
    What is the default settings for the BSP_OSAL_CFG_USE_STATIC macro (true or false) and what do you recommended it to be?

    Can you start a new thread on this?

    Guy Mardiks said:
    Regarding the eb block if i understand correctly, it is filled if there is an error when calling one of the API (not if something happens in the background) - is that correct? if so does this mean i need to check the eb after each API call or can i rely on the return value and check the EB only if the returned value indicates a problem?

    Yes. It is filled in by the API. If there is a return code, you use it to determine whether to re-initialize the Error_Block. Fingers crossed you have Error_IGNORE in your version. Doing the re-init is a pain.

    Todd

  • 0 in reply to Guy Mardiks
    TI__Guru 55685 points
    Hi Guy,

    BSP_OSAL_CFG_USE_STATIC should be set to TRUE. Same is the default setting.

    Regards,
    Rishabh