The idea of creating a system where the PC side just enables a data hose to open from the 8051 side is in my opinion not a good one. It can be unreliable!!

The alternative -----

Keep the concept where the host app sends periodic requests for data. Design it so that the average packet rate can be met without a problem. What I mean is that a slower packet rate will certainly work out to be functional as opposed to trying to do 1000 per second. This derives from the idea that "turn around time" at the packet level really does not change much relative to the length of the packets. Then based upon the sampling rate desired at the 8051 end have buffering of data to the extent that the buffer (or FIFO) size, in data item count, is about 2x size of the sample rate divided by the packet rate. Then in each packet supply the data in sets where each set includes the data items collected since the last host request. It is possible to design it so that the average packet rate is a sub-multiple of the 8051 sampling rate in which case the number of samples sent back up the hose to the host app is a fixed integer number of items. On the other hand the reply to the periodic requests could be designed to send back a variable number of data items where the average number of items returned is equal to the sample rate divided by the packet rate. In either case it would be a good idea to time stamp the reply packet headers so that if data gets lost the host app is aware of it.

Michael Karas