[ag-automation] OSADL: Working-Group I/O-Framework, Echtzeit-Ethernet

[Robert Schwebel]

Thomas,

On Sun, Dec 17, 2006 at 02:11:04PM +0100, Carsten Emde wrote:
> Zur Einstimmung auf das Thema hat Herr Gleixner eine Übersicht über die
> betroffenen Komponenten und Schnittstellen erstellt, vielen Dank!
 
Thanks for providing this outline, I think it reflects the problem very
well. Some comments:

- OSADL protocoll stacks don't have necessarily to be put ontop of
  special OSADL userspace drivers, at least some will most probably 
  directly sit ontop of kernel/glibc infrastrukture like raw sockets.

- What do you mean with FABI?

Some further remarks:

1) We have to decide which kind of I/O we want to take care of: There is
a small border between low speed, more or less static I/Os, like for
example fieldbus I/Os, and high speed data aquisition devices like PCI
measurement cards or FPGA based data sources. Both have very similar
requirements wrt. data description, but very different performance
issues. High speed sources have more in common with AV codecs than with
a PLC process variable. We don't have to aim for completeness on the
first shot, but we should definitely take into account that the high
speed people would also want to use such a framework.

2) If we go the classical process-variables-in-shared-memory way, it is
important that the shm is discoverable. There must be some service that
can provide information like the location of a pv, it's data type and
length (for arrays), description, maybe physical unit. Some devices
provide these information automatically, others have things like EDS. In
modern object oriented and distributed systems, pvs or blocks of pvs
may be hot pluggable. The whole discovery service could be an addon,
nevertheless.

3) Shms have to live on a backing store, for example battery buffered
static RAM. A framework needs to take care of the fact that there is
braindamaged hardware out there, like 8 bit FRAMs, being connected to a
16 bit CPU bus, which means that you can access the bytes at offsets 0,
2, 4 etc.

4) We have to decide if a framework will only use a "polling" model,
like processes running in cycles and doing things "once per cycle", or
if we also want to take care of "event" type activities.

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