Design Patterns Commonly Used for RTOS (VXworks)

Question

Can someone help me in developing the templates commonly used for RTOS?
In VXworks, which template is preferable?

Answer 1

Is it possible to ignore the second sentence in your question? This is pointless and perhaps indicates a misunderstanding of design patterns. However, the first part is interesting. However, I would generalize it to cover real-time systems, not RTOS.

Many of the more familiar models are mechanistic, but higher-level architectural patterns are also important in real-time systems.

Bruce Powell Douglas is probably the main author on the topic of patterns for real-time systems. If you need a taste of what he has to say on this subject, read this article on Embedded.com (this is the third part of three, do not forget to read the first two, as they also relate to the topic, (1) (2) ). You can also do worse than visit Embedded.com and enter "design templates" in the search box, there are a number of articles on specific templates and general articles on this subject.

While I think you are very far from specific templates for “RTOS (VxWorks),” the templates that I used specifically for VxWorks are Facade and Adapter . Partially provide the OO API, as well as provide an RTOS agnostic abstraction layer. The resulting classes were then implemented for embOS Segger (to allow us to run smaller, cheaper, free RTOS), and both Windows and Linux to allow testing, debugging, and modeling code in a richer environment with more powerful tools.

A non-exhaustive list of many templates is provided on Wikipedia , many of which will be applicable to real-time systems. The listed concurrency patterns are most important.

Answer 2

As Mike De Simon commented, it's too general. However, here are a few things to keep in mind for RTOS (and not just for VxWorks).

• Avoid doing too much in ISR. If possible, pass part of the processing to the pending task.
• Maintain multithreading. Too much, and you have a context switch. Too few, and your solution to the problem can be complicated.

Answer 3

Another important aspect is that RTOS is predictable and understandable to the user. As a rule, you see fixed priority schedulers who do not try to be honest or adaptive, but rather exactly the same as said, and if you ruin the priorities and starve some task, let it be. The completion time of kernel operations is usually short and predictable, often documented with the worst execution time.