Reply by David Bonnell April 5, 20072007-04-05
On Apr 4, 2:13 pm, LittleStar <LittleStar@no_spam_please.com> wrote:
> You can use CCS of course, but the transfer rate is limited.
Yes, but transfer rate isn't the deal-breaker. The problem with CCS comes down to licensing/portability/cost. I need a field debugging tool, which means one license (and emulator) per field agent. Wow...that last bit sounded like I'm part of some multi-national corporation (I'm not; I digress).
> A low cost and great product for data transfer from DSP to any other > peripheral including PC is for example Compandent's FLEXI-232 board, see:http://www.compandent.com/products_flexi232.htm
I've found a different product that may fit my needs: http://www.vinculum.com/prd_vdrive1.html Uses an SPI interface (which I have), and writes directly to a USB flash disk (cheap and available everywhere). Includes basic file/ directory support. At $25, it's very cheap for my purposes, and it should be much faster than RS232. I won't even have to connect to a PC! No licenses, emulators, cables, PCs required. Still need those pesky "field agents", though :)
Reply by LittleStar April 4, 20072007-04-04
You can use CCS of course, but the transfer rate is limited.

A low cost and great product for data transfer from DSP to any other 
peripheral including PC is for example Compandent's FLEXI-232 board, see:
http://www.compandent.com/products_flexi232.htm
If you do not need their vocoder, then perhaps you may purchase only the 
board from them.

David Bonnell wrote:
> This is slightly OT, but I figured I would ask anyway. > > I'm looking for a way to transfer data from a DSP to a file on a PC. > Are there any simple solutions or off-the-shelf products available for > this sort of thing? Ideally I'd like to either stream data or do a > block transfer into a file on the PC. > > I'm using a TI DSP with several available communication options > (McBSP, SPI, USB, MMC, I2C, UART, JTAG). > > Cheers, > Dave >
Reply by jleslie48 April 2, 20072007-04-02
On Apr 2, 10:40 am, "David Bonnell" <dbonn...@gmail.com> wrote:
> > RS232 to USB converters are available (I'm looking right now at > > model USB-2920 fromwww.cablesunlimited.comand they bump > > the baud rates to 600k. I've already written a handler to log all > > bytestreams coming in on a comm port for a PC, and with > > Code Composer v3.3 and my TI320 I can write to the Uart device > > with fopen, printf statements. Thats the CHAD solution. > > VerrRRRRry interesting. I did not realize that you could run RS-232 > faster than the normal 115k. Are you using the McBSP to perform the > write, or have you gone through a different communication channel? > > Thanks for the info, I'll definitely check it out.
Sorry, I'm brand new to DSP programming, and I'm not sure. Perhaps this will answer your question. Here is a snippet of the source C program running in the DSP: ***************************************** void FXN_io_task (void) { FILE *fid_write, *fid_read; int input; // open a stream for write and a stream for read to Uart device fid_write = fopen ("UART:DummyName", "w"); fid_read = fopen ("UART:DummyName", "r"); // write a message to Uart fprintf (fid_write, "Hello world!\r\n"); fprintf (fid_write, "Build: "__DATE__" "__TIME__" \n"); fprintf(fid_write, "Uart test with runtime library.\r\n"); fflush (fid_write); // fflush must be called to flush runtime library buffer // if not called data are collected until internal // buffer is full (255 characters) fprintf (fid_write, "Press any key to continue\r\n"); fflush (fid_write); for(;;) { // fseek() must be called since a // character device does not exist input = fgetc (fid_read); fseek (fid_read, 0, SEEK_SET); // if a key pressed if (input != EOF) { if (isprint(input) && (input < 0x80)) fprintf (fid_write, "Key %c pressed (code = 0x%02X)\r \n", input, input); else fprintf (fid_write, "Non-printable key pressed (code = 0x%02X)\r\n", input); fflush (fid_write); } // yield control to kernel // physical input and output to Uart is // done by the corresponding idle functions TSK_sleep (10); } } ************************************************** On the PC side, I wrote a console program that opens the comm port, and writes all inbound bytes to a file, and sends the keystrokes to the the DSP via the comm port. Works fine: ******************************************************* C:\jon\c\source\portcomm>dir la*.exe Volume in drive C has no label. Volume ial Number is 5CA4-941C Directory of C:\jon\c\source\portcomm 03/29/2007 12:06 PM 11,776 la_console.exe 03/29/2007 12:30 PM 11,264 la_console_ts.exe 2 File(s) 23,040 bytes 0 Dir(s) 46,008,483,840 bytes free C:\jon\c\source\portcomm>la_console_ts This is a la_console_ts mode program & is designed to run from a command window. Enter commands as :[CC][CC][D0]..[DF]cscs, case sensitive. !comment for log file >filename <filename wait 5000 (in milliseconds, up to 60000) Usage: la_console_ts <port> <baud> Eg: la_console_ts 1 9600 C:\jon\c\source\portcomm>la_console_ts 1 115200 This is a la_console_ts mode program & is designed to run from a command window. Enter terminal loop ( Type ^Z to exit ) Hello world! Build: Mar 29 2007 14:16:45 Uart test with runtime library. Press any key to continue Key pressed (code = 0x20) Key h pressed (code = 0x68) Key j pressed (code = 0x6A) Key h pressed (code = 0x68) Key j pressed (code = 0x6A) Key j pressed (code = 0x6A)
Reply by Vladimir Vassilevsky April 2, 20072007-04-02

David Bonnell wrote:

>>???? >>The RS232 transfer is a miser. It should not be affected by the CPU load. > > > The CPU still needs to do some work in order to write to the UART. My > application runs as multiple threads, and the data processing thread > has highest priority due to the real-time requirements...the > datalogging thread will get blocked for periods of time (roughly 35% > on average). Overall transfer rates will therefore be affected unless > I change the datalogging priorities. I could make the datalogging > thread higher priority, which may be a good idea as long as the data > processing thread makes the real-time deadline.
The UART is running by the interrupts, fetching the data from the buffer and sending it out. The datalogging thread only has to put the data into the buffer for transmission. If the thread provides enough data on the average, the UART will be running at the full speed.
> > As far as writing to a USB drive (etc.), I was hoping to find an off- > the-shelf solution that could be easily interfaced to my system.
Look at the FTDI web site. Not too long ago they released the IC exactly for this purpose. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by Vladimir Vassilevsky April 2, 20072007-04-02

David Bonnell wrote:


> VerrRRRRry interesting. I did not realize that you could run RS-232 > faster than the normal 115k.
Strictly speaking, it is not guaranteed. Although 230k appear to work for almost all of the modern PCs comports as well as USB/RS232 cables.
> Are you using the McBSP to perform the > write, or have you gone through a different communication channel?
On the DSP side, I am handling the UARTs by myself (I don't like the MsBSP). On the PC side, the standard WinAPI is used. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by David Bonnell April 2, 20072007-04-02
> Then you should have all you need.
Not quite. Emulators are expensive (and so are licenses for CCS). To have one JTAG emulator sitting on my desk is one thing, but the cost of multiple emulators outstrips the device's by a significant margin.
> You use fopen() on the DSP just as if it were running on the PC. I > believe the default directory is the one CCS was started up in. > > Oh yeah. Did I tell you that you have to run your code from CCS? That > is, you have to start up CCS and then run your program inside of CCS. > Somehow the file IO uses the jtag interface - don't ask me how, it's > magic to me. >
Yeah, but as long as the magic keeps working I'm fine with it! I've been manually copying/saving data to file! Fortunately, I haven't had to do much of this (yet).
Reply by David Bonnell April 2, 20072007-04-02
> ???? > The RS232 transfer is a miser. It should not be affected by the CPU load.
The CPU still needs to do some work in order to write to the UART. My application runs as multiple threads, and the data processing thread has highest priority due to the real-time requirements...the datalogging thread will get blocked for periods of time (roughly 35% on average). Overall transfer rates will therefore be affected unless I change the datalogging priorities. I could make the datalogging thread higher priority, which may be a good idea as long as the data processing thread makes the real-time deadline.
> It is mainly the question of how deep do you want to be involved. My > preference is the Ethernet, and it is not too simple either. >
Development time is an issue as well, so I'll lean in favour of simpler solutions. I'm starting to like UART if I can get higher speeds via a USB converter :) As far as writing to a USB drive (etc.), I was hoping to find an off- the-shelf solution that could be easily interfaced to my system. I did find one potential solution, but the details are a bit sketchy (I'm waiting to hear back). Cheers, Dave
Reply by David Bonnell April 2, 20072007-04-02
> RS232 to USB converters are available (I'm looking right now at > model USB-2920 fromwww.cablesunlimited.com and they bump > the baud rates to 600k. I've already written a handler to log all > bytestreams coming in on a comm port for a PC, and with > Code Composer v3.3 and my TI320 I can write to the Uart device > with fopen, printf statements. Thats the CHAD solution.
VerrRRRRry interesting. I did not realize that you could run RS-232 faster than the normal 115k. Are you using the McBSP to perform the write, or have you gone through a different communication channel? Thanks for the info, I'll definitely check it out.
Reply by Randy Yates April 2, 20072007-04-02
"David Bonnell" <dbonnell@gmail.com> writes:

>> I think the easiest way is to do direct file I/O within your DSP >> application, using, e.g., the C language fopen(), fwrite(), etc. This >> is assuming that you don't have to transfer large amounts of data >> real-time. Of course it also assumes that you can run your code with >> the debugger/PC hooked up to your target system. > > Good point Randy. I should have mentioned that I am using a JTAG > emulator for in-house development/testing, so I do have access to all > relevant data (more or less in real-time).
Then you should have all you need.
> I do not need to transfer large amounts of data in real-time. > Streaming data would be lovely (works out to about 2 bytes every 3 > microseconds!), but isn't a requirement. What type of link are you > talking about when you mention fopen(), etc.? Wouldn't the DSP need > to have knowledge of the PC's file system? Go easy, I'm still new to > this!
You use fopen() on the DSP just as if it were running on the PC. I believe the default directory is the one CCS was started up in. Oh yeah. Did I tell you that you have to run your code from CCS? That is, you have to start up CCS and then run your program inside of CCS. Somehow the file IO uses the jtag interface - don't ask me how, it's magic to me. I've used this technique many times (e.g., for running test vectors files stored on the PC through an algorithm) and it works beautifully, albeit a little slowly. -- % Randy Yates % "How's life on earth? %% Fuquay-Varina, NC % ... What is it worth?" %%% 919-577-9882 % 'Mission (A World Record)', %%%% <yates@ieee.org> % *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by Vladimir Vassilevsky April 2, 20072007-04-02

David Bonnell wrote:

>>The easiest is UART; it takes minimum of programming and no extra >>hardware. All other ways require the advanced knowledge and/or special >>hardware arrangements. If your goal is to get something for quick and >>cheap, use UART. The USB is good, but it is fairly complicated. > > > UART is a bit slow. I actually used it on the previous generation of > my project, but I'm looking to transfer about 80 kB. At maximum > RS-232 speed that's still about 7 seconds.
This is true. However most of the modern PC comports support for the bitrates higher then 115k. The speed bottleneck is the RS232 level convertor, but usually you can run up to 230k without any problems.
> Of course, the full > algorithm needs to keep running during the transfer, so such a sweep > could take minutes depending on CPU load.
???? The RS232 transfer is a miser. It should not be affected by the CPU load.
> I'm still considering UART, but something that can do the job faster > would be very attractive.
It is mainly the question of how deep do you want to be involved. My preference is the Ethernet, and it is not too simple either.
> RS-232 ports are becoming difficult to > find, particularly on laptops.
The USB to RS232 convertors work just fine. I was just looking for other potential
> options that I wasn't aware of (I'm new to this after all). In > particular, a solution that could write directly to file on a PC (or > flash drive).
You can either write to the compact flash or to the USB junk drive. Either variant is not very simple from the programming prospective. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com