Jonathan,
Thanks - I'll share back my findings and changes this week.
One problem i've run into is throughput - it seems like the linux spi subsystem has a non-deterministic 50-150us delay before an spi_sync or spi_async command is processed. I can't seem to find any way around this - so if i use larger multi-byte transfers using spi_async and DMA I get great, stable throughput, but that is broken up by these 50-150us delays between transfers (i'm using the beagle bone, so AM3359 that has a dedicated SPI controller and DMA.)
Have any of you guys had success getting reliable >1MSPS throughput via IIO over SPI? It seems like this inherent delay in the SPI subsystem would make this pretty difficult.
-chris
On Saturday, March 2, 2013 at 11:27 AM, Jonathan Cameron wrote:
> On 02/27/2013 07:32 PM, Chris Micali wrote:
> > Guys,
> >
> > Thanks a lot for the help! I finally tracked down issues, it was a combination of a few things:
> >
> > 1. The .channel had to be 0, not 1 in the driver (scan_index didn't matter)
> > 2. 1 or more scan_elements have to be enabled as you mentioned
> > 2. When echoing into the sysfs files it has to have a space after the number (cat 1 > in_voltage0_en and not cat 1>in_vo…) (duh!)
> > 3. The generic_buffer.c program had a few bugs in it causing crashes. I updated the iio_utils.h to a newer version I found here: https://github.com/analogdevicesinc/iio-oscilloscope and then made a few modifications (the newer iio_utils did not parse a few things right in the channel details like bigendian/littleendian)
> >
> > So generic_buffer is now correctly sampling (although it crashes after a couple, it's probably another iio_utils issue)
> If you do track down why this is happening, please do report back
> so we can get it fixed. I wasn't previously aware of any particular
> issues in the example code so any feedback is helpful!
>
> Looking foward to seeing the driver code when you are happy with it.
>
> Jonathan
> > Thanks!!
> >
> > -chris
> >
> >
> > On Wednesday, February 27, 2013 at 1:51 PM, Lars-Peter Clausen wrote:
> >
> > > On 02/27/2013 07:28 PM, Jonathan Cameron wrote:
> > > > On 02/27/2013 05:36 PM, Chris Micali wrote:
> > > > > lars,
> > > > >
> > > > > I was under the impression that flag gets added automatically by iio_triggered_buffer_setup (industrialiio-triggers.c:77) - I actually am now able to enable the scan_element after changing my channel .channel and .scan_index to 0 (trying to match exactly the other drivers.)
> > >
> > >
> > > Yea, you are right I missed the iio_triggered_buffer_setup part.
> > >
> > > > Strange, scan_index should have defaulted to zero and the .channel value shouldn't have mattered
> > > > for buffered reads (just effects naming). Might have caused issues with userspace expecting a channel 0
> > > > though...
> > >
> > >
> > >
> > >
> > >
> > > I guess the scan_index had nothing to do with this, but I suggested to set
> > > scan_elements/in_voltage0_en to 1, so this clearly wouldn't have worked with
> > > .channel being 1.
> > >
> > > >
> > > > > When i run general_buffer (from the docs dir) with that scan element enabled it can no longer read the trigger (Could not open /trigger/current_trigger Failed to write current_trigger file) - this succeeds if that scan_element is not enabled.
> > >
> > >
> > > You can't change the trigger if the buffer is currently enabled. Make sure that
> > > he buffer is disabled (check the buffer/enable attribute).
> > >
> > > - Lars
> > > u
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
