GPIO + SPI + Interrupt. Timing problem

Hello Everyone.
:slight_smile:

Scenario.
I have an ADC with an SPI Interface.
When the conversion is complete, the ADC asserts a pin. I read it on a
gpio(133).
And then initiate an SPI Transfer.

Problem.
I've set the ADC at 1000 Samples/Sec.
That means. If i need 10000 samples. It should take 10 seconds.

But it takes approx 30 seconds to acquire the 10000 samples.

Somewhere, the timing in my code is pretty messed up.

I'll write the basic algo.

for(10000 samples)
file* fd = open('/sys/virtual/gpio/gpio133/value', 'r');
myinterrupt = getch(fd);

if (myinterrupt == '0')
          ret = ioctl(spidevfd, message(1) , &spistruct);

fclose(fd);

any idea where the speed issue is?

the spi transfer is 27 bytes. And I've set max speed at 44MHz.
When i set it at 48Mhz. the first bit gets corrupted for some reason.

Is sysfs slow? with the gpio open close?
should i go for the mmap path?

or is spidev the prob?

My personal opinion is the the file i/o isn't fast enough.
Isnt there a way to keep a file open and keep polling it.
Or some event/interrupt method?

p.s. i use the tincantools trainer board for level translation as
well.
don't think that could be an issue because i can acquire the spi data.

Update

I used mmap to check the gpio.
Still 30 seconds.

And i redid the calculations.

Its actually
One second equivalent of samples that i acquire in 30 seconds.

Anyone know how i can optimize this?
Are there any blocking/sleep statements in spidev that anyone knows
of?
Or is the spidev interface uncool for realtime data acquisition?

Hello Zubair,
I am not sure if that is the best idea but maybe you could use a
GPtimer to control the exact time in between the samples you want to
acquire. That should work. Let me know i you need help.
Regards,
Frederico

Thought I'd update the solution here.

I am using the 2.6.32 kernel. DMA doesn't work in it.
Polling mode is slow.
So I took the updated omap_mcspi driver from the latest kernel. And
used that.
DMA Works in that.

I inserted my gpio133 check in the omap_mcspi driver using omap_readl
to read the gpio5datain register itself.
(I actually inserted a check in the delay area. The spi structure has
a delay value for each transfer. I put a check on the
delay. If the delay value is 3us my check code will run. That way I
can bypass the check if I want. )

Increased spidev buffersize.

Disabled soft reset for every transfer(I have only one spi slave)

The above solved the problem from 1sec samples in 30sec.
to 1sec samples in approx 1.06sec