This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

CMSIS RTOS RTX invalid thread id token ?

Note: This was originally posted on 8th August 2012 at http://forums.arm.com

Hi,

I am using Keil's RTX implementation of the CMSIS RTOS and need to communicate between an interrupt routine and a thread.  I intend to use the osSignalSet() call for this which the documentation says is suitable for use in an interrupt routine. This function takes an osThreadId parameter which I intend to store in a global variable for access by the ISR and will set it from the thread. 

My question relates to interrupts that might conceivably occur before the creation of the thread : I need a default value to use for the osThreadId which can never occur as a real thread id.  Obviously Keil's RTX comes complete with source and I am pretty sure "NULL" is a suitable value but the CMSIS RTOS documentation states that the implementation of osThreadId is implementation defined so I cannot rely on this being always true.  I have looked up and down "cmsis_os.h"but cannot find any #define like GUARANTEED_INVALID_THREAD_ID, so can anyone tell me whether this is an oversight in CMSIS RTOS, or am I missing something ?


Also, while I am here, my use above of a global variable to communicate data between an ISR and a thread is quite common but very ugly.  I am new to ARM Cortex and I wondered if there is anything I am missing in terms of alternatives ?   I am reminded of the early days of Windows when Windows drivers communicated with DOS counterparts via software interrupts in an arrangement like a kind of multi-level dumb waiter,  I can't remember what they called that arrangement but is there anything in the Cortex that would allow a similar scheme to work ?

Many thanks,

Mike
Parents
  • Note: This was originally posted on 9th August 2012 at http://forums.arm.com


    Didn't know RTX allows to create dynamic processes. ;)


    Well, the following are described in the Thread Management section of the CMSIS-RTOS API guide :

    osThreadId osThreadCreate (osThreadDef_t *thread_def, void *argument) Create a thread and add it to Active Threads and set it to state READY.
    osThreadId osThreadGetId (void) Return the thread ID of the current running thread.
    osStatus osThreadTerminate (osThreadId thread_id) Terminate execution of a thread and remove it from Active Threads.
    osThreadId osThreadCreate (osThreadDef_t *thread_def, void *argument) Create a thread and add it to Active Threads and set it to state READY.
    osThreadId osThreadGetId (void) Return the thread ID of the current running thread.
    osStatus osThreadTerminate (osThreadId thread_id) Terminate execution of a thread and remove it from Active Threads.
    osThreadId  osThreadCreate (osThreadDef_t *thread_def, void *argument)
      Create a thread and add it to Active Threads and set it to state READY.
    osThreadId  osThreadGetId (void)
      Return the thread ID of the current running thread.

    osStatus  osThreadTerminate (osThreadId thread_id)
      Terminate execution of a thread and remove it from Active Threads.

    I am using them in accordance with the example code in the reference implementation and they work fine.  I believe you may be referring to task state memory allocation which is indeed fixed in the configuration file "RTX_Conf_CM.C"  via the maximum tasks #define, but tasks themselves are dynamic and can be de and re-instantiated at will.


    Anyway, the cleanest way would be to send a message to the interrupt process to tell it the thread id.
    And of course, if the receiver gets killed, also notify the interrupt thread about that so it will discard the thread id.

    Well, that is what my original question was asking for :  how exactly do I do that ?  There is no advantage to sending a message rather than setting an ID in a public variable since sending a message means the IRQ routine needs access to a public MessageQ and that is in no way preferable (IMHO).


    BTW found this in the RTX sources:

    ...snip..

    So it is perfect clear the NULL is an ivalid thread ID esp. because it is a pointer.


    Yes, I was already aware that NULL would work and am using that.  I think it would be a nice idea to document that though, and create an alias for NULL so other implementations of CMSIS-RTOS which may not be using pointers for task ids can also declare a universally invalid task id.

    Thanks for your time and trouble in helping me with my questions,

    Mike
Reply
  • Note: This was originally posted on 9th August 2012 at http://forums.arm.com


    Didn't know RTX allows to create dynamic processes. ;)


    Well, the following are described in the Thread Management section of the CMSIS-RTOS API guide :

    osThreadId osThreadCreate (osThreadDef_t *thread_def, void *argument) Create a thread and add it to Active Threads and set it to state READY.
    osThreadId osThreadGetId (void) Return the thread ID of the current running thread.
    osStatus osThreadTerminate (osThreadId thread_id) Terminate execution of a thread and remove it from Active Threads.
    osThreadId osThreadCreate (osThreadDef_t *thread_def, void *argument) Create a thread and add it to Active Threads and set it to state READY.
    osThreadId osThreadGetId (void) Return the thread ID of the current running thread.
    osStatus osThreadTerminate (osThreadId thread_id) Terminate execution of a thread and remove it from Active Threads.
    osThreadId  osThreadCreate (osThreadDef_t *thread_def, void *argument)
      Create a thread and add it to Active Threads and set it to state READY.
    osThreadId  osThreadGetId (void)
      Return the thread ID of the current running thread.

    osStatus  osThreadTerminate (osThreadId thread_id)
      Terminate execution of a thread and remove it from Active Threads.

    I am using them in accordance with the example code in the reference implementation and they work fine.  I believe you may be referring to task state memory allocation which is indeed fixed in the configuration file "RTX_Conf_CM.C"  via the maximum tasks #define, but tasks themselves are dynamic and can be de and re-instantiated at will.


    Anyway, the cleanest way would be to send a message to the interrupt process to tell it the thread id.
    And of course, if the receiver gets killed, also notify the interrupt thread about that so it will discard the thread id.

    Well, that is what my original question was asking for :  how exactly do I do that ?  There is no advantage to sending a message rather than setting an ID in a public variable since sending a message means the IRQ routine needs access to a public MessageQ and that is in no way preferable (IMHO).


    BTW found this in the RTX sources:

    ...snip..

    So it is perfect clear the NULL is an ivalid thread ID esp. because it is a pointer.


    Yes, I was already aware that NULL would work and am using that.  I think it would be a nice idea to document that though, and create an alias for NULL so other implementations of CMSIS-RTOS which may not be using pointers for task ids can also declare a universally invalid task id.

    Thanks for your time and trouble in helping me with my questions,

    Mike
Children
No data