Newbie: Priority Design for Migrating μC/OS Tasks to QNX 7.1

GENERAL Help
2

You may have needed 15 unique priorities for the uC O/S if you were running on a single core, single threaded O/S. But it’s really unlikely you need that in QNX 7.1 unless you are somehow running on a CPU like that. What kind of CPU are you planning on running on since most CPU’s these days have multi-cores and multi-thread handling capabilities so that multiple threads can be running simultaneously.

There’s no real reason to run anything at priority higher than 63. In fact very few things besides drivers run higher than 10 (ie most user tasks run at 10 and rely on the O/S to schedule things correctly). In 30+ years of QNX development on various iterations of the O/S it’s only been a handful of times I’ve needed threads higher than the default 10 (mostly due to running graphics back in the day when QNX actually supported graphics like Photon/QNX Windows).

Privileged threads are typically only needed for accessing hardware (ie think device drivers) or memory mapped I/O. Most user applications don’t require it and if you look at the doc’s for the O/S calls you make they will tell you if you need special privileges for them to succeed.

What else can you tell us about what you are porting. That would help us help answer better.

Tim

3

So, everything that Tim said, thumbs up. I/O priviilege has nothing to do with scheduling priority other than, If I remember properly, there is a ceiling on the priority of a non-priviledged thread.

There is no difference between running processes at 10 and 11 with 10 and 20. When a processor is available, QNX always picks the highest priority thread. If there is more than one process at the same priority those threads are time sliced. As a practical matter, in most system a time-slice pre-empt will or should be rare.

If you just want to recompile with as little restructuring, you can. If not, I would suggest that you look into appropriate separating of threads into separate processes. This can dramatically increase the robustness of your system at the cost of portability to non-message passing OS’s.

If you need a hardware driver, you should write it as a resource manager. Processes should interact with drivers via message passing using the standard I/O api when possible.