[ag-automation] application layer use cases for fieldbus stack

[Robert Schwebel]

On Wed, Jul 11, 2007 at 01:37:08PM +0200, Peter Soetens wrote:
> I wasn't talking implementation yet here, I was talking usage
> patterns.  As long as fifos are independent, you could use a lock, but
> Orocos has lock-free implementations of fifos. At the expense of
> memory.

I'll have to check the sources.

> Some points in this discussion are not clear yet to me. Are you
> looking for a 'master' and 'slave' side API?

It doesn't matter. The OSADL framework provides an infrastructure for
fieldbus drivers in general; it may be master or slave, or, as with
CANopen, neither nor. CANopen has master/slave patterns only for some
features (NMT, Sync for example), so you cannot really say which one is
the master and which one the slave.

> And what does 'LTI' stand for by the way ?

You mean LDI? Logical Device Interface, following the Homag
nomenclature. The layer application objects are coded against.

> > I'd like to be able to push the data into the TPU buffers with
> > zerocopy; that would for example mean that, for a high speed
> > ultrasound data source, an interrupt would occur, the kernel driver
> > arms a DMA and makes sure it has direct access to the TPU buffer
> > memory (for example with the user pointer method used by V4L2). That
> > would mean the transfer from hardware into the user buffer would
> > work without buring CPU cycles.
> 
> This can only work if you serialise the read access of the TPU OR only
> one thread reads the contents of the TPU. In order to get that, you
> need to use callbacks to inform multiple interested parties.

The idea was that, after an application issued lock(), it has exactly
one TPU buffer which is it's "current" TPU buffer. While it has the
lock (real lock nor not doesn't matter), it may even sleep forever; this
would only mean that this particular TPU buffer isn't available for
other threads.

> > > > - On which "changes" would you like to be woken up? Per pv? Per TPU?
> > > > Per pv_group? Why?
> > >
> > > I believe most will answer per pv, but allowing to track multiple pvs
> > > simultaneously.
> >
> > I would expect that especially in your object oriented designs, an
> > control object would be interested in changes on it's pv group?
> 
> You mean the 'drive' object?

Yes.

> Yes, I would guess so, and the user of the drive object is interested
> as well. But I thought it would be enough to enumerate the pv
> instances you are interested in and that 'groups' were just
> short-hands.

A group would specify "this application object is interested in the pvs
in this group". The problem is that different pvs in the group may come
from different fieldbusses -> different TPUs. So when should we wake up?
It's more a design issue; if we wake up on any change on the pv_group,
we would have to find out which variable was affected. If we wake up on
changes on a variable, we may wake up several times, although in reality
we would be only be interested in the fact that a logical "set" of
changes has been changed.

Looks like we need to be woken up on change of TPUs inside PV groups.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9