Any do any TI DSP coding?

CodeX

2[H]4U
Joined
Mar 21, 2006
Messages
2,879
So I just got a job writing embedded C and ASM code for a Texas Instruments DSP chip. The project we are working on now will be a fiber line testing tool. Basically, you hook it up to a fiber optic cable, it sends out laser light through the cable and times how long it takes to get a signal back and also measures the amount coming back.

The output is put on a graph showing the amount of signal being received over the entire length of the cable. So for instance if you see a spike in the middle and a rapid drop off it means there is a pinch point or sharp bend (or even a complete break) at that point in the length of the cable. It has a resolution down to about a meter, which if you think about it is pretty amazing since the speed of light is like hundreds of miles per second.

My first task is getting the SPI (serial peripheral interface) to work to access a dataflash chip that we will be using to store the results of the scans. I should be ok with that but after that I am supposed to interface with this graphics chip that drives the LCD display to output all the graphical data, like menus and the graph of the data itself. I am a little uneasy here and hope I will be able to figure it out lol.

So if anyone has experience with anything like this let me know so I can ask you stuff if I get stuck
 
So I just got a job writing embedded C and ASM code for a Texas Instruments DSP chip. The project we are working on now will be a fiber line testing tool. Basically, you hook it up to a fiber optic cable, it sends out laser light through the cable and times how long it takes to get a signal back and also measures the amount coming back.

The output is put on a graph showing the amount of signal being received over the entire length of the cable. So for instance if you see a spike in the middle and a rapid drop off it means there is a pinch point or sharp bend (or even a complete break) at that point in the length of the cable. It has a resolution down to about a meter, which if you think about it is pretty amazing since the speed of light is like hundreds of miles per second.

My first task is getting the SPI (serial peripheral interface) to work to access a dataflash chip that we will be using to store the results of the scans. I should be ok with that but after that I am supposed to interface with this graphics chip that drives the LCD display to output all the graphical data, like menus and the graph of the data itself. I am a little uneasy here and hope I will be able to figure it out lol.

So if anyone has experience with anything like this let me know so I can ask you stuff if I get stuck

I don't have direct DSP chip (on TI DMS series chips) programming. However, I have experience doing embedded systems using similar devices. Why did you choose SPI? Why not I2C? Also, what do you mean "interface with graphics chip"? Which chip is it, btw?

You probably can't go into too much specific information due to an NDA or such, but the more you can say about the specific ICs you'll be working with will help out a lot.
 
It has a resolution down to about a meter, which if you think about it is pretty amazing since the speed of light is like hundreds of miles per second.

It's even more impressive when you realize the speed of light is hundreds of thousands of miles per second. :p

Cool project. I started working on some DSPs last year but we decided to go a different route. I'd be interested to know how difficult it is to get your project working.
 
I don't have direct DSP chip (on TI DMS series chips) programming. However, I have experience doing embedded systems using similar devices. Why did you choose SPI? Why not I2C? Also, what do you mean "interface with graphics chip"? Which chip is it, btw?

I dont know why they chose an SPI bus, but the main board with all of the hardware was already developed when I started there.

I dont know the name of the graphics chip off the top of my head, I actually haven't even started on it yet. Since I first posted here I have setup methods to interface with the dataflash chips (and designed the file system for it), a digital potentiometer, a real time clock, and now I am working on getting USB communications working. We have a standard usb port for a memory stick and also a mini usb port to connect the device directly to a computer and I have to write routines to copy files between either.

bassman said:
It's even more impressive when you realize the speed of light is hundreds of thousands of miles per second.

Cool project. I started working on some DSPs last year but we decided to go a different route. I'd be interested to know how difficult it is to get your project working.

lol, oops. It doesn't seem that difficult to use the DSP so far. The specific one we are using has loads of sram and flash memory, we are able to store several traces (scans) in ram at a time at 16kb each. It has like 32 different general purpose IO pins that we are mostly using as chip selects. It runs at 150mhz and has a low speed clock for peripherals that can get down to just a few khz (we run most peripheral devices at 10mhz but the keyboard is run at 65khz if I remember correctly).

The only real problem we have is that we cant figure out how to separate the code we are working on from the stuff that is finalized in order to avoid burning the flash memory each time we want to run it. The flash memory is only guaranteed to 1000 writes and we are probably half way through that already and apparently just replacing the chip on the board is not an option, they would have to built a whole new development platform if we burn out the chip
 
