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
Zhuo Li wrote: > 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