Microsecond timer
-
Hi... I have a program to read data from serial port,and I want to repeat the program every 1 microsecond. this is my program, but I just can repeat every 1 milisecond
void CStripDlg::OnTimer(UINT nIDEvent)
{
int dcount=0;
CString data[4];
VARIANT in_dat;{ in\_dat = m\_comm.GetInput(); // read port CString strInput(in\_dat.bstrVal); m\_input.Format("%s", strInput); // show data m\_comm.SetInBufferCount(0); // clear buffer } } UpdateData(FALSE); CDialog::OnTimer(nIDEvent);void CStripDlg::OnStart()
{
SetTimer(1,1,NULL); // set data 1 milisecond
}
}thx
You need to do the following. 1. Determine the actual baud rate. In your other code you suggested 9600. Presumably that is correct. 2. Create a thread. 3. That thread does the following and NOTHING else. a. Block on the serial port. (You don't use a timer but rather you wait until data is available.) b. Read one byte c. Add that byte to a thread safe queue. d. Go back to a. 4. In your GUI code (or wherever) you read data from the queue and do whatever you want with it. Note that this occurs in a different thread.
-
You need to do the following. 1. Determine the actual baud rate. In your other code you suggested 9600. Presumably that is correct. 2. Create a thread. 3. That thread does the following and NOTHING else. a. Block on the serial port. (You don't use a timer but rather you wait until data is available.) b. Read one byte c. Add that byte to a thread safe queue. d. Go back to a. 4. In your GUI code (or wherever) you read data from the queue and do whatever you want with it. Note that this occurs in a different thread.
-
You need to do the following. 1. Determine the actual baud rate. In your other code you suggested 9600. Presumably that is correct. 2. Create a thread. 3. That thread does the following and NOTHING else. a. Block on the serial port. (You don't use a timer but rather you wait until data is available.) b. Read one byte c. Add that byte to a thread safe queue. d. Go back to a. 4. In your GUI code (or wherever) you read data from the queue and do whatever you want with it. Note that this occurs in a different thread.
jschell wrote:
b. Read one byte
You want to read the FIFO taking out as many bytes at a time as you can. It is only for special control characters that you need to read individual bytes, such as DTR RTS CTS etc etc etc and you set those in the 'wait on mask'.
============================== Nothing to say.
modified on Tuesday, September 13, 2011 3:16 AM
-
jschell wrote:
b. Read one byte
You want to read the FIFO taking out as many bytes at a time as you can. It is only for special control characters that you need to read individual bytes, such as DTR RTS CTS etc etc etc and you set those in the 'wait on mask'.
============================== Nothing to say.
modified on Tuesday, September 13, 2011 3:16 AM
Few months back I was having the same issue of Microsecond. Windows does not provide granularity of 1 microsecond. For this reason we have used Real Time OS which is an extension to Microsoft Windows . The Timer granularity is well handled by RTOS ( provides upto 1 Microsecond , which can further modified by modifying the value of 'Ticks' of clock using some API of that RTOS.
-
Few months back I was having the same issue of Microsecond. Windows does not provide granularity of 1 microsecond. For this reason we have used Real Time OS which is an extension to Microsoft Windows . The Timer granularity is well handled by RTOS ( provides upto 1 Microsecond , which can further modified by modifying the value of 'Ticks' of clock using some API of that RTOS.
-
jschell wrote:
b. Read one byte
You want to read the FIFO taking out as many bytes at a time as you can. It is only for special control characters that you need to read individual bytes, such as DTR RTS CTS etc etc etc and you set those in the 'wait on mask'.
============================== Nothing to say.
modified on Tuesday, September 13, 2011 3:16 AM
Fat__Eric wrote:
You want to read the FIFO taking out as many bytes at a time as you can
I presume my answer wasn't clear. If you block on a read and there is in fact data available then you do not block. So many bytes are read. And a serial port is a single byte stream. So excluding an intermediate buffer mechanism it is only going to read one byte at a time. But if the API supports a buffered read then using that is certainly an option.
-
You need to do the following. 1. Determine the actual baud rate. In your other code you suggested 9600. Presumably that is correct. 2. Create a thread. 3. That thread does the following and NOTHING else. a. Block on the serial port. (You don't use a timer but rather you wait until data is available.) b. Read one byte c. Add that byte to a thread safe queue. d. Go back to a. 4. In your GUI code (or wherever) you read data from the queue and do whatever you want with it. Note that this occurs in a different thread.
-
Fat__Eric wrote:
You want to read the FIFO taking out as many bytes at a time as you can
I presume my answer wasn't clear. If you block on a read and there is in fact data available then you do not block. So many bytes are read. And a serial port is a single byte stream. So excluding an intermediate buffer mechanism it is only going to read one byte at a time. But if the API supports a buffered read then using that is certainly an option.
-
jschell wrote:
b. Read one byte
You want to read the FIFO taking out as many bytes at a time as you can. It is only for special control characters that you need to read individual bytes, such as DTR RTS CTS etc etc etc and you set those in the 'wait on mask'.
============================== Nothing to say.
modified on Tuesday, September 13, 2011 3:16 AM
-
Fat__Eric wrote:
You want to read the FIFO taking out as many bytes at a time as you can
I presume my answer wasn't clear. If you block on a read and there is in fact data available then you do not block. So many bytes are read. And a serial port is a single byte stream. So excluding an intermediate buffer mechanism it is only going to read one byte at a time. But if the API supports a buffered read then using that is certainly an option.
jschell wrote:
And a serial port is a single byte stream. So
Very very few are. As stated a single byte rcv buffer UART is a very shonky piece of hardware. The stock (what is it, 82530 or some such compatible UART on most PCs) has an 8 byte RX FIFO. Better quality UARTs on serial PCI cards will have far bigger FIFOs.
============================== Nothing to say.
