If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Processing Time For PVOID Into Byte Array Conversion

I'm getting PVOID data continuously

Where is this data coming from and how does it get set into the memory pointed to by pvData? Is one thread producing this data and another thread processing it?

All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

Re: Processing Time For PVOID Into Byte Array Conversion

Hi Mr.2kaud & Mr.Paul,

Sample code like below,

Code:

byte TempArr[1024];
PVOID pvData = NULL; //store a line data into a pointer
pvData = GetCardData(); //I'm just using this function only. All functions are in the form of dll.
// Its getting from owner of card seller. using this Getting one line data = 1024 bytes @ every milliseconds
byte *bPoint = (byte*)pvData;
for(int i = 0; i < 1024; i++) TempArr[i] = (byte)(*(bPoint + i)); //Started to copy the data for drawing purpose
//For this transaction only I'm getting delay.

But using this I'm missing a line data for every line like 1,3,5,7,.... etc.

Originally Posted by Paul McKenzie

you have to ensure that you don't miss any data coming in. You don't do that by "coding the fastest routine" and hoping that the routine processes all the data before some real-time function refreshes the buffer with new data. That is a naive and wrong approach. You have to use the proper data structures (probably a queue), that caches the data that comes in so you don't miss anything.

after getting a line data, If I add any process means, the missing line increases like 1,5,11,etc... Sure Data are coming correctly. Myself only missing. Where is the problem?

Originally Posted by 2kaud

Where is this data coming from and how does it get set into the memory pointed to by pvData? Is one thread producing this data and another thread processing it?

I'm using a card it gives the data at every millisec 1024 bytes. And the memory pointed to pvData. Using thread concept I'm pointing Data by pvData continuously and using paint method to draw an image.

Re: Processing Time For PVOID Into Byte Array Conversion

... after getting a line data, If I add any process means, the missing line increases like 1,5,11,etc... Sure Data are coming correctly. Myself only missing. Where is the problem?

It seems that your painting takes much more time than reading the data...

Originally Posted by saraswathisrinath

I'm using a card it gives the data at every millisec 1024 bytes. And the memory pointed to pvData. Using thread concept I'm pointing Data by pvData continuously and using paint method to draw an image.

Which "thread concept" do you mean? I don't see any "thread concept" in the code snippet you have posted.

Besides, like Paul wrote:

Originally Posted by Paul McKenzie

You have to use the proper data structures (probably a queue), that caches the data that comes in so you don't miss anything.

Re: Processing Time For PVOID Into Byte Array Conversion

Originally Posted by saraswathisrinath

[/code]But using this I'm missing a line data for every line like 1,3,5,7,.... etc.
after getting a line data, If I add any process means, the missing line increases like 1,5,11,etc... Sure Data are coming correctly. Myself only missing. Where is the problem?

The problem is that you didn't put much thought in your design.

The solution is very simple in concept, and I explained briefly before, I will try again.

1) You are trying to write the fastest routine possible so that you can process the data quickly enough before the buffer gets overwritten with new data. This is the wrong approach.. There is no guarantee that your fast routine will be fast enough, so get rid of this idea of trying to write code that attempts to be speedier than the hardware that is sending you the data. What is speedy today may miss a byte or two of data tomorrow.

2) The solution or one such solution is to cache the data coming in, so that you don't lose any data. You save the incoming data on the back of the queue, while at the same time, you're processing the data that is sitting in front of the queue.

For the solution, you make the queue big enough so that it fits in with the processing time it takes to do one batch of data, plus accept any new data coming in. This is where experiments and trial/error comes in to see how big to make the queue. Once you have that set up, there is very little chance at all of missing data. If your drawing code is slow, then you make the maximum queue size large, if it's fast drawing code, then you can make the maximum queue size smaller. So basically, the speed of your graphics code won't matter.

Think of this like a cashier at a supermarket. The customers want to pay for the items they bought, so they must stand in line (a queue), waiting to be processed. Yes, the cashier needs to process each customer quickly, but there is no way a cashier can process a customer every single second or every two seconds.

Your code is trying to be the cashier that can process a customer every one or two seconds, therefore process each customer as they are about to check out of the store (which means no line is ever formed). You know that is practically impossible for a cashier to process a customer every second. So the solution is the same as what a supermarket does -- you create a line (queue) that where incoming checkout customers line up to be processed. If the cashier is not as fast as expected, then the queue will be longer, but every customer will be processed.

In your case, the customers are the same as the data the card is giving you, your graphics/drawing code is the cashier. So can you envision this? You make a queue for the data that the card is sending you. Any new data the card sends you gets placed at the back of the queue, while your graphics code processes the data that is in front of the queue.

For the queue, you will need proper synchronization so that reading and writing to the queue are done in a safe manner. So the only major thing you would need to do now is to implement the queue. There is std::queue from STL that can work for this, but again, you'll have to add the synchronization to ensure that you're not writing to the queue while reading from the queue, etc.

If your drawing code is very fast, e.g. the queue is empty most of the time, then that's ok -- just wait for data to be placed on the queue by the card.

