On Wed, 20 Mar 2019 14:53:50 +0000 "Popa, Stefan Serban" <StefanSerban.Popa@xxxxxxxxxx> 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
