I’ve noted, that even in the “Oscilloscope” mode, the PCSU1000.exe process consumes significant (96%) amount of CPU cycles. This is not very significant if program runs on the something like Celeron 2GHz, but makes difference on the Pentium 4 3Ghz which starts to dissipate too much heat causing all the fans to produce an unwanted noise.
I’ve tried to throttle CPU performance down to 25% and this doesn’t affected functionality of the scope. This leads me to suspicion, that the main loop contains some kind of “while (!data_is_ready) { nop() }” code, which just wastes CPU cycles. So, is this true, and if so, it is possible to use different mechanisms to reduce power usage ?
Thank you for this comment.
Indeed, the software is polling a ftd2xx.dll function FT_GetQueueStatus to get the number of bytes in the receive queue of the FT245BM USB FIFO. The buffer is read when there is the amount of the data needed to draw the two traces on the screen.
One alternative to solve this problem is using timer and only periodically check the FT_GetQueueStatus. I’ll test this soon.
Any other ideas…
Never ever use a loop or timer to poll for asynchronous IO, this is very bad practice, since it will hog CPU cycles.
The FTDI chip offers functions that support event signalling. You should try creating a background worker thread that blocks until a certain event occurs (eg. data arrived or application exit). The worker thread can then read the data (by using FT_GetQueueStatus etc) and process it. When the read is complete it should go back to sleep and start the whole thing over again.
[quote=“VEL448”]
Reference: FT_SetEventNotification
[/quote]Alternatively, one can specify read and write timeouts via FT_SetTimeouts() function and use FT_Read() in the loop taking into account number of bytes returned in the each FT_Read() call. Using this approach it will be possible to receive large chunks of data in the single call to FT_Read().
That would indeed be a quick way to patch the application. But note that timeouts aren’t provided for this purpose and might cause unwanted behavior while used in an infinite loop.
Imho you should bite the bullet and use a more durable approach through multithreading/signalling and apply timeouts to detect failed/defective IO. And maybe reuse the routines for other scopes.
Thank you for your comments. It’s nice that you like the new features of the software.
If you find any unwanted “side effects” due to this modifications please inform.
Also all other suggestions to improve the software are welcome.
Indeed the version numbering may be somewhat confusing. You have downloaded the right software version regardless that the version number of the PCSU1000.EXE program is 1.04. The version numbers for every individual instrument live their own lives. The version number advances if there is any change done to the operation of the instrument. The “top level” version number of the PCLAB2000SE package advances every time if any of the sub programs is changed. This “top level” version number (now 2.04) is displayed during the software setup only. This version number will be put in the future to the user interface of the PCLAB2000SE.EXE program.