Help on System Design (To be Resource Manager or Not to be)

Please give some comments on my design:

I’m starting a new project for a Automation System which consists of some hardware devices such as RF Generator, Motor and DIO cards etc…

I wonder if it is a good approach to create a Resource Manager for each major component (e.g. Motor, IO Card, RF Generator etc…) of our system. Each Resource Manager will be running as an individual Process (Trying to avoid multithreading). Then I can have a “Master” Process to dispatch the required “I/O commands” to these Resource Managers.

Roger

We even use resource manager architecture to check “user process” statuses and data. And of course it’s usefull for different devices, just don’t too complicate them. =)

I vote ‘yes’

From what I can see, this is a sound design.

We are using QNX to program many devices as Digital/analog Cards,
devices which have serial ports, encoder cards (to read the position of
motors) and so on.

Before, we used to use a process with many threads or processes that werent drivers. Now we use drivers normally.

When you use multithreading it is not so easy to make changes to your
source code because any change you make affect to all the threads in the process.

When you use drivers, and if you have the interface to the driver well
documented, things at the start are harder, I mean to have to write the
driver (not so easy for a newbie as I was), but there are many advantages. Many people can work on the project, writing each one a
driver and the changes that each one made, affect only to the driver.

To communicate with a driver is really easy, you just need an open, write
and so on.

I have used both and I am “PRO DRIVER”.

I hope it helps, sorry for my english.

I recommend you this article (it helped me a lot)

qnx.com/developer/articles/i … le=nov2900

Hi

Your design is sound, but I’d like to add some inputs.

If you’re looking at high-frequency servo loops, I’d suggest the old multi-threaded design. Its complex, but has lesser overheads and if you design it right, no other thread is affected. I’ve used this approach by converting all the devices into objects, and it works well.

Remember, in a MT (multi-threaded) design, reading an encoder is just an (inlined) function call. in a resource manager approach its a message requiring at least two context switches, message parsing and lots of function calls.

When you use drivers, and if you have the interface to the driver well
documented, things at the start are harder, I mean to have to write the
driver (not so easy for a newbie as I was), but there are many advantages. Many people can work on the project, writing each one a
driver and the changes that each one made, affect only to the driver.

If you’ve hardware constraints, go with MT design, if not then follow the resource manager path, it offers great modularity and ease of development.

First of all, let me say that I have a good deal of respect for mritun and value his opinion highly, but on this topic I am compelled to disagree.

If you want your code to be error-free quickly, be stable and easy to maintain, stay away from MT if at all possible. Hardware constraints are not a valid argument as a resource manager (if there is more than one) will probably end up being smaller overall due to code sharing (unless the application designer factors all their common code into a shared object which implies duplication of effort).

A single threaded driver is more often than not, more efficient than a MT driver (faster and smaller), since there are fewer context switches in a well designed ST driver. I understand that mritun was referring to the overall number of context switches necessary to move data between the application and the hardware, but this is argument is (more often than not) a red-herring, since (for most designs) the message passing between the driver and the application is a small percentage of the computing time relative to the rest of the application.

MT is required when you need a degree of parallelism greater than that supported by the hardware you are writing a driver for. The classic example of this is a disk filesystem. With a disk filesystem the presence of cached data means that you can reasonably service parallel requests to data that “appears” to be on the device (i.e. valid cache entries), but is not actually on the device, and therefore there will be no asynchronous events (interrupts) generated to provide a ST driver with easily available scheduling information that it can use to provide parallelism to clients. In this case it makes sense to use the operating systems built-in scheduler to provide the “logical” scheduling rather than write your own internal scheduler.

IMO before you select a MT design, you need to be convinced that the design rigor required to be applied to insure correct synchronization, requires less overall effort than the alternative, or that the alternative will simply not produce a sufficiently fine grain of parallelism.

That’s the way to go IMHO. That means you can stop/stopthe IO Card driver at will without problem (most of the time). The RF Generator may crash by your IO card is still working. If it all would be in a single MT program, you wouldn’t get that robustness. And hell the IO Card driver could sit in another machine and it would still work (because message can go across network).