• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 5262 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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 ?

Mike Davies
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
  • Note: This was originally posted on 8th August 2012 at http://forums.arm.com

    Passing thread-IDs via global variables is nothing ugly unless these are "constant".
    In your case, since threads are created on start-up the thread-id won't change later on.

    Regarding your problem, the simplest thing is to activate the interrupt from within the foreground thread.
    So it is sure the global thread-id is valid.
  • Note: This was originally posted on 8th August 2012 at http://forums.arm.com


    Passing thread-IDs via global variables is nothing ugly unless these are "constant".
    In your case, since threads are created on start-up the thread-id won't change later on.

    Regarding your problem, the simplest thing is to activate the interrupt from within the foreground thread.
    So it is sure the global thread-id is valid.

    I guess uglyness is in the eye of the beholder but I prefer to avoid global data where at all possible.

    However you are wrong to say that my threads are created at start-up and, in addition, the objects which access the hardware need to be deleted and created dynamically in my application so some form of INVALID_THREAD_ID token is required by my software.

    Thanks for your reply,

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


    I guess uglyness is in the eye of the beholder but I prefer to avoid global data where at all possible.

    However you are wrong to say that my threads are created at start-up and, in addition, the objects which access the hardware need to be deleted and created dynamically in my application so some form of INVALID_THREAD_ID token is required by my software.

    Didn't know RTX allows to create dynamic processes. ;)
    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.
    BTW found this in the RTX sources:

      if (tsk == 0) {                        // Invalid task ID
      sysThreadError(osErrorNoMemory);            // Create task failed (Out of memory)
    return NULL; 
    }

    So it is perfect clear the NULL is an ivalid thread ID esp. because it is a pointer.
  • 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