Capture data from COM port / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

Capture data from COM port

Move Thread

LAN_403

GeordieBoy

Mon Mar 30 2015, 02:49PM

Registered Member #1232 Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881

Hi all,

Can anyone recommend a good program that will enable me to capture raw data from a COM port and write it directly to a raw binary file on disk?

I'm using one of those FTDI chips to give me a 3Mbit/s serial interface for downloading 32 Megabytes of data from an embedded system that i'm currently developing. I've tried using the usual suspects like "Putty" and "HyperTerminal", and also the command line "copy com3: /b file.raw" with some success, but not without problems.

Putty and HyperTerminal try to display the raw data as ASCII characters in the window while the data is coming in, and keep de-asserting CTS (flow control) to temporarily suspend the transmission of data. As a result the download of data takes about 3 times longer than it should. I can't find any way of disabling the screen updates. After all, I have no need to see a window full of flickering hearts and diamonds

For some reasons the command line "copy com3: /b file.raw" stops directing the received stream to the file after it encounters the first ASCII "EOF" character, which inevitably happens in several places in my raw data transmission. This seems strange, as I thought that the "/b" switch was meant to tell the copy command that it's dealing with a raw binary file and stop this behaviour. (It works for transmission of a raw binary file using the command "copy file.raw /b com4:" but not for reception.)

So can anyone recommend a good utility for redirecting raw received COM data to a disk file on a Windows PC?

Many thanks in advance.

-Richie Burnett,

Linas

Mon Mar 30 2015, 03:19PM

Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721

do you must use UART, or you can use SPI (FT2232H/D)

With SPI and labview it is easy to get data at 12Mbps from MCU, but Labview acts as master, and mcu use dma to send data

GeordieBoy

Mon Mar 30 2015, 03:39PM

Registered Member #1232 Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881

I could use SPI.

My system actually consists of a dsPIC processor to perform the data-acquisition and some basic DSP processing, with a high-speed SPI connection to a Spansion 32MByte FLASH chip to store the results. I'm really just wanting to download the 32MB worth of data out of the FLASH chip to the PC so that I can check everything is functioning correctly in the acquisition software.

One option would be for me to remove the SPI flash chip from the system and read it in a Flash chip programmer. It's just a bit inconvenient. I went down the UART/FTDI/USB route to download the data because my dsPIC chip has a spare UART available and I had one of the ready-made TTL-232R-3V3 FTDI cables lying around. So I thought i'd make use of that option and leave it connected while debugging.

I have Labview available where i'm currently doing the work, but may encounter problems getting my employer to license it for use on other computers where I might want to download data too. That's why I was hoping for a more generic solution if possible. I suppose I can live with the Putty download speed, with it's flickering and bell sounds, but thought there might be a better utility. Putty also puts a "----- Captured by Putty -----" header at the start of the capture file too, which is mildly annoying because i have to strip that out.

FWIW, the final incarnation of what i'm working on will actually download it's results wirelessly. I'm quite prepared to wait a longer time for the download then, but it's a pain in the backside waiting 15 mins for download during the debugging stage just to know what i've written to the Flash chip.

-Richie,

Linas

Mon Mar 30 2015, 03:49PM

Registered Member #1143 Joined: Sun Nov 25 2007, 04:55PM
Location: Vilnius, Lithuania
Posts: 721

i have all programs that can be used with Labview or VisualStudio,

solution would be just send data to flash, go to High z state, and connect FT2232D/H and read data, i could do that with visual basic in no time :) ( write address, read 66565 chars, write address, read 65535 chars, do intull you have data you want)

This is how i implemented DSP programmer, DSP use 2MB flash for program, and FT2232D put dsp in reset, connect to SPI bus via buss drivers, reprogram flash, and release dsp from reset, you just have to do reversal of this action, easy

GeordieBoy

Mon Mar 30 2015, 06:13PM

Registered Member #1232 Joined: Wed Jan 16 2008, 10:53PM
Location: Doon tha Toon!
Posts: 881

It seems like I have a workable solution...

Linas, when you mentioned Visual Basic it made me think about trying to write a simple QBasic program to read from the COM port and write the bytes straight to a file. I've got QB64 on this PC but never thought it would be anywhere near fast enough to cope with comms at 3Mbits/s. Well, it was!

I managed to transfer a known 16MByte PRBS test pattern from the flash memory to the PC and write it to disk in almost exactly 60 seconds. I thought that the QBasic program was probably dropping the CTS line to throttle the data rate, but working out the timing suggests 2.8Mbits/s. That's plenty fast enough for this debugging application

(I even tried the download with streamed video (BBC iPlayer) running in two IE windows at the same time and was amazed that it didn't drop a byte, and only slowed to about 2.5Mbits/s.)

QBasic has obviously progressed since the last time I played with it 30 years ago!

Linas, It's nice to know that I can go faster than 3Mbits/s too if I need to. The SPI option would be nice too. As you said I already have the SPI bus and could also possibly DMA some data straight from the DSP to the FT2232 chip that you mentioned to help with debugging. Lots of options.

For now I'm happy, that I have something that works, but it's nice to know some other options. The people at work will most likely like the Labview option because they have a history of using it.

Many thanks,

-Richie,

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob