New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of RTX layer in mbed_error
#9125
Comments
mbed_error
mbed_error
@SenRamakri please review. Was this usage reported back to CMSIS_5 as a issue/pull request for adding this functionality ? I do not see this functionality covered in cmsis rtos v2. |
As of a very recent patch release of CMSIS-RTOS 2 / RTX, osThreadGetId is now documented callable from interrupt. I know this, because it came up in #8961 Documentation doesn't specify what it does from exception, but it seems that RTX's implementation does return the OS's current thread, even when called from exception context. (At some point I thought it returned 0). So The remaining points are:
The latter is never specified for any CMSIS-RTOS call, but generally it seems that if a call is documented as callable from interrupt, thread context with ISRs disabled also works, at least for RTX. If you haven't hit it already, you will soon hit the |
@JonatanAntoni please review |
The idle thread is actually something we haven't implemented in our We are actually planning to move to the standard one in some point. |
Hi @kjbracey-arm,
The current documentation of
So, yes, for RTX it simply returns And yes, it can be called from ISR context since a while (or with interrupts disabled/masked). Low-power (or tickless) operation is tricky and might be implemented very differently. Hence we never tried to abstract this functionality using CMSIS-RTOS2 APIs. The API initial intention of this API is not to fully decouple user applications from the actual RTOS implementation but allow generic middle-ware components (like com stacks for instance). Cheers, |
To me that is not 100% concrete - if called from exception context, arguably that thread isn't currently "running" - it's been preempted by the exception - so I can imagine another CMSIS-RTOS implementer doing something different. Another possible definition would be to return NULL if not called from thread context, and that would make more sense if, say, using it to implement (Been spending far too much time pinning down some of this "current thread" stuff in RTOS awareness in pyOCD recently.)
In the past I do recall there were calls that were callable from ISR, but faulted if called from thread context with ISRs disabled. I know in RTX 4 either semaphore-post or flag-set blew up. Is this a general rule now that "callable from ISR" context now permits that case? Is this stated? |
Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-341 |
As there is no direct CMSIS equivalent for most RTX functionalities used in mbed_error.c, it is not worth changing only the ones available ( |
As there has been no movement on this issue for the last 2 years I am closing it. Please re-open if it is still a valid issue. |
Description
As I mentioned in ARM-software/CMSIS_5#479 we work with
mbed-os
with a different implementation of thecmsis-os
abstraction layer based on the closed sourcethreadx
rtos.There are cases where internal details of
rtx
are used in mbed.One of the newer ones is with the introduction of
mbed_error
in one of the recent releases.It uses information of the current thread:
mbed-os/platform/mbed_error.c
Line 150 in 463a453
Note that AFAICT this information cannot be retrieved from the
cmsis
abstraction layer and the only solution for this bug is an extension of thecmsis
api.Do you think such an extension is viable?
Issue request type
The text was updated successfully, but these errors were encountered: