Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
xPC target serial communication time delay
44 views
Skip to first unread message
Zhuo Li
Jun 30, 2012, 1:55:23 AM6/30/12
to
Hi,
After long time of signal tracing, I measured that the receving side of the xPC application produces long time delay (5~15ms for different char), while on the sending side, the time delay is small and can be ignored.
Is this due to the RS232 FIFO read block? or due to file write on the xPC file system?
I did 2 experiments, both at sampling rate 10K Hz, and FIFO block at sampling rate 1K Hz.
1. I looped the serial cable back from COM1 to COM2. and let COM1 send a char to COM2. I'm using analog data logger monitering the RS232 signal on the cable. I measured the time from _*a char being sent out*_ to that _*RS232 signal actually appear on the wire*_. It's like immediate which doesn't take visible time.
However, I received the char with COM2 about 5ms later. All the time are from xPC timeLog, so should be synchronized. Hence, I infer that the delay is produced on the receving side. I guess it due to the FIFO buffer or software?
2. I connected my target PC to my lab equipment, and let COM1 port send commands to the equipment while monitoring the RS232 signal in the mid-way.
Again, the RS232 signal shows up on the wire at the same time when my target PC sends the command out.
Then the replied signal shows up on the wire after 1 or 2 ms. however, when I looked at the logged data on my target PC, the time stamps of the replies are about 15 ms later on average.
Since it doesn't take long for my lab equipment to reply, it seems that the receiving side of the target PC produces significant and undesirable time delay.
Could anyone explain this? is this normal?
Can this be reduced by parameter setting?
Or this is inevitable?
Thanks
After long time of signal tracing, I measured that the receving side of the xPC application produces long time delay (5~15ms for different char), while on the sending side, the time delay is small and can be ignored.
Is this due to the RS232 FIFO read block? or due to file write on the xPC file system?
I did 2 experiments, both at sampling rate 10K Hz, and FIFO block at sampling rate 1K Hz.
1. I looped the serial cable back from COM1 to COM2. and let COM1 send a char to COM2. I'm using analog data logger monitering the RS232 signal on the cable. I measured the time from _*a char being sent out*_ to that _*RS232 signal actually appear on the wire*_. It's like immediate which doesn't take visible time.
However, I received the char with COM2 about 5ms later. All the time are from xPC timeLog, so should be synchronized. Hence, I infer that the delay is produced on the receving side. I guess it due to the FIFO buffer or software?
2. I connected my target PC to my lab equipment, and let COM1 port send commands to the equipment while monitoring the RS232 signal in the mid-way.
Again, the RS232 signal shows up on the wire at the same time when my target PC sends the command out.
Then the replied signal shows up on the wire after 1 or 2 ms. however, when I looked at the logged data on my target PC, the time stamps of the replies are about 15 ms later on average.
Since it doesn't take long for my lab equipment to reply, it seems that the receiving side of the target PC produces significant and undesirable time delay.
Could anyone explain this? is this normal?
Can this be reduced by parameter setting?
Or this is inevitable?
Thanks
Gordon Weast
Jul 12, 2012, 4:46:45 PM7/12/12
to
This is most likely the UART interrupt delay. If you have the UART
configured to interrupt when the hardware fifo is half full, but you
only have a few characters coming in, the UART will still interrupt, but
only after a delay of 4 character times. This is a hardware issue in
the serial port chip (UART).
If you only have short messages, you can configure the UART to interrupt
after every character. You really don't want this if you have long
messages since it greatly increases the interrupt service overhead.
Gordon Weast
xPC Target Development
MathWorks
configured to interrupt when the hardware fifo is half full, but you
only have a few characters coming in, the UART will still interrupt, but
only after a delay of 4 character times. This is a hardware issue in
the serial port chip (UART).
If you only have short messages, you can configure the UART to interrupt
after every character. You really don't want this if you have long
messages since it greatly increases the interrupt service overhead.
Gordon Weast
xPC Target Development
MathWorks
0 new messages