IIO channel type for status/error flag indicators

IIO channel type for status/error flag indicators

[Popa, Stefan Serban]

Hello,

We are currently working on a new adis16495 IMU driver which is an upgrade
from the adis16480 family: https://www.analog.com/media/en/technical-docume
ntation/data-sheets/ADIS16495.pdf.

This new chip supports a feature called "Burst Read Function" (page 13 in
the datasheet). The burst read function (BRF) provides a method for reading
a batch of data (status, temperature, gyroscopes, accelerometers, time
stamp/data counter, and CRC code), which does not require a stall
time between each 16-bit segment and only requires one command
on the DIN line to initiate.

Most of the data read in this way can be attributed to a type of channel: 
IIO_TEMP, IIO_ANGL_VEL, IIO_ACCEL, etc. However, there is no equivalent for
the status and CRC. The status register provides various error flags such
as spi communication error, sensor failure, sync error, etc (Table 18 in
the datasheet). This information together with the CRC error should be
exposed to the user space. What is the best way to do it? 

The most obvious way, but not necessarily the correct one, would be to add
a new channel type called something like IIO_STATUS or IIO_FLAG. Is this
acceptable?

A more or less similar burst read function has been previously implemented
as part of the adis16400 driver. Although a burst read will also produce
diagnostic status data, it was ignored in the driver implementation.

Looking forward to any suggestion.

-Stefan

Re: IIO channel type for status/error flag indicators

[Jonathan Cameron]

On Wed, 20 Mar 2019 14:53:50 +0000
"Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:

> Hello,
> 
> We are currently working on a new adis16495 IMU driver which is an upgrade
> from the adis16480 family: https://www.analog.com/media/en/technical-docume
> ntation/data-sheets/ADIS16495.pdf.
> 
> This new chip supports a feature called "Burst Read Function" (page 13 in
> the datasheet). The burst read function (BRF) provides a method for reading
> a batch of data (status, temperature, gyroscopes, accelerometers, time
> stamp/data counter, and CRC code), which does not require a stall
> time between each 16-bit segment and only requires one command
> on the DIN line to initiate.
> 
> Most of the data read in this way can be attributed to a type of channel: 
> IIO_TEMP, IIO_ANGL_VEL, IIO_ACCEL, etc. However, there is no equivalent for
> the status and CRC. The status register provides various error flags such
> as spi communication error, sensor failure, sync error, etc (Table 18 in
> the datasheet). This information together with the CRC error should be
> exposed to the user space. What is the best way to do it? 

Ok, So this is not exactly unusual.  The issue has always been defining
a remotely generic userspace ABI.

> 
> The most obvious way, but not necessarily the correct one, would be to add
> a new channel type called something like IIO_STATUS or IIO_FLAG. Is this
> acceptable?

No unfortunately. What does generic userspace do with it?

Part of the problem is we don't have a channel type to cover flags in
general (if we had digital inputs packed into bytes we would at least
be slightly better off).

> 
> A more or less similar burst read function has been previously implemented
> as part of the adis16400 driver. Although a burst read will also produce
> diagnostic status data, it was ignored in the driver implementation.
Yup :)  Couldn't figure out how to do it at the time.

Normally these flags represent error conditions (if they map to events
in IIO then put them out like that).  The problem has always been that
Linux doesn't actually have generic simple error event handling.
There is RAS handling for servers, but who runs it on embedded boards
except possibly for some form of EDAC.

> 
> Looking forward to any suggestion.

I'm not against us having meta data channels, but they pretty much need
to be as tightly defined as any other channel.  The other side issue
here is it's a new 'huge' space.  However, I'm not sure you are in
that territory here.  Looks to me like status really means error.
If you get an error, mostly it's game over.  If you get a CRC error
and want to check it, then drop the record and spit out a message.

So I'm a little unconvinced as yet that there is anything we actually
can use in this status message.

Jonathan


> 
> -Stefan

Re: IIO channel type for status/error flag indicators

[Popa, Stefan Serban]

Hi Jonathan,

Thank you for taking the time to answer.