Again, all of this should have been envisioned if you truly wanted to process real-time data. In no way should you have started trying to beat the card's speed. What if the processor(s) you were writing for are slow? What if the compiler's optimizer was bad (I know it's not, but what if it was slow)? What then? Get a faster computer? Or do you write the code so that no matter how slow or "bad" the drawing code is, it will process all the data that's coming in.

Re: Processing Time For PVOID Into Byte Array Conversion

Other processes running would also affect the speed of your program.

I am just wondering if one line of data (1024 bytes) will be drawn to one line of the display that was created in Draw Image Using 2D Byte Array ?. Does this display scroll vertically after each line is drawn? Or does each successive line of data get drawn on a successive line of the display until the display is full and then the drawing starts at the top of the display again? What are the dimensions of the display? (Width = 1024?, Height = ?) With the rate of data you are getting (1,024,000 bytes per second), it seems that the entire display would be redrawn a few times a second. Is this data coming from a camera? The InvalidateRect() function only needs to be called at most 60 times per second. Calling it more often would be unnecessary since your monitor does not update that fast.

Is the DLL allocating the memory for the incoming data array? Is this memory location static? If not, where is it freed? If your code could allocate the memory and pass the DLL a pointer to that memory, you could pass the DLL a pointer to a line of your image data. This would do the drawing automatically.

The solution or one such solution is to cache the data coming in, so that you don't lose any data. You save the incoming data on the back of the queue, while at the same time, you're processing the data that is sitting in front of the queue.

Am I cache the Real Data correctly? Please refer the code above which I post.

Mistake is in my side. But sure I tell Painting & the compiler's optimizer not reason for this. B'cos I removed paint method and run my code and also run my application with higher configuration PC.

Originally Posted by Coder Dave

What are the dimensions of the display? (Width = 1024?, Height = ?)

Width = 1024 & Height = 256.

Now, My problem is not drawing the image.

My first aim is getting the data correctly from camera with out any missing data.

The highlighted line in red just copies TempRealDataArray to itself! - as bTo is set to point to the beginning of TempRealDataArray.

The green line is just an attempt at a kludge to get the data because you are not using the proper structures for obtaining the data that have been suggested previously by Paul. The above code is not needed and should be removed.

You need to implement properly a queue with the producer being your realdata method and the consumer being the method/function to process or save the data as needed. The producer adds to the queue at the back and the consumer takes from the queue at the front. The queue consists of elements of 2048 bytes. Everytime your realdata method in its thread calls getdata() it copies the data to a new queue element at the back of the queue (add queue element - push in STL terms). Your consumer function takes elements from the front of the queue if there are any and processes the data (remove queue element - pop in STL terms). This can be done using the STL queue class and appropriate thread syncronisation.

All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

Re: Processing Time For PVOID Into Byte Array Conversion

Originally Posted by saraswathisrinath

I Already removed Paint and run my application. But no changes in the result.

The retrieval of the data from the card should do nothing except place the data onto the queue. Once the data is copied to the queue, that's it -- the reading of the card data is done. Instead, you're calling InvalidateRect and all sorts of other things during the reading of the data -- this is wrong.

The while (forever) will quit at some time, either it is signalled that no more data will come in or by some other means. Of course, you have to use the proper synchronization between the consumer/producer threads so that the queue doesn't become corrupted. You could even "lock" the queue with the RemoveDataFromFromOfQueue (and even in this case, to make the read "fast", you only read at most, say 500 bytes at a time). Then when the Read is done, you, unlock the queue so that the producer (the card) places data into the queue.

If you don't understand the producer/consumer paradigm or do not understand what a queue is, just say so. It seems you're not quite getting why your method is flawed, and why I suggested that you should just scrap it and use proper techniques. Just copying data to an array in a "simple" loop from begin to end is not a queue. You can use an array as a queue (but not necessary as there is std::queue built for this), but unless you use that array correctly as a queue, you're not going to get anywhere.

A queue requires that you copy data to the back of the array, while the processing of the data uses the data in the front of the array.

As an example, let's say that the queue has room for 10,000 bytes. Then 2,000 bytes of data comes in from the card (the producer). You place this data in the queue, and at the same time, the drawing function (the consumer) is looking at the queue for any data -- it is not looking or even care what the card is doing.

So now let's say your drawing function has drawn 1,500 bytes of data, and then the card sends 2000 bytes of data. Your card reading thread takes this data and places the card data in the queue -- nothing is being overwritten, since the data is placed in the back of the line.

The queue had 9500 bytes of space since the drawing completed 1,500 bytes. At the same time, the drawing function finishes up with the remaining 500 bytes it had to do the first time, then it looks at the queue and sees that there are 2,000 more bytes of data, and then draws that data.

Let's say the drawing function now processes 1,999 bytes of data, and then the card sends another 2000 bytes of data right when the drawing program is going to draw the last byte. You place the new card data at the back of the queue (which can hold 9,999 bytes, since the drawing processed 1,999 bytes). The drawing function finishes drawing that last remaining byte, looks at the queue, and sees it needs to draw more data.

This producer/consumer interaction goes on forever, until the drawing ends. Do you now see that you never miss any data, provided that the queue is big enough? Do you see where your current method fails miserably? Do you see why having the fastest code in the world doesn't matter with using a queue? With your current method, all of the times when the drawing function didn't draw all the bytes, you got into trouble. With the queue, you will never get into trouble (and your function to draw doesn't even need to be fast, albeit it is good that it is fast).

First I used Timer. called at every 1 milli seconds. This case I missed 15 to 20 lines. So I go to threads.

Threads are not going to help you -- you need to use the proper data structures, and you're not doing it. If you used the proper structure, it doesn't matter what the timings are.

And if it took 10,000 microseconds, then what do you do? What should be happening is that this painting routine doesn't care one bit about the timing, as long as the queue has room for more data coming in from the card. If the drawing routine takes a long time so that the queue is too small, then make the queue bigger -- that's how you fix the problem. You don't fix it by trying to write the fastest code in the world.

Mistake is in my side. But sure I tell Painting & the compiler's optimizer not reason for this. B'cos I removed paint method and run my code and also run my application with higher configuration PC.

Again, forget about what the compiler's optimizer does, and forget about how fast your PC is, and honestly forget about QueryPerformanceCounter() -- pretend that function doesn't exist. None of those things would hardly matter if you coded using the proper data structures.

My first aim is getting the data correctly from camera with out any missing data.
If I achieve this then my problem solved 90%.

If you took the advice of creating a queue, then 100% or close to it would be solved.

Pls take me at right path.....

We are trying, but are you listening? So far you're still stuck on using the same broken design. Again, forget about what you wrote -- it won't work if you do not want to miss any data.

My feeling is that you're trying to code in a "simple" fashion instead of actually coming up with a design. The card has data, you draw the data to the screen, and if the data comes in too fast, you create the drawing code even faster. Sure, that's the easy way to think about it, and frankly any beginner would have done exactly what you've done. But it isn't correct and it is seriously flawed. You have to actually use certain design patterns to overcome the problem.

Re: Processing Time For PVOID Into Byte Array Conversion

Originally Posted by saraswathisrinath

Code:

memcpy(bTo, bPnt,2048);

Why are you copying 2048 bytes when the input buffer is only 1024 bytes?

So your application is basically displaying the output of a black and white digital camera in a window. You are receiving 1,024,000 bytes/pixels per second from the camera. Your display has 1024 x 256 = 262,144 pixels, so it takes 256 milliseconds to receive one full image from the camera. That is, you are displaying 1,024,000 / 262,144 = 3.90625 full images per second. Even at this relatively slow speed for a video camera, if you miss a few lines of pixels here or there, they will be overwritten anyway after just a little more than a quarter second. Unless the camera data is being used for something other than just the display, does it really matter if some of the data is lost? I think your real problem is synchronizing the input signal with the display so that every pixel, that gets received, is drawn at the correct spot on the display.

Re: Processing Time For PVOID Into Byte Array Conversion

Hi,
Thanks to support me. I'm beginner only.

I didn't use Queue before that. I learned the queue concept. By using the queue concept, feeling very difficulty.

I stored the data into the queue , now how can I retrieve the data from that?. I know the method pop(). But i want byte array format.
The sample code, i didn't try just i share my doubt before use the code.

Really I felt very bad about me. before use codegure, no one here to help me. But now, all of then help me but my knowledge, I'm felt very difficult
I will study the concept and use and come back with you. Please give any sample code for me about queue.

Re: Processing Time For PVOID Into Byte Array Conversion

queue<PVOID> mypvoidQ;

Er... No. queue needs a type of data that is to be stored. PVOID is not a suitable type as this is just a pointer to void.

I've knocked up some code to demonstrate the idea between a producer thread and a consumer thread for you. Its just win32 not MFC but you should get the idea about using a queue and sync between the threads. I don't have a camera to test so I don't know the timings for loss of data - but if this sort of program design still looses data from the camera then you really are in trouble as all the producer is doing is adding blocks of data to the queue.

All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

Re: Processing Time For PVOID Into Byte Array Conversion

Originally Posted by saraswathisrinath

Hi,
Thanks to support me. I'm beginner only.

Well this is why in a real situation, it takes an experienced programmer to process "live" data correctly and efficiently. You can't really write a program with skills of a beginner to accomplish this.

First, get the idea of how a queue works by writing a simple program. Don't try and use your current program to learn how to use a queue.

For example, the queue::front() function returns a reference to the item that is first in the queue, but your sample program does nothing with the return value. All the queue::pop() does is remove the item from the queue -- it doesn't return to you a reference to the item. Second, why are you calling queue::back()? The push() automatically places the item in the back of the queue.

So even in a very simple situation, you're not using the queue correctly and you really are not sure what those member functions do.

Re: Processing Time For PVOID Into Byte Array Conversion

Hi,
After long time, I came back and also my problem solved .

I used the Buffer to store the data (1000 line of data) & used the memcpy function to copy the data in to the byte pointer. After that, I used the file method to print the data.Now, I received the data without missing. Really happy.

Single time(1000 lines data) real time data received successfully. here after trying to get the real time data continuously.