Yes Robert this is basically what I’ve done.
I created a header file called ADDev_idl.h that describes the messages that
must be supported by all AD Devices.
Then I wrote a C program that creates the resource manager and attaches it.
It #includes ADDev_idl.h and waits for all of the specific messages defined
in ADDev_idl.h. This program maps the messages into a bunch of set/put type
function stubs. The actual implementation of the functions is defined in yet
another h file called ADDev_ddc.h which is the DDC (vendor) specific
implementation of the functions called in ADDev_ddc.h.
So the only thing I need to create an “xyz” implemetation of a Position
device is to write a header file ADDev_xyz.h to implement the functions on
the “xyz” hardware.
Is this too complicated?
“Robert Krten” <nospam90@parse.com> wrote in message
news:a3se3l$dfq$1@inn.qnx.com…
Chris Rose <> chris.rose@viasat.com> > wrote:
Let me state first that I’m not a software engineer, so if what I’m
asking
for here is obvious, please excuse my ignorance and kindly explain.
I am working on the development of an instrument. I am designing it to
be
component oriented and I want to standardize on an interface for all
components of a given class or type. I am designing all hardware
responsible
components as Resource Managers.
As an example, say I need a component to handle Analog to Digital
converters
(ADC’s). Since I may have ADC’s by different vendors, I will have to
write
different implementations of an ADC component anytime we change vendors.
But
I want all ADC components to obey the same interface of course so the
client
never know the difference.
Excellent idea…
In a previous job where we used Windows NT and COM, we were simply able
to
write an IDL file to define the interface of the component. Then for
each
implementation of that component we simply did an “implements ADC.idl”.
The
compiler then checked our implementation against the definition of the
interface to make sure we’d implemented the complete interface.
Is there anyway do this in QNX? Right now I’m just doing it by hand so
to
speak. I’m just manually making sure that each implementation of a
device
class responds to all the same messages.
I’d go with a set of devctl()s that are well defined in terms of their
functionality, and also, importantly, in terms of their
non-functionality
on hardware that doesn’t support certain features. Once you have this
definition (i.e., a definition of all of the pieces that you will want to
control on your hardware on each and every type of A/D or D/A ever made),
then I’d write a set of test scripts for regression testing of your
resource managers.
The devctl()s will give you the “interface”, and the regression test
scripts
will verify that every new resource manager you generate conforms.
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.