• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 5324 views
  • Users 0 members are here
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
Parents
  • 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
Reply
  • 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
Children
No data