These devices are mostly used in automotive/aerospace industries where they
usually require a continuous stream of data even if an error occurs. This
is why we cannot just "drop the record" :).
So, should we maybe think of a way of covering flags channel types?

Regards,
-Stefan 

On Du, 2019-03-24 at 18:00 +0000, Jonathan Cameron wrote:
> 
> 
> On Wed, 20 Mar 2019 14:53:50 +0000
> "Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:
> 
> > 
> > Hello,
> > 
> > We are currently working on a new adis16495 IMU driver which is an
> > upgrade
> > from the adis16480 family: https://www.analog.com/media/en/technical-do
> > cume
> > ntation/data-sheets/ADIS16495.pdf.
> > 
> > This new chip supports a feature called "Burst Read Function" (page 13
> > in
> > the datasheet). The burst read function (BRF) provides a method for
> > reading
> > a batch of data (status, temperature, gyroscopes, accelerometers, time
> > stamp/data counter, and CRC code), which does not require a stall
> > time between each 16-bit segment and only requires one command
> > on the DIN line to initiate.
> > 
> > Most of the data read in this way can be attributed to a type of
> > channel:
> > IIO_TEMP, IIO_ANGL_VEL, IIO_ACCEL, etc. However, there is no equivalent
> > for
> > the status and CRC. The status register provides various error flags
> > such
> > as spi communication error, sensor failure, sync error, etc (Table 18
> > in
> > the datasheet). This information together with the CRC error should be
> > exposed to the user space. What is the best way to do it?
> Ok, So this is not exactly unusual.  The issue has always been defining
> a remotely generic userspace ABI.
> 
> > 
> > 
> > The most obvious way, but not necessarily the correct one, would be to
> > add
> > a new channel type called something like IIO_STATUS or IIO_FLAG. Is
> > this
> > acceptable?
> No unfortunately. What does generic userspace do with it?
> 
> Part of the problem is we don't have a channel type to cover flags in
> general (if we had digital inputs packed into bytes we would at least
> be slightly better off).
> 
> > 
> > 
> > A more or less similar burst read function has been previously
> > implemented
> > as part of the adis16400 driver. Although a burst read will also
> > produce
> > diagnostic status data, it was ignored in the driver implementation.
> Yup :)  Couldn't figure out how to do it at the time.
> 
> Normally these flags represent error conditions (if they map to events
> in IIO then put them out like that).  The problem has always been that
> Linux doesn't actually have generic simple error event handling.
> There is RAS handling for servers, but who runs it on embedded boards
> except possibly for some form of EDAC.
> 
> > 
> > 
> > Looking forward to any suggestion.
> I'm not against us having meta data channels, but they pretty much need
> to be as tightly defined as any other channel.  The other side issue
> here is it's a new 'huge' space.  However, I'm not sure you are in
> that territory here.  Looks to me like status really means error.
> If you get an error, mostly it's game over.  If you get a CRC error
> and want to check it, then drop the record and spit out a message.
> 
> So I'm a little unconvinced as yet that there is anything we actually
> can use in this status message.
> 
> Jonathan
> 
> 
> > 
> > 
> > -Stefan

Re: IIO channel type for status/error flag indicators

[Jonathan Cameron]

On Thu, 28 Mar 2019 18:38:21 +0000
"Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:

> Hi Jonathan,
> 
> Thank you for taking the time to answer.
> 
> These devices are mostly used in automotive/aerospace industries where they
> usually require a continuous stream of data even if an error occurs. This
> is why we cannot just "drop the record" :).
> So, should we maybe think of a way of covering flags channel types?

Propose an interface and we can certainly talk about it :)  Keep in mind
that it needs to be lightweight for anything not making use of it and
that I can see this absorbing a lot of namespace / id space (particularly
in potential event codes) so keep that in mind as well.

I'd argue that those automotive / aerospace devices should certainly
cope with missing data, but perhaps that's wishful thinking.

Anyhow, I'm not against this in principle but think it's a non trivial
exercise so prepare yourself for a big job and quite a few rounds of
interface descriptions!

