• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 5264 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
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