Serial port in Windows

Is there any way to bypass the ~15ms (i.e. 1 tick) delay between write instructions? I tried using the SerialPort class of .net and Win32 API so far, and both have that 1 tick delay between every write. Reads seem to work just fine.

For your information: I'm currently using .net, however, if there is a way around that 1 tick problem, I'm willing to switch, as I only used .net for the easy form creation.
If possible, I would like to stick to Windows, as I don't have a spare PC for that project at the moment.
My goal is to send an instruction (2 bytes) + data (0-2 bytes) to a µc and get the answer (1 byte instruction, 1..n bytes for data) every 10ms. Baudrate is not an issue, there is plenty of room between the µc's answer and the next instruction sent from the PC.

Give yourself an enema

Give yourself an enema

>>3
That's disgusting

Travel back in time to tell yourself what to write to COM before you know it.

>>5
That would be great, but how do I know the answers from the µc?

>>6
s/5/2/
Fixed

the delay is a standard, you could rewrite the device driver to act as fast as possible though it can be tricky on windows

>>8
After my research I found out about timeBeginPeriod() for a higher precision timer. That might work with having multiple threads, however I'm not sure how that will work out with the simple protocol we are using (which is strictly sequential). If it works at all that is.
Going for *nix would mean redoing the whole UI, so I'll probably be doing the calculations for the controller on another Atmel and just leave path planning and interpreting the CNC commands to the PC.

>>1,9
It seems that your issue is the way you time the writes, or the the way you pause between writes (why do you do it?). What's your problem, really?

>>10
A thread, which is basically:
while (active) {
  if (queue.length>0) {
    send instruction via COM;
    read ack/error byte;
    if (ack) read 2 databytes;
  }
}
This always takes ~15ms, meausered with the oscilloscope. The Atmel answer immediatly after the stop bits, so that's not the problem.

>>11
*answers

Use events, not polling.

>>13
Events won't help. The Atmel won't send anything unless instructed to and the answers have predefined lengths, so an event-based approach would only complicate matters.
And as I stated in >>1 reading is not the problem, writing is.