Digital I/O in IIO

Digital I/O in IIO

[George McCollister]

In many industrial applications it's common to mix digital (binary)
and analog I/O. In many cases digital input modules have change
buffers and sometimes event time stamping capabilities. While the gpio
subsystem can support software timestamping and buffering it doesn't
fit well for many industrial digital applications where the host
process reads buffered digital samples or events from input modules.

Would anyone appose or support the addition of digital channel type or
suggest an alternative path to supporting this use case?

A possible alternative is to use 1 bit for storage and use voltage for
type. For instance a 16 channel 24V DC Input module would present 16
input voltage channels with 1 bit of storage each. 0 would correspond
to 0VDC and 1 to 24VDC.

Cheers,
George McCollister
Software Architect
NovaTech LLC

Re: Digital I/O in IIO

[Matt Ranostay]

On Thu, Apr 6, 2017 at 7:24 AM, George McCollister
<george.mccollister@gmail.com> wrote:
> In many industrial applications it's common to mix digital (binary)
> and analog I/O. In many cases digital input modules have change
> buffers and sometimes event time stamping capabilities. While the gpio
> subsystem can support software timestamping and buffering it doesn't
> fit well for many industrial digital applications where the host
> process reads buffered digital samples or events from input modules.
>
> Would anyone appose or support the addition of digital channel type or
> suggest an alternative path to supporting this use case?
>
> A possible alternative is to use 1 bit for storage and use voltage for
> type. For instance a 16 channel 24V DC Input module would present 16
> input voltage channels with 1 bit of storage each. 0 would correspond
> to 0VDC and 1 to 24VDC.

I don't think IIO_VOLTAGE should be used for this since it is against
the ABI definition.
At the worse it should be reported as 0V and 24V, but I think using
the events is a better solution.

IIO_EV_DIR_RISING  -> 24V
IIO_EV_DIR_FALLING -> 0V


>
> Cheers,
> George McCollister
> Software Architect
> NovaTech LLC
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Digital I/O in IIO

[Jonathan Cameron]

On 07/04/17 07:21, Matt Ranostay wrote:
> On Thu, Apr 6, 2017 at 7:24 AM, George McCollister
> <george.mccollister@gmail.com> wrote:
>> In many industrial applications it's common to mix digital (binary)
>> and analog I/O. In many cases digital input modules have change
>> buffers and sometimes event time stamping capabilities. While the gpio
>> subsystem can support software timestamping and buffering it doesn't
>> fit well for many industrial digital applications where the host
>> process reads buffered digital samples or events from input modules.
>>
>> Would anyone appose or support the addition of digital channel type or
>> suggest an alternative path to supporting this use case?#
>>
>> A possible alternative is to use 1 bit for storage and use voltage for
>> type. For instance a 16 channel 24V DC Input module would present 16
>> input voltage channels with 1 bit of storage each. 0 would correspond
>> to 0VDC and 1 to 24VDC.
Pulled Linus Walleij in as he's always interested in these discussions.

Firstly, 24V for example could be made explicit by just having _scale set
appropriately. Often these units aren't that simple, but it'd be a start!

If we are dealing with data sampled on a regular clock (so like an ADC
sample) then we should indeed support it as a 1 bit voltage.  Mostly this
is easy to do, the fun question on this has always been what to do about
demuxing the buffers. Do we repack individual bits or not?  Don't really
want to store them in 8 bits each just to make repacking easy.

Hence we'd probably have to start allowing storage_bits values of less
than 8 (probably only for the 1 bit case initially!) and add the logic
to the demux to handle this. 

One previous suggestion on this was to have 1 bit values behave differently
from others, in that we don't repack them in the demux but just pass
on the byte they are contained within.  I don't like the semantics of
doing it that way but it would be a bit less code. I think if we are
going to do this we need a bit repacker in the demux.

> 
> I don't think IIO_VOLTAGE should be used for this since it is against
> the ABI definition.
> At the worse it should be reported as 0V and 24V, but I think using
> the events is a better solution.
> 
> IIO_EV_DIR_RISING  -> 24V
> IIO_EV_DIR_FALLING -> 0V
Events are certainly an option here, particularly if we have
a timestamp to go with them...

