I take issue with some of the breaking changes that have been made in mbed-rtos rev118 and newer, and I'm sure I'm not the only one.
For starters, any targets using the ARM micro toolchain by default (AKA most of them) are now forced into a "single-thread" mode, in which you can't create any additional threads besides the main thread or even RtosTimers. What sense does that make? Why would anyone include the RTOS library just to bloat their firmware with no additional functionality? And on that note, why should we be forced to switch to the more bloated ARM standard toolchain in order to use the RTOS, when the ARM micro toolchain has worked for years?
Secondly, rev120 changed the memory model so that the main thread is now given an explicit 512B stack instead of a more traditional stack at the top of the RAM. This is going to break a lot of existing code that expects the main thread to have a larger stack than it now does, and since there's no way to customize the size of that stack (short of modifying the library), people are going to be forced to waste even more RAM creating worker threads to do tasks that the main thread would normally be doing. I don't know about everyone else, but in my own projects I run all of the "application" code on the main thread, and only use additional threads for concurrent/background stuff (e.g. USB, battery, etc). IMO that is a logical and efficient progression from a non-RTOS design, and it will no longer be possible because of this change.
Thirdly, combining "single-thread" mode with the changes to the memory model creates an asinine combination in which you only have 512B of stack to work with period.
In conclusion, I believe a lot of the smaller targets are significantly less useful as a result of these changes, and I would urge the mbed developers to seriously reconsider them.
Also posted on GitHub.
Neil Thiessen.
0
replies
I take issue with some of the breaking changes that have been made in mbed-rtos rev118 and newer, and I'm sure I'm not the only one.
For starters, any targets using the ARM micro toolchain by default (AKA most of them) are now forced into a "single-thread" mode, in which you can't create any additional threads besides the main thread or even RtosTimers. What sense does that make? Why would anyone include the RTOS library just to bloat their firmware with no additional functionality? And on that note, why should we be forced to switch to the more bloated ARM standard toolchain in order to use the RTOS, when the ARM micro toolchain has worked for years?
Secondly, rev120 changed the memory model so that the main thread is now given an explicit 512B stack instead of a more traditional stack at the top of the RAM. This is going to break a lot of existing code that expects the main thread to have a larger stack than it now does, and since there's no way to customize the size of that stack (short of modifying the library), people are going to be forced to waste even more RAM creating worker threads to do tasks that the main thread would normally be doing. I don't know about everyone else, but in my own projects I run all of the "application" code on the main thread, and only use additional threads for concurrent/background stuff (e.g. USB, battery, etc). IMO that is a logical and efficient progression from a non-RTOS design, and it will no longer be possible because of this change.
Thirdly, combining "single-thread" mode with the changes to the memory model creates an asinine combination in which you only have 512B of stack to work with period.
In conclusion, I believe a lot of the smaller targets are significantly less useful as a result of these changes, and I would urge the mbed developers to seriously reconsider them.
Also posted on GitHub.