Hello,

I've gone through the io/dio48 module and made it configurable (I hope that's OK with you Curt - this used to be your module...).

It now gets the points it should input/output, the direction and the device filenames it should use from the config. The filenames have defaults, but the specification of the mapping is mandatory.

I guess it's an example of how I intended the config routines to be used; I'm never quite sure whether I'm making things clear or confused

Incidentally, I realized while I was changing it that half the old code used opposite directions to the other half - either there was a fairly
serious bug in it, or I've completely misunderstood *something*.

Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Huh? I'm confused.

Hi Jiri

I hope you used the 48h driver, that's the one I have been using. I have a small problem with making the driver specific to lplc and I'm curious why that wouldn't go in the IO process. Convince me it's a good idea to break a standard
interface and replace it with a project specific one. What is it that you can't do with a
standard char driver interface? This is basic UNIX philosophy, it's standardized for a reason, that being that you can use general file routines and interchange drivers to a reasonable extent. The ioctl thing _is_ a little kludgey but at
least it's standardized. I'm lothe to break basic and long standing standards. I hope I don't sound too crabby and dogmatic.

regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Jiri Baum:
> > I've gone through the io/dio48 module and made it configurable (I hope
> > that's OK with you Curt - this used to be your module...).

Curt Wuollet:
> I have a small problem with making the driver specific to lplc and I'm
> curious why that wouldn't go in the IO process.

That's where it is. The io/dio48 is the I/O process for the dio48H driver.

The io directory is where the various I/O processes live; we may have a generic I/O process in the future or we may not, but for now this one's dio48-specific.

Actually, now that I look in the driver, I see the number of channels can vary, so that should be configurable in the io process too; but not today. Once that's done, it'll be a generic 8255 I/O process, because it can already take the device names from the config and it'll then be able to handle any number of 8255s on any combination of boards.

> Convince me it's a good idea to break a standard interface and replace it
> with a project specific one.

I can imagine that with something like serial-connected I/O it'd be easier to just open /dev/ttyS0 and handle the protocol from userspace. But that's not really breaking the standard either - it's just the same standard on an inter-device level.

Some existing I/O programs have a command-line interface - that's probably the next one to support, because it'll be easy (for outputs at least).

> I'm lothe to break basic and long standing standards. I hope I don't
> sound too crabby and dogmatic.

No, that's OK - no problem. Especially since we seem to agree


[rearranging the order here]

Jiri Baum:
> > Incidentally, I realized while I was changing it that half the old code
> > used opposite directions to the other half - either there was a fairly
> > serious bug in it, or I've completely misunderstood *something*.

Curt Wuollet wrote:
> Huh? I'm confused.

I think the points i1 to i24 were ioctl()'d as PORT_OUTPUT, while q1 to q24 were PORT_INPUT, or something like that.

Sorry, I wrote the above just after working in the code where I used "direction" to mean "input or output?". I'll put an extra comment in the
code to explain what I mean. (Done, but not yet uploaded.)


Jiri
--
Jiri Baum <[email protected]>
Windows is not popular. Windows is *widespread*. Linux is popular.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Jiri Baum wrote:

> Jiri Baum:
> > > I've gone through the io/dio48 module and made it configurable (I hope
> > > that's OK with you Curt - this used to be your module...).
>
> Curt Wuollet:
> > I have a small problem with making the driver specific to lplc and I'm
> > curious why that wouldn't go in the IO process.
>
> That's where it is. The io/dio48 is the I/O process for the dio48H driver.
>
> The io directory is where the various I/O processes live; we may have a
> generic I/O process in the future or we may not, but for now this one's
> dio48-specific.
>
> Actually, now that I look in the driver, I see the number of channels can
> vary, so that should be configurable in the io process too; but not today.
> Once that's done, it'll be a generic 8255 I/O process, because it can
> already take the device names from the config and it'll then be able to
> handle any number of 8255s on any combination of boards.
>
> > Convince me it's a good idea to break a standard interface and replace it
> > with a project specific one.
>
> I can imagine that with something like serial-connected I/O it'd be easier
> to just open /dev/ttyS0 and handle the protocol from userspace. But that's
> not really breaking the standard either - it's just the same standard on an
> inter-device level.

I don't have a problem with using userland services from userland. Serial is one that would be easier from userland, Ethernet is another. There it would make less sense to interface directly to a driver where we have protocol or discipline layers available. We may need to go low level to do some serial protocols correctly, they have timing requirements that aren't
addressed by the standard termio. Ethernet from kernel code would be evil and they've changed the stack every release I believe.

> Some existing I/O programs have a command-line interface - that's probably
> the next one to support, because it'll be easy (for outputs at least).
>
> > I'm lothe to break basic and long standing standards. I hope I don't
> > sound too crabby and dogmatic.
>
> No, that's OK - no problem. Especially since we seem to agree

Sorry Jiri, I misunderstood module to mean the driver, which is a loadable module. Good thing I can still type with foot in mouth. When I have a high speed connection tomorrow I'll take a look. We haven't yet dealt with the many IO procs/ single IO proc issue but I expect reality will point the way on that. There are advantages either way.

Regards

cww

______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc