Hello,
If you violate RTX's rule that you are not to mix the interval and delay timers (thus a task that needs to wake-up at a certain interval is blocked), RTX will try to fix the periodic task's schedule but waking it up sooner that expected. It might take anything between 1 and 10 cycles until the original period is restored. It is possible to call "os_itv_set" again to fix it immediately, though.
No, I am talking of the skills required by the developer to read and understand the documentation
You start sounding like Jack Sprat (that is not necessarily an offense). Aha. I hope I don't need to tell you how complex and big these programs can become. The failure above can be introduced by someone that knows the rules and the software by heart, but there is a (asynchronous) path in the program that introduces this failure, and it is unlikely to occur very often. If and when one has expensive stuff or even lives at the tip of his/her fingers, I would like to have some guarantees that SOME safeguards are in place. Don't faint, Steve :-)
"The failure above can be introduced by someone that knows the rules and the software by heart, but there is a (asynchronous) path in the program that introduces this failure, and it is unlikely to occur very often."
Sorry Tamir, but that simply sounds like a badly designed project.
Stunned Steve,
It did not happen yet, and the project is not badly designed.
But, surely, such a person would be aware of this possibility and, therefore, take steps to ensure that it can't happen - by design...?
That's exactly right Andy - the design of the operating system in question :-)
No, the design of the OS says, "you must not do this" - so it is up to you to ensure that your application cannot do it.
eg, have a flag to tell you when you're using one type of timer, and check that flag before using the other type
Andy, I believe your latest reply is a summary of the philosophical differences between me and the rest. As stated once, "arrogance and self awareness seldom go in hand in hand". People are flawed. No matter how smart you are or think you are, you will make mistakes, some of them lurking, waiting to bite you when you least expected. How much ROM space will it cost to implement a simple test and return a error code in necessary, just to indicate "there is something wrong here and it could be dangerous"? Will it delay execution by a too a significant amount of time? How many accidents can be prevented? How many lives can be saved?
For some "normal" OS, there are checked builds - special versions of the OS that incorporates extra tests to try to catch problems in the OS and in the user applications.
For an RTOS, it can be hard to make augmented versions, since extra code will take extra time, and possibly change the balance of the application. Of course, it would be good if every single application with real-time requirements was always fast enough that there was exctra cycles to spare for run-time testing.