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

Keil RTOS (old style) versus CMSIS RTOS....

Former Member
Former Member

I know I'm an old guy (software developer for more than 35 years), I have been using Keil RTOS for ages (13+ years on ARM, before that a zillion years on 8051) and have so far been satisfied with it, and most importantly learned to live with the RTOS and its shortcomings...

In this "CMSIS" age of things, I wonder if I should move on to the "brand new modern way" of using the RTOS? One thing I REALLY hate is the "package idea" of UV5, all this builtin handling of things makes me shiver... Basically its because I feel that I loose control...

Am I right, or should I just pull myself together and jump on the CMSIS wagon and embrace the wonderful new world?
What is your experience with this ??

Maybe I'm just being paranoid....

Parents
  • I have stayed away from plugins.

    I like to own 100% of the code and have it stashed in the source code management system.

    And to get the last out of a processor, I really do need to read through the processor data sheet/user manual multiple times - regularly rereading different sections for the full lifetime of the software. It takes much more time to learn the processor (which is an obligatory task) than it takes to write the actual driver code.

    Another aspect is that own code allows balancing of what to do directly in the low-level driver and what to do later to best fit the specific latency requirements, indirectly giving different driver code different priority.

Reply
  • I have stayed away from plugins.

    I like to own 100% of the code and have it stashed in the source code management system.

    And to get the last out of a processor, I really do need to read through the processor data sheet/user manual multiple times - regularly rereading different sections for the full lifetime of the software. It takes much more time to learn the processor (which is an obligatory task) than it takes to write the actual driver code.

    Another aspect is that own code allows balancing of what to do directly in the low-level driver and what to do later to best fit the specific latency requirements, indirectly giving different driver code different priority.

Children