Hi,
I'm currently using orocos with 2 IO boards and 2 drivers of my own. For
the simplest driver I had made my own DigitalInInterface and etc. I also
implemented my own IOComponent.
Now I'm implementing the second one and I don't see the advantages of using
that IOComponent. It looks like it is simpler and easier to implement a
simple taskcontext to represents my second drivers.
What is the advantage of using IOComponent and Interface things?
Thanks
Usage of IOComponent versus taskContext
On Monday 02 March 2009 21:18:47 Simon Pelletier-Thibault wrote:
> Hi,
>
> I'm currently using orocos with 2 IO boards and 2 drivers of my own. For
> the simplest driver I had made my own DigitalInInterface and etc. I also
> implemented my own IOComponent.
>
> Now I'm implementing the second one and I don't see the advantages of using
> that IOComponent. It looks like it is simpler and easier to implement a
> simple taskcontext to represents my second drivers.
>
> What is the advantage of using IOComponent and Interface things?
When this component was developed, we had this vision that once a number of
device drivers were supported by the RTT Device Interface, it would be
convenient to have a quick-setup component for getting started. However, the
IOComponent fails in these areas:
* It doesn't know any devices by itself, so you need to setup the devices
anyway in another component ('CreateDevices'), using the C++ global naming
service and then let the IOComponent find it. So you're doing the setup anyway.
* It doesn't allow to sample various channels at various times. You'd need to
instantiate multiple IOComponents to have a reasonable complex application
working.
* Only little devices (mainly Comedi) are supported under the RTT Device
Interface.
* The Device Interface itself is very limiting. Often, your device drivers
offer features you'd like to use, but which are not provided by the DI. So you
need to access your device driver directly anyway.
For these reasons, it's easier to 'just' access your drivers from a custom
'Adaptor' component and by-pass the whole DI.
The only part for which we use the DI is to access Comedi in a C++-way. It was
suggested earlier to make a variant of the IOComponent, say the
ComediComponent, and let that component create and manage Comedi devices.
Peter
Usage of IOComponent versus taskContext
Okay that's perfect,
thanks
On Tue, Mar 3, 2009 at 4:29 AM, Peter Soetens <peter [dot] soetens [..] ...> wrote:
> On Monday 02 March 2009 21:18:47 Simon Pelletier-Thibault wrote:
> > Hi,
> >
> > I'm currently using orocos with 2 IO boards and 2 drivers of my own. For
> > the simplest driver I had made my own DigitalInInterface and etc. I also
> > implemented my own IOComponent.
> >
> > Now I'm implementing the second one and I don't see the advantages of
> using
> > that IOComponent. It looks like it is simpler and easier to implement a
> > simple taskcontext to represents my second drivers.
> >
> > What is the advantage of using IOComponent and Interface things?
>
> When this component was developed, we had this vision that once a number of
> device drivers were supported by the RTT Device Interface, it would be
> convenient to have a quick-setup component for getting started. However,
> the
> IOComponent fails in these areas:
>
> * It doesn't know any devices by itself, so you need to setup the devices
> anyway in another component ('CreateDevices'), using the C++ global naming
> service and then let the IOComponent find it. So you're doing the setup
> anyway.
> * It doesn't allow to sample various channels at various times. You'd need
> to
> instantiate multiple IOComponents to have a reasonable complex application
> working.
> * Only little devices (mainly Comedi) are supported under the RTT Device
> Interface.
> * The Device Interface itself is very limiting. Often, your device drivers
> offer features you'd like to use, but which are not provided by the DI. So
> you
> need to access your device driver directly anyway.
>
> For these reasons, it's easier to 'just' access your drivers from a custom
> 'Adaptor' component and by-pass the whole DI.
>
> The only part for which we use the DI is to access Comedi in a C++-way. It
> was
> suggested earlier to make a variant of the IOComponent, say the
> ComediComponent, and let that component create and manage Comedi devices.
>
> Peter
> --
> Peter Soetens -- FMTC -- <http://www.fmtc.be>
>