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....
What you write is very similar to my history. Both in timescale and experience.
I am currently looking into a project using one of the new ST Cortex M7 parts but find the packages really annoying. To me, having understanding of the whole project code is key to project confidence.
Unfortunately, packages like these seem to be the way of the modern development and seems particularly suited to the 'bolt it together' generation.
So far, with projects stretching to the LPC800 series, I've intentionally not used the packages but have instead read the manufacturers reference material and written drivers myself. It could be argued that this is simple stubbornness and a case of reinventing the wheel; but, to date, code done in this way has worked well.
But it seems inevitable that the more capable chips will require that final step :(
Totally agree! I have been playing around with the middleware (filesystem and network) and it all seems very nice and well packaged. BUT, I'm a little concerned that a lot will be "hidden" and that I no longer have control over it all... Maybe we are just plain old ;)
As a side note, when looking at the CMSIS RTOS, it seems that you are no longer able to supply your own stack memory when creating a thread, but rather relying on that the memory is used from a "global pool" of stack memory. I hope not thats the case, I need (for a couple of reasons) to be able to supply my own chunck of memory when starting threads....
Answering my own question regarding stacks, in RTOS2/RTX5 it is now possible again to do this :) http://www.keil.com/pack/doc/CMSIS/RTOS2/html/ThreadStack.html
I guess a question is also if the filesystem (NAND, NOR and SD card) are "production ready", until now we have used a 3rd party for this, but it could be interesting if Keils implementation is in fact "working"....
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.
More and more solutions are provided by manufacturers, and each one is different from the others. Don't know how to catch up.
... -> LPCXpresso -> MCUXpresso -> Qualcomm to Acquire NXP -> ???
The MCUXpresso IDE merges the best of the popular LPCXpresso and Kinetis Design Studio IDEs into one easy-to-use integrated development environment for Kinetis and LPC MCUs.
globenewswire.com/.../NXP-Announces-MCUXpresso-Software-and-Tools-Unifies-Development-Support-for-its-Microcontroller-Powerhouse-Portfolio.html
Well, I have dug into this modern "CMSIS stuff" and Keils RTX5/RTOS2 etc. It seems mostly logical, but one must keep focused as there are a lot of old information/previous versions etc that one have to steer around. I had a couple of questions, these where answered with lightning speed by technical support.
Currently trying to get the file system to run on a MCB1500 board (SD card over SPI), but so far no success (I'm getting fsMediaError) on the fsMount(). It seems from the eventrecorder (which is super nice!) that there is a "BlenWriteError". I will take this up with support also...