Dear all, First of all, sorry for the delay. The time measurement deliberatley includes the print call, since i am interested in the continious read-in speed. On that note, is it possible that the PC spends about 4/10 of the time with the USB, and 6/10 with formatting and printing? If that's the case, then the chip actually can do the promised 1MB/s read-in. I'll try to make some tests, and share the results.
The code is obviously faulty, because i have to flush the sdtout, that already had been corrected. On that note, the stdout buffer does have a maximum size, and i believe if that is reached, it prints out the buffer, flushed or not. Also, i changed it to file writeing, but that did not effected the speed by much. Last, but not least Thomas Jarosch's idea sounds plausible, but could someone help me out how to use (or find for that matter) the git? Thanks to everyone Daniel Balog 2012.08.14. 21:45, "Jim Paris" <[email protected]> ezt írta: > Thomas Heller wrote: > > Am 29.07.2012 16:30, schrieb Balog Dániel: > > >Dear all, > > > > > >I'm working on a way to read in data form ADCs to a PC via the UM245R. > > >It is working, but i could only achieve 630 KB/s compared to the > > >theoretical speed of the device (1MB/s with d2xx drivers). I'm > > >assuming that my code is inefficient, since I'm only a hobbist at > > >programming. > > > > IIUC, in the time you measure, you are including the printf calls to the > > console. Don't know how much this influences the result. > > I'd expect it to influence it quite a lot, but his code only prints > the buffer when you hit a key. (it's hard to see that because the > indentation is messed up) > > -jim > > -- > libftdi - see http://www.intra2net.com/en/developer/libftdi for details. > To unsubscribe send a mail to [email protected] > > -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
