@Mike: I did measure, but reply goes to the original sender and not to the list, whereas for the other lists I am on reply normally replies to the list.
Here's my message with benchmarking data. Frans. ---------- Forwarded message ---------- From: Frans Meulenbroeks <[email protected]> Date: 2010/8/19 Subject: Re: [UrJTAG-dev] [PATCH V4] Add cable driver based on GPIOs using sysfs interface To: Stefano Babic <[email protected]> 2010/8/19 Stefano Babic <[email protected]>: > Frans Meulenbroeks wrote: > > Hi Frans, > >> I have sent two small patches that improve the performance a little bit. >> >> Still I am looking at further ways to improve performance. >> Currently writing an svf file of 2.4 MB (9432 lines) takes 2 minutes >> (on a 1.2 Ghz PowerPC) (read frequency is 12169) >> While acceptable it would be nice to speed it up some more. >> >> Is it possible to access the gpio pins directly instead of through >> sysfs, and if so, how could that be done (and what could be achieved)? > > Well, the logic of the driver is that it could be used on any processors > and architecture, because it uses the standard interface provided by > sysfs. Your target is powerPC, mine is ARM based, no problem if you used > another one. Which is good > > Of course, you could write a kernel module that does more thing in > kernel using gpiolib (I mean, you could replace for example gpio_clock > with a single system call, an ioctl for your driver). However, you will > miss the possibility to run on different architectures and you have > dependencies with your kernel. Yeah, meanwhile peeked into it and it seems /dev/gpio is deprecated in 2.6.28 or so. A dedicated solution is not portable and (at least for me) not worth the effort. Actually I am not sure how much overhead there is in the whole /sys interface. I guess a good measurement would be the length of a clock pulse (the high time) > > I changed as suggested by Mike my first implementation replacing direct > I/O operations (open/close/write) with the stream functions (fopen, > etc). Even if I set them as not buffered, I had the impression (really I > have not measured, I have only tested if everything works) that there > some penalties on performance. Hm. I thought about open/close too. Triggered by your comments I wrote a small test app. If I use fopen/fclose and in a while loop do: fputc('0', fp); fputc('1', fp); I get a wave with period 1.96 uS. If I move to open/close with a while loop like: write(fd, "0", 1); write(fd, "1", 1); the period reduces to 1.53 uS. Same hw (1.2 ghz ppc) So write is substantially faster than fputc. I strongly suggest to move back to low level I/O (open/write/close) Frans BTW: i tried open with and without O_DIRECT but that did not seem to make any difference. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
