[ag-automation] FDDI (Fieldbus Device Driver Interface) Update

[Robert Schwebel]

On Mon, Jun 18, 2007 at 08:03:57PM +0200, Robert Schwebel wrote:
> I've added this revision and all the earlier ones to the OSADL SVN
> repository, at this location:
> 
> 	https://www.osadl.org/svn/osadl/software/fieldbus-framework

... and a first autotoolized version as my personal playground is here:

	https://www.osadl.org/svn/osadl/software/fieldbus-framework/fddi-20070618-1-ptx1

It compiles your code into a shared library.

> > - The implementation in fddi.c is just a prototype, to get the idea
> >   how it is working. I know that there are a lot of improvements like
> >   error handling, more dynamic data structures etc.
> 
> Yup. I can add some makefiles, to make it possible to build it easily.

See above.

> > The following things are planned to be delivered in the next few days:
> > 
> > - an implementation proposal for the fddi
> > - a definition of configuration profile for a field bus protocol
> >   (which should we use as a first example? We at 3S have definitions for
> >   CANopen, Profibus, EtherCat and SERCOS III)
> 
> Some use cases would also be a good thing, just to get the picture how
> these things are supposte to work.

I'm still wondering about the usecases and about how the abstraction is
supposed to be used. Let's take an example, to make things more clear.
As CANopen is the fieldbus I know most about, let's suppose we have a
company called "Industral Mesozoicum Inc.", building a state-of-the-art
industrial code quality CANopen stack. Meso' Inc. has invented their
very own API to their stack and they now get the task to port it into
the OSADL fieldbus framework.

Now we have two things: an API which makes it somehow possible to bring
up and manage the stack; basic NMT stuff is probably abstractable via
your cmd_device function, but how about things like sync, or other very
CANopen specific things like firmware download? They are an application
speciality, and they are very CANopen specific. Then PDO mapping. PDOs
somehow have to be mapped into your transportation units. How? We need a
description for that, and we need well defined rules (I avoid the word
profiles here on purpose).

Then, when we have the transportation units equiped with the payload,
you have an embedded description of your process variables inside the
tpu. What about data types? Name, size and offset is probably not enough
on the application level, we need things like unsigned/signed 8, 16, 32
bit integers plus probably floating point, and while being there I'd
like to be able to attach more sophisticated things to a process
variable, like physical units, min/max range etc.

How are things working on the application layer? When I define my
business object ontop of fddi, something like a motion controller, I'd
like to specify a mapping between different tpus and things like high
level process variables. But if we need a high level mapping mechanism
anyway, why invent a second mapping between CANopen and the tpus? That's
duplicate work, and not only duplicate, because each and every CANopen
stack provider would have to do that again, not only our brave Meso'
Inc. guys.

What I have in mind is more like a generic I/O object model, with an
inherritance model between generic and specific bus objects. Think OO,
not microcontroller. For example, CANopen and PowerLink share a common
abstraction of an object dictionary; so a framework would need an
objdict abstraction _inside_ the fieldbus layer, plus a generic layer
ontop of that which deals with these entries and makes PDO mapping
possible in a way that the actual code can be runtime/compiletime-
generated from a model. It must be made sure that, for each application
scenario, the necessary initialization code can be provided in a bus
specific way (like setup code for CANopen sync), without violating the
general concept of layers calling only the layers below them and without
coding application specific stuff into stack layers.

Seeing all this, I'm wondering if it wouldn't be easier to start with
the application layer, above fddi. I'm not sure if somebody already had
a look at what our libpv provides, but I suppose it could be a start for
the layer above fddi:

http://www.pengutronix.de/software/libpv/download/

But nevertheless, it may also happen that I just totally don't
understand yet how these fddi things are meant to work, so I'm very
interested in learning more about it.

The fddi model discussed here has quite some good ideas which we should
definitely incorporate. But there are quite some open questions, and I
suppose that we probably better organize another face-to-face meeting
with the automation working group to discuss them. Let's talk about that
on Thursday.

Regards,
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