So your classic PLC had two types of input (which may well share
a given actual pin)

1) Scanned inputs - usually on something like a 5ms timer.
2) Capture inputs - these log a timestamp - and sometimes other things
such as a the position of than encoder unit at that instance (lets ignore
that one for now!)

Scanned inputs are as above - easy up to the demux extension needed.

Capture units either:
1) Events
2) Triggers driver buffers - allowing other channels to be sampled at the
capture instance if supported. Issue here is you then need one buffer per
capture input - plus point is that unlike a typically PLC you have a fifo
built in rather than having to shuffle these off before the next one shows
up.

Hmm. Non obvious what is the best approach.

Jonathan
> 
> 
>>
>> Cheers,
>> George McCollister
>> Software Architect
>> NovaTech LLC
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Digital I/O in IIO

[Lars-Peter Clausen]

On 04/08/2017 05:49 PM, Jonathan Cameron wrote:
> On 07/04/17 07:21, Matt Ranostay wrote:
>> On Thu, Apr 6, 2017 at 7:24 AM, George McCollister
>> <george.mccollister@gmail.com> wrote:
>>> In many industrial applications it's common to mix digital (binary)
>>> and analog I/O. In many cases digital input modules have change
>>> buffers and sometimes event time stamping capabilities. While the gpio
>>> subsystem can support software timestamping and buffering it doesn't
>>> fit well for many industrial digital applications where the host
>>> process reads buffered digital samples or events from input modules.
>>>
>>> Would anyone appose or support the addition of digital channel type or
>>> suggest an alternative path to supporting this use case?#
>>>
>>> A possible alternative is to use 1 bit for storage and use voltage for
>>> type. For instance a 16 channel 24V DC Input module would present 16
>>> input voltage channels with 1 bit of storage each. 0 would correspond
>>> to 0VDC and 1 to 24VDC.
> Pulled Linus Walleij in as he's always interested in these discussions.
> 
> Firstly, 24V for example could be made explicit by just having _scale set
> appropriately. Often these units aren't that simple, but it'd be a start!
> 
> If we are dealing with data sampled on a regular clock (so like an ADC
> sample) then we should indeed support it as a 1 bit voltage.  Mostly this
> is easy to do, the fun question on this has always been what to do about
> demuxing the buffers. Do we repack individual bits or not?  Don't really
> want to store them in 8 bits each just to make repacking easy.
> 
> Hence we'd probably have to start allowing storage_bits values of less
> than 8 (probably only for the 1 bit case initially!) and add the logic
> to the demux to handle this. 
> 
> One previous suggestion on this was to have 1 bit values behave differently
> from others, in that we don't repack them in the demux but just pass
> on the byte they are contained within.  I don't like the semantics of
> doing it that way but it would be a bit less code. I think if we are
> going to do this we need a bit repacker in the demux.
> 
>>
>> I don't think IIO_VOLTAGE should be used for this since it is against
>> the ABI definition.
>> At the worse it should be reported as 0V and 24V, but I think using
>> the events is a better solution.
>>
>> IIO_EV_DIR_RISING  -> 24V
>> IIO_EV_DIR_FALLING -> 0V
> Events are certainly an option here, particularly if we have
> a timestamp to go with them...
> 
> So your classic PLC had two types of input (which may well share
> a given actual pin)
> 
> 1) Scanned inputs - usually on something like a 5ms timer.
> 2) Capture inputs - these log a timestamp - and sometimes other things
> such as a the position of than encoder unit at that instance (lets ignore
> that one for now!)
> 
> Scanned inputs are as above - easy up to the demux extension needed.
> 
> Capture units either:
> 1) Events
> 2) Triggers driver buffers - allowing other channels to be sampled at the
> capture instance if supported. Issue here is you then need one buffer per
> capture input - plus point is that unlike a typically PLC you have a fifo
> built in rather than having to shuffle these off before the next one shows
> up.
> 
> Hmm. Non obvious what is the best approach.

We've done this to support this kind of hardware:
https://github.com/analogdevicesinc/linux/commit/e04f0837ae47df0a3f07bdeba5db71ebf297cff9

There is a bit more discussion about this in this topic:
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-July/002839.html