Re: Two questions

On Monday 14 November 2005 16:52, Patrycjusz Szczepaniak wrote:
> Hello,
>
> .::1:
> template<class CPort, class SPort, class IPort, class MPort, class OPort,
> class _Extension = KernelBaseFunction> class
> ORO_ControlKernel::detail::BaseKernel< CPort, SPort, IPort, MPort, OPort,
> _Extension >
>
> BaseKernel takes as template arguments detail::DataObjectLockFreeC or
> detail::DataObjectC. They are used to define CommandPortType,
> OutputPortType, etc. but these types are not used anywhere. Could you
> please explain me what difference does using detail::DataObjectLockFreeC or
> detail::DataObjectC make? Where are these used?

In addition to what Erwin said, the kernel defines the transport mechanism, 
and different types of 'protocols' exist. The components define what data 
they transfer. When the component is loaded in the kernel, the transport 
mechanism which transports that kind of data is created by the kernel. 

>
> .::2:
> I have an Orocos application and a device driver that is a module(is a part
> of a Linux kernel). I want this Orocos application to work in a hard
> real-time. AFAIK to do that I need to write an Orocos device driver that
> will be a part of Orocos. Could you tell me how to write a device driver in
> Orocos? And how to do it so the driver could handle interrupts in RTAI?
> Mabe you could point me manuals/howtos/documents?

Orocos does not contain application specific device drivers. Comedi is 
supported because it supports lots of hardware, but normally, device drivers
is kept minimal (I see this sometimes as a drawback, since users could save a 
lot of time if Orocos supported natively more devices out of the box). 

Take a look at the canpie/ canopen package in Orocos. canpie is an (RTAI) 
kernel module, with a 'C' API to be used from LXRT userspace. 
CANPieController is an Orocos C++ class which interfaces the kernel module 
through this API. The kernel module handles interrupts and stores the data in 
a buffer, which is emptied by the C++ class.

For a specific device, see if a class in namespace ORO_DeviceInterface matches
what you need and implement that interface in your own source tree. Some 
Orocos classes will then be able to use that implementation, thus the device 
driver does not need to be part of Orocos, it can be maintained outside as 
long as you use the Orocos interfaces (in C++ these are classes with virtual 
functions).

Peter