Jonathan

> 
> Regards,
> -Stefan 
> 
> On Du, 2019-03-24 at 18:00 +0000, Jonathan Cameron wrote:
> > 
> > 
> > On Wed, 20 Mar 2019 14:53:50 +0000
> > "Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:
> >   
> > > 
> > > Hello,
> > > 
> > > We are currently working on a new adis16495 IMU driver which is an
> > > upgrade
> > > from the adis16480 family: https://www.analog.com/media/en/technical-do
> > > cume
> > > ntation/data-sheets/ADIS16495.pdf.
> > > 
> > > This new chip supports a feature called "Burst Read Function" (page 13
> > > in
> > > the datasheet). The burst read function (BRF) provides a method for
> > > reading
> > > a batch of data (status, temperature, gyroscopes, accelerometers, time
> > > stamp/data counter, and CRC code), which does not require a stall
> > > time between each 16-bit segment and only requires one command
> > > on the DIN line to initiate.
> > > 
> > > Most of the data read in this way can be attributed to a type of
> > > channel:
> > > IIO_TEMP, IIO_ANGL_VEL, IIO_ACCEL, etc. However, there is no equivalent
> > > for
> > > the status and CRC. The status register provides various error flags
> > > such
> > > as spi communication error, sensor failure, sync error, etc (Table 18
> > > in
> > > the datasheet). This information together with the CRC error should be
> > > exposed to the user space. What is the best way to do it?  
> > Ok, So this is not exactly unusual.  The issue has always been defining
> > a remotely generic userspace ABI.
> >   
> > > 
> > > 
> > > The most obvious way, but not necessarily the correct one, would be to
> > > add
> > > a new channel type called something like IIO_STATUS or IIO_FLAG. Is
> > > this
> > > acceptable?  
> > No unfortunately. What does generic userspace do with it?
> > 
> > Part of the problem is we don't have a channel type to cover flags in
> > general (if we had digital inputs packed into bytes we would at least
> > be slightly better off).
> >   
> > > 
> > > 
> > > A more or less similar burst read function has been previously
> > > implemented
> > > as part of the adis16400 driver. Although a burst read will also
> > > produce
> > > diagnostic status data, it was ignored in the driver implementation.  
> > Yup :)  Couldn't figure out how to do it at the time.
> > 
> > Normally these flags represent error conditions (if they map to events
> > in IIO then put them out like that).  The problem has always been that
> > Linux doesn't actually have generic simple error event handling.
> > There is RAS handling for servers, but who runs it on embedded boards
> > except possibly for some form of EDAC.
> >   
> > > 
> > > 
> > > Looking forward to any suggestion.  
> > I'm not against us having meta data channels, but they pretty much need
> > to be as tightly defined as any other channel.  The other side issue
> > here is it's a new 'huge' space.  However, I'm not sure you are in
> > that territory here.  Looks to me like status really means error.
> > If you get an error, mostly it's game over.  If you get a CRC error
> > and want to check it, then drop the record and spit out a message.
> > 
> > So I'm a little unconvinced as yet that there is anything we actually
> > can use in this status message.
> > 
> > Jonathan
> > 
> >   
> > > 
> > > 
> > > -Stefa  

Re: IIO channel type for status/error flag indicators

[Popa, Stefan Serban]

Hi Jonathan,

We'll come back with an interface proposal.
Thank you!

-Stefan

