serialport control performance

serialport control performance

• Joe Janson

  
  It sounds like a synchronous control. :(
  
  

• Joe Sutphin

  Hi,
  
  Thanks for your reply. I am unsure what exactly you mean. I believed I was already doing async I/O. I am currently NOT sending data, waiting a timeout then checking a buffer to see if theres anything to read. I am sending something then recieving data when the response comes in (on the recieved event). As I have a lots send/recieves to make I thought i could improve performance by sending/receiveing simultaneously.
  
  Do have the understanding of async i/o confused :/
  
  Regards,
  Rick
  

• Salvatore74

  I wish you'd said more about your protocols and the environment. Many classes use Asynchronous communications. The IO request is made and the processor does not wait on it, instead there is a callback routine that completes the request when the request is fulfilled.
  
  You can achieve the full duplex you want by doing asynch I/O.
  
  You can certainly do asynch on a serial port, but you won't be able to initiate anything new on the control until it's finished.
  
  

• Douglas Olson

  I'm not sure this control is asynch although I thought I read somewhere that it was. The control only has events like .DataReceived .ErrorReceived and .Pinchanged.

  
  

• Brett Samblanet MSFT

  OK, im trying to work out the implementation of you're doublebuffering suggestion. You suggestion involves having a recieve buffer and a send buffer and a timer that when fires, sends data in the send buffer and processes data in the recieve buffer
  

• DuncanEdwards

  Hi,
  
  Try the serial component from Sax.Communication (it's the people behind the old mscomm32.dll). It's a real .net component.
  
  Link: http://www.commstudio.com/
  
  With this component you can create a communication object at run-time and not in the UI - this makes the UI respond even if you are doing heavi communication.
  
  Regards,
  Brian
  
  

• bowie198672

  There is no timer.
  
  There are "callback" routines that are called upon I/O completion. These call back routines are specialized and know what they are to do when an I/O completes. you write them and you design them.
  
  A class has to have asynch before you can use it. Are you sure this control is asynch If so there should be some event that fires upon completion.
  
  The only place that a timer fits into this scheme is to deal with situations where an I/O has not completed within a certain amount of time. Then you want to do I/O cancellation and error handling.
  
  

• Rajeeshun

  You may understand asynch but your implementation isn't really asynch. Asynch frees you up to do other things including making additional I/O requests. This is a technique commonly called double buffering.
  
  Double Buffering means to have two buffers. You make an asych request against the first buffer. When it comes in or has gone out you immediately make the next request against the second buffer and then go back and process the data in the first buffer and then free up the buffer. Go to sleep until the second response is completed at which time you immediately issue the next request against the first buffer and then process the second buffer.
  
  You might be doing asynch I/O but with a single buffer, you are achieving the same thing as you would be with synchronous requests because you are always waiting on a single buffer. This needn't be limited to two buffers either. You can use as many resources as you can process either with fixed or dynamic allocations. This is limited only by cpu speed, available resources and line bandwidth.
  
  You also get to do the data bookkeeping and context maintenance reflecting what a give buffer is for and where it fits in the transfer you are making.
  
  
• serialport control performance