Dante Sanchez wrote:
Hi Ryan,

Ryan Rapetti wrote:
For the sampling rate, you should probably use a timer. Linux provides
several that work very nicely.

Great, I'll look into that. I was using Dave Hylands' usleep-drv driver as a
'periodic timer', but if there's something else that is more reliable and
also goes down to useconds, I'll take it.
Microseconds are tricky, you may need to play with the kernel setup to get that kind of resolution.

Ryan Rapetti wrote:
 If dropped packets aren't the end of the world, then you should use a udp
socket, or possibly even a raw 

Yeah, I am using UDP sockets because I read that TCP sockets resend failed
packets, and that didn't sound very good to me.

Ryan Rapetti wrote:
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.

I have almost 40 bytes per sample, and that's what I was sending to fprintf
(no fprintf, gotcha!). I can definitely sample the SPI port at 1MHz and pipe
the data to wifi at ~50Hz...but then again, how do I do that so as not to
get in the way of the data sampling?
The best way to do this is to have the sensor set the sample frequency. The gumstix kernel isn't true realtime, and getting good timing at 1 MHz is going to be hard. But if the sensor sends a packet at 1MHz, that sets the timing and should be extremely accurate. Then you use the packet arrival as the signal to start everything. Grab the packet, process, send. The other question is whether or not exact timing is required post wifi, because you can't have it. The wifi chip will buffer and send the data on its own schedule. Also, just how much processing do you have to do? At about 1 operation/clock, you have a budget of 600 (XL6P) operations per sample, minus OS overhead, application overhead and other application overhead. If you're doing any floating point ops, 400-500 operations will run out before you've done a whole lot. Basic low order filtering will probably work, but I wouldn't count on much more than that.
    As far as not stomping on the sampling, you're going to have to be very creative to get the gumstix to set the timing correctly. It's just not realtime enough for that. If you can get the sensor to set the timing, it's mainly a matter of getting the SPI driver to buffer the incoming data and send a signal when a packet arrives. Then you have a signal handler grab the packet, process it and send it. At that point your program is basically in the handler. For multithreading, it all depends on what else the program is doing. If it has other duties, multithreading makes sense, but if all it does is grab, process and send, you shouldn't need a second thread.

Ryan Rapetti wrote:
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.

Yeah, that sounds easy enough...but I will have to do computations on the
data coming in, so I guess I am CPU bound. And, I haven't had the
opportunity to develop a SPI driver, so I am accessing the NSSP port through
user space. I guess that's not so great either...

Thanks for all the pointers, I appreciate it