All of your ideas are valid designs / architectures. At the end of the
day, it is a game of balancing performance, reliability and usability.
Exporting several “mountpoints” is nice because you can use “cat” and
“echo” to easily script your stuff. But it sounds like you’re writing a
robotic control system, where the x and y work in tandem. In this case,
you’ll have lots of resource manager overhead processing the “echo” to
each mountpoint (echo > pos/x, echo > pos/y, echo > rot/x, echo > rot/y,
etc…).
Perhaps you might consider just exporting /dev/rectl that can accept
tuples [posx,posy,rotx,roty] instead?
The plugin thing is again a balancing game. Some questions to ask yourself:
- How much common data (not code) is shared between multiple types of
remote controls? (DLL vs. process)
For example, the devb-* drivers take the DLL approach to file systems
(fs-qnx4.so, fs-ext2.so, etc…) because each file system can share the
same cache. But the serial drivers are strictly separate processes
because there’s no common data that they can really share.
-
How reliable does your system have to be? How much performance are
you willing to pay? (monolithic vs. DLL vs. process)
-
How small does your system have to be?
Separate processes for each type of remote is good, if an embedded
system only uses one type at a time. Otherwise, the overhead of
duplicated code and memory may be wasteful.
A DLL plugin approach for each type of remote is good, if an embedded
system always uses lots of types at a time. In this case, you might want
a generic remote control resmgr that pulls in plugin DLLs for each type
of remote. That way, the common code (the resmgr and framework) is
stored and run once. But this gets a bit more complicated and requires
more code to manage the dynamic loading / unloading of DLLs. This would
be wasteful, if a system loads this complex master control just to pull
in one DLL.
Good luck.
Daryl Low
Jiri Novak wrote:
Hello…
as a new user (in embedded field, and QNX in particular) I started toying
with QNX 6.2NC while on christmas holidays. I read articles on QSSL and
found it so appealing, I had to write something > 
> As a “test” project I
chose to write simple remote control application.
My design is based on a resource manager, which will create devices
/dev/remctl/pos/x, /dev/remctl/rot/x etc. and an frontend application,
which will open() and read()/write() to them.
Is this the way to go in QNX? Or is there a better approach, like using
single device under /dev and using custom messages? I like “my” approach,
because it allows me to “cat /dev/remctl/rot/x” or "echo
/dev/remctl/rot/x", so testing will be easy, and one could easily “script”
whole thing >
Another thing that worries me - I want to be able to use various types of
remote controls, so instantly idea of driver “plugins” came to my mind. Is
it the correct solution? or should I decouple things more and use separate
process as a “driver-plugin”?
thanks in advance for comments…
(please be kind to naive hobbyist > 
> )