Messages in this thread | | | Date | Fri, 11 Jan 2013 16:40:06 +0200 | Subject | Re: Kernel driver vs libusb performance | From | Ozan Çağlayan <> |
| |
> It all depends on what you want to do, but I really think that user vs. > kernelspace is not going to be the real problem here. Start with libusb > and if you find that you are having problems, use 'perf' to see if the > kernel part is really the problem. I think you will find all of your > time is going to be spent in the USB hardware itself, and the USB > driver, once you get the data out of that, user vs. kernel is not going > to be noticable at all. > > Best of luck, and I bet you, in the end, you pick a better hardware > platform for your project (hint, go buy a Beaglebone, it actually works > and the tiny increase in cost more than makes up for the time you will > waste fighting the RPI hardware.)
My mainloop is sth like this actually:
(I never thought of multi-processing & multi-threading but I may give a chance on cooperative multitasking using Python greenlets)
1. [Simultaneously] {Fetch 32bytes in 128Hz + Decrypt + Queue them} AND {Flicker 2 LEDs with 10Hz/7.5Hz respectively using GPIO} (This is the step I'm afraid off, I expect jitters of course but up to a limit. I also think about trying RT-patched kernel if that will help at all...)
2. Take FFT of the signal queued using SciPy (I timed this: It takes 230~ uS for FFT of 128 integers on Rpi)
3. Do some simple math on FFT'ed signal && Send a command to another device over a USB-FTDI channel if some threshold is attained.
You are right that Beaglebone brings a huge improvement with acceptable increase in the price but what I'm trying to do is to show people that "Hey what you are doing on your decent 1000$ i7 desktop with Matlab over Windows works on my 30$ Linux box using Python" and that is exactly why I'm pushing the limits of the device.
Thank you very much :)
-- Ozan Çağlayan Research Assistant Galatasaray University - Computer Engineering Dept. http://www.ozancaglayan.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |