[ag-automation] LDI-Interface

[Robert Schwebel]

On Fri, Jul 06, 2007 at 08:26:54AM +0200, Thomas Rothfuss wrote:
> A caller has to do following steps:

Thanks for posting your proposal. Please, when posting code, always give
us a statement about the license this code is released under. For the
code we already have in the fieldbus repository, we've taken GPL plus
Link Exception, so that would be the prerequisite for integrating the
code into the repository.

> 1. Set the callback functions for the kind of responses needed:
> 
>     fapia_set_callback_for_parameter_read_response_callback (
>         fapia_parameter_read_response_callback)
> 
>     fapia_set_callback_for_parameter_write_response_callback (
>         fapia_parameter_write_response_callback)
> 
>     fapia_set_callback_for_parameter_info_response_callback (
>         fapia_parameter_info_response_callback)

Could you elaborate on the details of this read/write/info abstraction?
How does it map to different fieldbusses, and how is it supposed to be
used? I assume the async interface is tricky to be done in a fieldbus
independend way (in fact I cannot really imagine that it is possible at
all).

Let's start some discussion how that fits into the abstraction we
already have in the FDDI. There are these objects:

- fddi_iface:  interface (access object for a fieldbus)
- fddi_tpu:    transportation unit (for process data)
- fddi_device: physical or logical devices (like a bus coupler)
- fddi_param:  parameters (key/value)
- fddi_pv:     process variables (description of payload

At the moment, an fddi_device has these methods for async communication:

extern int fddi_dev_read_async(fddi_device_t *dev /* FIXME */);
extern int fddi_dev_write_async(fddi_device_t *dev /* FIXME */);

So this would probably be the place where we would integrate the
structures.

> 2. Call the init function:
> 
>     fapia_init (argc, argv, "CNC")
>     Runtime parameter could be "-FAPIADebugLevel <debug level>"

I'd change that into an interface which fits better into the object
oriented design we have for the rest of the code. But that's details; I
suppose that doing it in the same way as with the FDDI is a good method:
I refactored the original code in a posix like way and put it back into
the repository for review.

> 3. Do the communication
> 
>     fapia_parameter_read_request (...)
> 
>     The FAPIA-Lib has own threads. Within such a thread the callback set
>     by the application (in point 1 it's
>     fapia_parameter_read_response_callback)is called. Within this
>     function the application can handle the response.
> 
>     Write and Info requests are similar.

If you already have the code as a lib, would you be able to post it
somewhere as a reference?

> A callee has to do following steps:
> 
> 1. Set the callback functions for the kind of requests which are expected:
> 
>     fapia_set_callback_for_parameter_read_request_callback (
>         fapia_parameter_read_request_callback)
> 
>     fapia_set_callback_for_parameter_write_request_callback (
>         fapia_parameter_write_request_callback)
> 
>     fapia_set_callback_for_parameter_info_request_callback (
>         fapia_parameter_info_request_callback)

What is a "parameter" in your abstraction, for example for CANopen?

> 2. Call the init function:
> 
>     fapia_init (argc, argv, "CAN1")
>     Runtime parameter could be "-FAPIADebugLevel <debug level>"

Will probably be intergrated into the already existing code; the async
interface is, according to my understanding, just a part of the FDDI.

> 3. Do the communication
> 
>     When a caller sends a request the appropriate callback function
>     which was set by the callee is called (e.g.
>     fapia_parameter_read_request_callback (...)).
> 
>     In this example the CAN1-Process may get a read request. It then
>     reads the values from the CAN-bus (this may happen in the
>     callback-function) and sends the result to the caller by function
> 
>     fapia_parameter_read_response (...)
> 
>     Write and Info are similar.

Are you talking about plain CAN here, or about CANopen? The FDDI and
higher layers never see plain CAN messages, and for CANopen, how would
that map to for example SDO transfers?
 
> //=============================================================================
> /**
>   *  @file    FAPIA.h
>   *
>   *  $Id$
>   *
>   *  @author Thomas Rothfuss <thomas.rothfuss at homag.de>
>   */
> //=============================================================================

Please insert the GPL+LinkException header here; I've posted it some
mails ago (please tell me if I should resend).

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