On Fri, 20 Sep 2019 09:45:21 +0200 Andrea Merello <andrea.merello@xxxxxxxxx> wrote: > Il giorno ven 13 set 2019 alle ore 13:30 Couret Charles-Antoine > <charles-antoine.couret@xxxxxxxxxxxxx> ha scritto: > > > >> One thing that maybe could be optimized (for the driver), is in `ad7949_spi_read_channel()` to use the current-channel & > > >> not do a SPI write to change the channel if it doesn't change. > > >> > > >> Datasheets (in general) are not always obvious about describing chip behavior for SW (or for writing a driver), but I > > >> would suspect that if you are reading garbage data, it could be that the channel has changed. > > >> This is true for some other ADCs. > > >> And requires testing for this one. > > > Yes, it's exactly what I've seen here. If the channel does not change > > > then the AD is already in acquisition phase on the right channel (I > > > assume it's OK to keep it in such phase indefinitely), then we can > > > just trigger a new conversion (CNV low->high, that is a dummy xfer) > > > and then read the result in following xfer, as the driver already did. > > > > > > I craft a V2 that performs the extra (3rd) spi xfer only if the > > > channel has to change. > > > > This design should be ok. I didn't implement in that way because not > > enough time to optimize the driver before release (I don't have access > > to the chip anymore) and for our workflow it was not relevant (we > > scanned all channels). > > I was in the process of doing this, but, thinking again about it, I'm > not completely sure it is really OK: > Should we guarantee that the value we return as outcome of a IIO read > request (i.e. we access in_voltage_raw) is sampled _after_ the user > read request? > > For example, the user might setup some other HW for the measure, or > somehow wait for the right moment for doing the measure, and then > perform the read from IIO, thus it's probably not OK if we convert a > value sampled just before the IIO read request. Absolutely. MUX in front of the sensor is a fairly common thing to see. > > If we skip the configuration rewrite when the channel doesn't change - > as discussed above - then we actually _terminate_ the acquisition when > the IIO read is triggered, that is we are converting the value sampled > right before the IIO read. > > If this is OK then I'll go on, otherwise I think that we should always > do the three cycles (so that triggering IIO read always waits also for > a new acquisition phase) An excellent point. I agree and suspect we may have this wrong in other sensors. The question gets more interesting if running in buffered mode as we have had systems using a trigger generated by an external process. I suppose in that case we just have to deal with the offset in the fifo etc in userspace. Maybe we should think about adding a note to be careful of that. Not really sure where we would note it though... Thanks, Jonathan
