ps5000 callback thread racecondition

Post your C and C++ discussions here
Post Reply
ducky

ps5000 callback thread racecondition

Post by ducky »

I want to stream data from my picoscope continuously at about 500kHz on two channels for some hours. I adopted the streaming example in ps5000con.c for my application.

Somewhere in the documentation is stated that the callback is executed in a separate thread. :

“… The driver then returns control to your application, allowing it to perform other tasks until the data is ready. When this happens, the driver calls your function in a new thread to signal that the data is ready. It is then up to your function to communicate this fact to the rest of your application.”

So ps5000GetStreamingLatestValues() is a non-blocking call, right?

I am confused, because in the ps5000con example the global variable g_ready is changed inside the callback and (at the same time) in the streaming loop – this is a race condition that should be avoided, at least when timing parameters are adopted and autostop is disabled. With some bad luck g_ready is set to FALSE right after the callback has set it to TRUE and a full chunk of data is lost, am I right?

Code: Select all

…
while (!_kbhit() && !g_autoStop)
	{
		Sleep(100);
		g_ready = FALSE;
		status = ps5000GetStreamingLatestValues(… callback …) ;

		if (g_ready && g_sampleCount > 0) {
			…
		}
}
…
My questions are:
- Am I right with the racecondition, or did I miss something?
- What is the preferred way to continuously capture data for very long periods and several gigabytes of data? (I just want the plain samples without aggregation or Trigger) An example would be great
- At which time the callback gets executed?
- Is there any documentation on how the buffers are used internally by the drivers?

I want to understand the whole (Ring)buffer topic and don’t find enough information in the ps5000pg.en.pdf document. How big should the buffer be (depending on samplerate)? is a wraparound done automatically? Where do I get further information?

Chris
Site Admin
Site Admin
Posts: 169
Joined: Tue Aug 17, 2010 9:00 am
Location: St. Neots

Re: ps5000 callback thread racecondition

Post by Chris »

The Block mode callback is non-blocking, but the streaming mode callback is blocking, so the race condition won't occur.

The callback is only called by the ps5000GetStreaminglatestValues call if there are values to collect, and will run to completion when called.


The buffer size you set will depend upon the sample rate, and what else your PC is doing. If your PC is busy, you might have collected several seconds of data before collecting them from the scope.

ducky

Re: ps5000 callback thread racecondition

Post by ducky »

Chris wrote:... but the streaming mode callback is blocking ...
Thanks for clarification.

Post Reply