On Du, 2019-03-31 at 12:11 +0100, Jonathan Cameron wrote:
> On Thu, 28 Mar 2019 18:38:21 +0000
> "Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:
> 
> > 
> > Hi Jonathan,
> > 
> > Thank you for taking the time to answer.
> > 
> > These devices are mostly used in automotive/aerospace industries where
> > they
> > usually require a continuous stream of data even if an error occurs.
> > This
> > is why we cannot just "drop the record" :).
> > So, should we maybe think of a way of covering flags channel types?
> Propose an interface and we can certainly talk about it :)  Keep in mind
> that it needs to be lightweight for anything not making use of it and
> that I can see this absorbing a lot of namespace / id space (particularly
> in potential event codes) so keep that in mind as well.
> 
> I'd argue that those automotive / aerospace devices should certainly
> cope with missing data, but perhaps that's wishful thinking.
> 
> Anyhow, I'm not against this in principle but think it's a non trivial
> exercise so prepare yourself for a big job and quite a few rounds of
> interface descriptions!
> 
> Jonathan
> 
> > 
> > 
> > Regards,
> > -Stefan
> > 
> > On Du, 2019-03-24 at 18:00 +0000, Jonathan Cameron wrote:
> > > 
> > > 
> > > 
> > > On Wed, 20 Mar 2019 14:53:50 +0000
> > > "Popa, Stefan Serban" <StefanSerban.Popa@analog.com> wrote:
> > > 
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > We are currently working on a new adis16495 IMU driver which is an
> > > > upgrade
> > > > from the adis16480 family: https://www.analog.com/media/en/technica
> > > > l-do
> > > > cume
> > > > ntation/data-sheets/ADIS16495.pdf.
> > > > 
> > > > This new chip supports a feature called "Burst Read Function" (page
> > > > 13
> > > > in
> > > > the datasheet). The burst read function (BRF) provides a method for
> > > > reading
> > > > a batch of data (status, temperature, gyroscopes, accelerometers,
> > > > time
> > > > stamp/data counter, and CRC code), which does not require a stall
> > > > time between each 16-bit segment and only requires one command
> > > > on the DIN line to initiate.
> > > > 
> > > > Most of the data read in this way can be attributed to a type of
> > > > channel:
> > > > IIO_TEMP, IIO_ANGL_VEL, IIO_ACCEL, etc. However, there is no
> > > > equivalent
> > > > for
> > > > the status and CRC. The status register provides various error
> > > > flags
> > > > such
> > > > as spi communication error, sensor failure, sync error, etc (Table
> > > > 18
> > > > in
> > > > the datasheet). This information together with the CRC error should
> > > > be
> > > > exposed to the user space. What is the best way to do it?
> > > Ok, So this is not exactly unusual.  The issue has always been
> > > defining
> > > a remotely generic userspace ABI.
> > > 
> > > > 
> > > > 
> > > > 
> > > > The most obvious way, but not necessarily the correct one, would be
> > > > to
> > > > add
> > > > a new channel type called something like IIO_STATUS or IIO_FLAG. Is
> > > > this
> > > > acceptable?
> > > No unfortunately. What does generic userspace do with it?
> > > 
> > > Part of the problem is we don't have a channel type to cover flags in
> > > general (if we had digital inputs packed into bytes we would at least
> > > be slightly better off).
> > > 
> > > > 
> > > > 
> > > > 
> > > > A more or less similar burst read function has been previously
> > > > implemented
> > > > as part of the adis16400 driver. Although a burst read will also
> > > > produce
> > > > diagnostic status data, it was ignored in the driver
> > > > implementation.
> > > Yup :)  Couldn't figure out how to do it at the time.
> > > 
> > > Normally these flags represent error conditions (if they map to
> > > events
> > > in IIO then put them out like that).  The problem has always been
> > > that
> > > Linux doesn't actually have generic simple error event handling.
> > > There is RAS handling for servers, but who runs it on embedded boards
> > > except possibly for some form of EDAC.
> > > 
> > > > 
> > > > 
> > > > 
> > > > Looking forward to any suggestion.
> > > I'm not against us having meta data channels, but they pretty much
> > > need
> > > to be as tightly defined as any other channel.  The other side issue
> > > here is it's a new 'huge' space.  However, I'm not sure you are in
> > > that territory here.  Looks to me like status really means error.
> > > If you get an error, mostly it's game over.  If you get a CRC error
> > > and want to check it, then drop the record and spit out a message.
> > > 
> > > So I'm a little unconvinced as yet that there is anything we actually
> > > can use in this status message.
> > > 
> > > Jonathan
> > > 
> > > 
> > > > 
> > > > 
> > > > 
> > > > -Stefa