|
-
March 18th, 2013, 11:56 AM
#21
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.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; March 18th, 2013 at 05:25 PM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|