Why in CMSIS RTOS API compatibility layer there is a dynamic memory management ? Does it depend on something? Can it be static ?
In version v2.12 I have seen osKernelLock. How to map it to chSysLock ? It return state.
https://www.keil.com/pack/doc/CMSIS/RTO ... 1c2a4dfe12
Do you have in roadmap update API compatibility layer to CMSIS RTOS API v2 ?
CMSIS RTOS API
Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess
-
Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: CMSIS RTOS API
Hi,
chSysGetStatusAndLockX() locks and returns status, chSysRestoreStatusX() restores the status, work in both thread and ISR context.
The CMSIS API is designed to require memory allocation, CMSIS 2 is supposed to change this.
There are no immediate plans for CMSIS v2 support. It has become more like an RTOS implementation than an RTOS interface, see for example the definition of thread states, those are mandated and may not map 1:1 with the underlying RTOS. It has strayed away from being an abstract API specification. Another problem is that it has no specification and no test suite, a lot of behavior is not specified.
Probably, more than a CMSIS RTOS "skin", it would require a CMSIS RTOS implementation from scratch, not sure if I am interested in that. I would rather do a Posix and/or OSEK implementation.
Giovanni
chSysGetStatusAndLockX() locks and returns status, chSysRestoreStatusX() restores the status, work in both thread and ISR context.
The CMSIS API is designed to require memory allocation, CMSIS 2 is supposed to change this.
There are no immediate plans for CMSIS v2 support. It has become more like an RTOS implementation than an RTOS interface, see for example the definition of thread states, those are mandated and may not map 1:1 with the underlying RTOS. It has strayed away from being an abstract API specification. Another problem is that it has no specification and no test suite, a lot of behavior is not specified.
Probably, more than a CMSIS RTOS "skin", it would require a CMSIS RTOS implementation from scratch, not sure if I am interested in that. I would rather do a Posix and/or OSEK implementation.
Giovanni
Who is online
Users browsing this forum: No registered users and 9 guests