Speed of RS232 functions. [1/1]

[John Cameron]

Hi,

I am developing an embedded controller and a CVI application that
communicates with it.

The embedded controller uses a USB - UART bridge and has a driver for
the PC that creates a virtual COMs port.

The embedded control has a function to erase a flash memory card. The
function is invoked by a command from the CVI application sent via
RS232. When each page (and there are 4096 in total) has been erased the
embedded device sends a 5 byte string to the PC (page number and \r E.G.
"0001\r").

Erasing a page takes a maximum of 8ms (in practice it is a little
quicker) and the entire erase function is completed in about 25s.

Using Hyper Terminal all of the page numbers transmitted by the embedded
controller are received and disp
layed within 25s as expected.

However, using CVI the erase function still completes in 25s (I have an
LED on the embedded controller to tell me when it's over) but CVI
continues to receive data for a further 193s (8.7 times longer).

No data is lost or corrupted and no additional data is received.

The figures above are for CVI in debug mode, in release mode it is
quicker but not much.

Task manager shows 99% CPU system idle process, so it doesn't look as
though I've written code that sits in a resource hungry loop.

I have attached a file showing the CVI function I am using.

If anyone could shed some light on this I would be grateful.

I also suspect that something similar happens when data is transmitted
by CVI RS232 but it is harder to prove.

CVI 7.0.0 (393)
Windows XP Home SP1
Intel 2.4GHz 512Mbytes RAM
Cypress CP2101 USB - UART bridge.

--
Regards,

John Cameron.
Type softly, read gently.

[Jattie]

Your problem lies in your loop:


See my previous explanation of the serial communications under windows.

I also previously experienced issues with the serial communications functionality under windows with fast response times if there is not a lot of data transmitted. It's almost as if the buffer waits for a longer period before servicing it and giving it back to CVI. This can be overcome iusing direct SDK calls, but that's redesigning the wheel.

A simpler solution in your case would be to make your loop respond faster. I would bet that the delays occ
ur at the ComRd (port, msgStr, 5); function in your control loop. Decrease the wait time in your SetComTime (port, 1.0); to a smaller number like 0.1 see what happens.

You might get more that one response back at a time, but if you get a message every 8ms that should work. The way the serial routine works it might not get updated if it sits in a call waiting for the buffer to reach a count of 5 and especially in debug mode.

You might want to use a diffirent read method as well and read a terminated buffer instead bu using ComRdTerm (1, , , );

Let me know how you get on!

[John Cameron]

>Let me know how you get on!

Thanks for the rapid response.

I tried shortening the time out (to a value just above one which
actually causes a time out) but that made little difference.

I also tried using the ComRdTerm() function as you suggested with long
and short time outs but that made little difference either.

I then installed a comms callback (see attached) and that makes a big
difference. The data is all received within the 25 seconds it is sent in
(as near as I need to know anyway).

I need to tidy up the process as the final finished message gets
incorrectly dealt with by the comscallback but that is straight forward.

I'm now going to have a look a transmitted data.

--
Regards,

John Cameron.
Type softly, read gently.