help needed!!!!

I assume you are using: TMS320C6455 DSP starter kit (DSK).

http://c6000.spectrumdigital.com/dsk6455/v2/files/6455_evm_techref.pdf

- TMS320C6455 DSP starter kit (DSK) features a Serial RapidIO (sRIO) bus interface for multiprocessor system.

- Another option is to use HPI interface. But I dont see the DSP starter kit having this interface supported between the two cards (DSK board and Mezzanine board)

- However, another way to communicate to  DSP is through I2C module. Configure I2C as Master on on DSP and as Slave on another for data transfer from one DSP to another. Please check whether the I2C bus from both the boards are connected through the J9 connector.

Yes I'm using the TMS320C6455 DSP starter kit (DSK) but without the Mezzanine board.

Actualy the problem is not how to conect the 2 dsp's because between the 2 dsp's will be another device (a cip that we want to test if it's working ) so the output signal from the first dsp won't be the same input signal of the second dsp. I didn't specify this because i wanted to keep it simple.... so let's suppose that we have 2 pins I and O on each dsp and A1 is conected to B2 and A2 to B1 with 2 copper wire's.

My problem is how to controle those pins (and what pins do you sugest to work with) ;

where should i save the file that i want to send (wich memory location is easier to acces because i will need to read one bit at a time );  

is it possible to do this in C or i olso need to work in asm ?

if you have some project's in wich  you used GPIO (i was thinking to use this pins) , accesed to the dsp memory  or used time functions please send me.

Thank you!

Burli

Since your question has to do with how to use the C6455, it is appropriate to post it in this forum. And thank you for sending your posting to the TI E2E Community. And you have chosen a very powerful DSP.

Since you are new to DSP, please permit me to talk like an old-timer. One of the most helpful things that we can do on this forum is to help you understand your problem and how to describe your solution. It is very common to start with the statement of the real problem you want to solve and then move too quickly into the details of the solution as you envision it. But we really need to go back to that original statement of the problem you want to solve, then look for choices of solutions before going into the details of one possible solution.

If the project goal is as simple as sending a 50Mbps serial bit stream of data from DSP1 to DSP2, there would be a variety of solutions, some of which were pointed out by Nagabhushan. The McBSP serial port would be the absolute easiest solution, in my opinion. With the McBSP, you would program a DMA channel, start the transfers, then the DSP would do nothing but wait until the transfer was completed.

If the project goal is to send a 50Mbps serial bit stream of data from DSP1 to a Comm I/F Proc, there would again be a variety of solutions, possibly including some of the ones pointed out by Nagabhushan. The McBSP serial port would still be a very attractive solution, but it would depend on whether the CIP can connect with it.

If the project goal is to implement the specific 50Mbps serial bitstream protocol you have defined here with a sync header, clock recovery, and an unspecified amount of data before the next sync header, then you may need to do some more analysis of the problem and capabilities of the C6455 before we can help you best. For example, clock recovery requires a much higher sampling speed than the data rate so if we still assume 50Mbps data rate then you would need to sample the data at 8x to 16x which would not leave much time for the DSP to do any decision making. Another example would be that the GPIO pins cannot be sampled or toggle much faster than 20ns and possibly not quite that fast - a validation test on your DSK would be required to see how fast you could do either.

If you would, please explain more about the high-level goal of your project. Required data rate or preferred data rate, which CIP you want to use, what the other constraints might be on the system.

The C6455 gives you a huge range of possibilities, but it is also easy to specify things it cannot do.

Thank you for your interest in my problem.

Yes the project goal is to implement the specific 50Mbps serial bitstream protocol. There will be only one output pin and one input pin on each DSP . Between the DSP's will be the cip that we want to test. For every bit of 1 that I want to send the cip should receive a few rising edge's (1--3; but if it cannot togle so fast as to generate 3 edges every 20ns ... it will be enough just one edge). The second DSP will receive from the cip a continuous signal (so if I send 7 consecutives bits of 1 it will receive high voltage for 140ns ). So the sampling frequency should be twice as the data rate => sampling rate at every 10ns.

For generating the edges i was thinking of a periodic function something like :

for( i = 0 ; i < n ; i++ )    // n=1..3         i will try with 3 but if it can't n=1 it will be good enough

{    eneblepin;

     disablepin;}

OR

for( i = 0 ; i < n ; i++ )    // n=1..3 

{    nop;   //  Advanced event trigger -> toggle program action point -> Drive Pin External Pin High

    nop;   //  Advanced event trigger -> toggle program action point -> Drive Pin External Pin Low }

If the execution is too fast and they don't have enough time to toggle I will need a delay between the enable / disable instructions.  Wich is the smallest delay I can achieve ?

Today i will search for a scope and I shall try to see if they toggle as fast as I want.

The C6455 has many data path busses inside, where some are optimized for speed and some are designed for simplicity. Usually, none of this would matter to the programmer except when trying to optimize the last few cycles out of a high-performance algorithm.

The GPIO peripheral module sits on the Configuration Bus (ConfigBus) which is designed for simplicity and not for performance. Most of the activity on the ConfigBus is expected to be at the beginning of the program for configuring the peripherals rather than raw data being transfered. There are exceptional cases, like yours and like updating EDMA Param, that do require lots of access to the ConfigBus. But the time required to read one word from the ConfigBus or write one word to the ConfigBus can be slow. There is a discussion thread here where the poster has run some tests to determine the speed at which he can toggle a GPIO pin (scroll down about half-way to his Mon, May 4 2009 1:17 PM posting for where the GPIO discussion starts to get detailed). His result was that he could toggle a GPIO at only about 10MHz or 50ns per toggle. I would have expected closer to 20-25ns per toggle, but it is all in the same range.

You will learn a lot from your project if you try doing this with GPIO pins, but because of the slow speed of the ConfigBus, it may be difficult to reach the speeds you want to reach.

If you want a signal that is toggling at 100MHz 10ns and that can be sampled at that rate, the McBSP is still the right peripheral to use. If you configure it for 16-bit data, then you can write the exact header sequence out in one data write to the McBSP and it will take care of serializing it for you; 32-bit word configuration would be more efficient, but this is just an example. On the other side, you will be able to read it after every 16 sample times (or whatever word size you configure it for). And for the McBSP, since it needs to be accessed so often, the data registers are dual-mapped to 0x30000000/0x34000000 to allow the CPU or EDMA to access them quicker than through the ConfigBus.

It would be interesting to see what kind of rate you can get with the AET-generated signal. It would need a little work to do more than generate just a square wave, but I am sure you could find a way.

I took a look at the GPIO Electrical Data/Timing in SPRS276I–MAY 2005–REVISED APRIL 2009 page 248 and I found  :

Table 7-114. Timing Requirements for GPIO Inputs

1 tw(GPIH) Pulse duration, GPIx high 12P

2 tw(GPIL) Pulse duration, GPIx low 12P

Table 7-115. Switching Characteristics Over Recommended Operating Conditions for GPIO Outputs

3 tw(GPOH) Pulse duration, GPOx high 36P - 8

4 tw(GPOL) Pulse duration, GPOx low 36P - 8

where P  = 1/CPU clock frequency in ns. For example, when running parts at 1000 MHz, use P = 1 ns.

Burli said:

Table 7-114. Timing Requirements for GPIO Inputs

1 tw(GPIH) Pulse duration, GPIx high 12P

2 tw(GPIL) Pulse duration, GPIx low 12P

The input Timing Requirement above shows the minimum pulse that is guaranteed to be viewable through the GPIO peripheral. If you are using edge-triggered or level-sensing interrupts (available on some devices), then a pulse that is shorter than this spec might be missed. This does not tell you the fastest rate at which you can read the GPIO peripheral. But it does at least point to the fact that you will not be able to reliably read a signal that changes at a 10P or 10ns rate.

Burli said:

Table 7-115. Switching Characteristics Over Recommended Operating Conditions for GPIO Outputs

3 tw(GPOH) Pulse duration, GPOx high 36P - 8

4 tw(GPOL) Pulse duration, GPOx low 36P - 8

I am very surprised that this spec is so high. This says that the fastest toggle rate would be 36P or 36ns. But even if I question whether you could actually go a little faster, you would still not be able to get it down to 10P. And as the note (2) says below that spec, "This parameter value should not be used as a maximum performance specification. Actual performance of back-to-back accesses of the GPIO is dependent upon internal bus activity." We could read that to mean you might get a little faster or you might get slower results if your internal busses are heavily loaded.

I will continue to recommend the McBSP as a very good fit to my understanding of your project, until you tell me to drop it.

Yes you are right about GPIO pins, they are not what I need because they are not fast enough...

I will surely use McBSP for input because if it works at 100Mhz it's exactly what I need. For the output i still want to see the AET how fast can it toggle (maybe I cand achieve more than one rising edge each 20ns). If AET is not faster than McBSP then I will use McBSP also for output. I didn't managed to find a scope but as soon as i find one i will post here the results and will see which solution is better.

I foun in help :

"On the other hand, what if you add a Program Action Point that drives a pin high at location 0x100? If you halt the CPU at location 0x100 and step over location 0x100, the pin will only be driven high for one cycle. This happens because the AET drive pin job will get reprogrammed when you do the step, resetting the underlying hardware."

this means that it can toggle every 2ns ?? Where do i find the External Pin's on the C6455 DSK (their location).

The external pins should be EMU0 and EMU1 on the emulation header. Sometimes they are refered to as ET0 and ET1 in the tools like AET. I will caution you that even though this sounds like a high-speed signalling method, it is not intended for that use and is very likely not going to behave the way you want or expect.

Where "in help" did you find the text you have quoted above?

 Help menu -> contents -> Advanced Event Triggering ->  Troubleshooting -> Reprogramming Jobs When the CPU Halts.  

Yes I know that it was not intended for that use but I want to explore this posibility also, because it could be what I was searching. I'll return wih the results...