Re: [Gumstix-users] Threading for real-time data transmission

[Ryan R. <rjr...@uc...>]

Dante Sanchez wrote:
> Hi,
>
> I have a Verdex+console-vx+netwifimicro stack that reads data from a SPI
> device and forwards it to my computer via wireless sockets (I create a pipe
> with socat and then write to it with fprintf).
>
> Right now I am sampling at around 250Hz, but I want to be able to read at
> least as fast as 1MHz. I'm confident the routine can definitely do it, but
> the data transmission is what's slowing down my program.
>
> Do you think it's worth it to try making the data transmission into a
> separate thread? I'm not sure if that will actually fix the problem.
>
> Also, I'm using gettimeofday() to take a measurement of the sampling time,
> and every data point returns a different value, approx. within 0.500 ms. Is
> there a way I can shut off processes running in the background? I'm using a
> buildroot image. 
>
> Thanks,
>
> Dante
>   
For the sampling rate, you should probably use a timer. Linux provides 
several that work very nicely. You've got several options for data 
transmission.  I think your backup will be in the wifi link. The 50Mbs 
is a burst rate, kind of like a 3Gbs SATA drive. Sustained rates will be 
far slower due to packet overhead, handshaking, etc. It also depends on 
whether you have to have every packet. If dropped packets aren't the end 
of the world, then you should use a udp socket, or possibly even a raw 
socket. The other question is how many bits/sample. Your theoretical 
maximum is 50 bits/sample at 1 MHz. 50 bits is 6 bytes and change, and 
figure you'll be lucky to get half of that. Also, dump fprintf. It's 
slowing you down. Use write() to send binary structs or 
ints/shorts/chars, whichever applies to your sensor.
Threading only makes sense when you have one task that's IO bound and 
another that's CPU bound. Unless you're doing some filtering on the 
data, you're not CPU bound at all. You have a pure IO problem here, and 
that's where you should focus. If all the gumstix is doing is acting as 
a relay, the fastest solution is to modify the SPI driver to pass the 
data directly to the wifi buffer. Short of that, you should be able to 
pass the address of the spi buffer to write with an appropriate size and 
skip all the copying.

Ryan