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@xxxxxxxxxx> 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@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/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