You'd be very surprised at how many writes you'll get in the flash memory. I haven't worked with any Ti devices but the embeded PIC programming I've gotten way more writes then that out of.
 
You'd be very surprised at how many writes you'll get in the flash memory. I haven't worked with any Ti devices but the embeded PIC programming I've gotten way more writes then that out of.

PIC's use flash memory rated for between 10k and 100k writes. TI DSPs are not designed that way. The way that TI _recommends_ programming them (check their data sheets) is to not program the DSP with anything other than bootloader code and put the remainder of your program code in an external flash.

If that's not possible, then do all of your "get it working" testing in an emulator until you're confident enough to program it to the silicon.
 
I dont know why they chose an SPI bus, but the main board with all of the hardware was already developed when I started there.

I dont know the name of the graphics chip off the top of my head, I actually haven't even started on it yet. Since I first posted here I have setup methods to interface with the dataflash chips (and designed the file system for it), a digital potentiometer, a real time clock, and now I am working on getting USB communications working. We have a standard usb port for a memory stick and also a mini usb port to connect the device directly to a computer and I have to write routines to copy files between either.

That's not "all" you've got to do with USB. USB has a very specific stack that you've got to interface with. Likely, you'll be setting up your device as a USB Host so that you can read from the memory stick (to be specific, I don't know how you'll accomplish this because I don't know how your entire design is set up. USB hosts have certain restrictions placed on them). For connecting to a PC, you'll have to look at enumerating your device as a USB-HID Mass Storage device or such so that the data can easily be read by the host PC (I recommend USB-HID since it would require fewer USB drivers for you to write). This is a _very_ terse treatment of USB. For more details on how to do USB properly, I highly recommend picking up Jan Axelson's book.
 
if you are going to implement USB look into FutureTechnologies FTDI series (the [FONT=Arial,Arial]FT245R) it takes care of the painful USB stuff proving registers IC-side and a drive&dll windows/linux side

We use this chip at work in conjunction with FPGA's to provide USB interface

[/FONT]w.r.t. SPI vs I2C more hardware CHIP's are going SPI for some reason, even going away from JTAG (a fantastic boundry-scan & program interface) so much so that the flash-based FPGA from Xilinx can only be flash-bootable via SPI programming
 
[FONT=Arial,Arial][/FONT]w.r.t. SPI vs I2C more hardware CHIP's are going SPI for some reason, even going away from JTAG (a fantastic boundry-scan & program interface) so much so that the flash-based FPGA from Xilinx can only be flash-bootable via SPI programming

Which Xilinx FPGA are you talking about? Since you said "flash based" I'm going to assume that you mean the Spartan-3AN. We (I'm a Xilinx engineer) provide lots of cores for various different communications stacks, including SPI and I2C. JTAG is, and always will be, hardware dedicated since it's a good, stable standard that doesn't require many external passives to implement. The tradeoff for the secondary communications stacks is that they require space inside the device since you have to instantiate a core to use them -- but they are there if want/need them.
 
Which Xilinx FPGA are you talking about? Since you said "flash based" I'm going to assume that you mean the Spartan-3AN. We (I'm a Xilinx engineer) provide lots of cores for various different communications stacks, including SPI and I2C. JTAG is, and always will be, hardware dedicated since it's a good, stable standard that doesn't require many external passives to implement. The tradeoff for the secondary communications stacks is that they require space inside the device since you have to instantiate a core to use them -- but they are there if want/need them.

exactly that part ;)
we are only just about to start using it (been using some virtex 3's) and our main FPGA man has been reading over the 300 page app notes on that chip and there is lots of talk of SPI for programming. He did say there are ~3pins used to set SPI-based programming and OTHER programming
 
if you are going to implement USB look into FutureTechnologies FTDI series (the [FONT=Arial,Arial]FT245R) it takes care of the painful USB stuff proving registers IC-side and a drive&dll windows/linux side

We use this chip at work in conjunction with FPGA's to provide USB interface

[/FONT]w.r.t. SPI vs I2C more hardware CHIP's are going SPI for some reason, even going away from JTAG (a fantastic boundry-scan & program interface) so much so that the flash-based FPGA from Xilinx can only be flash-bootable via SPI programming

We actually are using an FTDI chip, I read through the spec sheet and it doesn't seem very complicated to get it to work, Ill find out tomorrow I guess...
 
Back
Top