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.
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
socket.
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?
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
Dante
