AD7609 driver for IIO

We're planning to use an AD7609 in our designs, so we got an evaluation board and hooked it up to the SPI controller.

Looking at the Linux IIO drivers, the AD7609 is a close match to the AD7606 family, only it's 18-bit instead of 16.

The way to go here seems like adding support for the 7609 in the ad7606*.c driver. I'm uncertain though as how to handle the 18-bit format. The hardware just outputs a "packed" 18 bytes of data for 8 channels at 18-bit. I could decode this in the driver and expand to say 32-bit per sample with only 18-bit significant data, or I could leave this up to user-space. The latter seems the more versatile choice.

We'll be feeding a constant (5 kHz) clock to the "start conversion" pins.

Any advice or futher hints on this?

  • Hi,

    If you want to get the maximum performance out of the part what I recommend is using the SPI engine framework rather than a off the shelve SPI controller. Although 5kSPS is at the limit of what can be handled by a pure software implementation, but I think you'll see a rather high system load.

    The SPI engine framework allows to reduce latency, increase throughput and reduce overall CPU load on the data path, while keeping the full flexibility for the configuration interface (if there is any). We have done some work with the AD7616 and the SPI engine framework. The AD7616 also has an interface very similar to the AD7609. The AD7616 is not final yet, but mostly complete and works and should good give a good idea how to approach this.

    At the moment the IIO framework requires that data is aligned at 8, 16, 32 ... bits. So packed data where you have one 18-bit word follow directly another one are not supported. But there are some discussions ('[RFC] iio: Add support for describing scan offsets in buffer ops' - MARC) on softening this requirement and let userspace opt-in to receive data in the 'native' layout of the converter. If you want to keep things aligned you'd have to add 14 bits of padding which could be quite wasteful depending on your setup. Also if not using SPI Engine and FPGA acceleration you'd have to re-align things in the driver for each sample which might cause some additional overhead. You could go ahead and just use packed data, but this will not work with any of the existing tools at the moment.

    - Lars

  • Good point, at 5kHz there'll be at least 10k IRQs per second: For each sample one from the ADC "busy" going low, triggering the SPI read, and then another from the SPI controller to indicate the transfer being ready (the Zynq SPI controller has a 64-byte FIFO, so just one IRQ is enough).

    Now I did get an embedded Linux system to handle 100k IRQs per second, but in a normal word, 10k is rediculous already...

  • One of the major issues is also variable latency. Even if on average you can handle the interrupt load when some unrelated driver disables interrupts or e.g. takes a spinlock or other interrupt handlers are running the latency goes up and occasional it will be larger than the sampling period and you miss a sample. We've been running some experiments in the past and on the ZYNQ 5kSPS is kind of the limit were you can get reliable data, but the CPU load from just capturing and copying the samples went to 70-80% (on one of the CPUs).

    - Lars