InterConnect 2 Omap L-138

Hi Amit;

I think spi is a better option and the 15mbps is well withing the reach of the cpu. the maximum speed depends on the cpu speed you choose.

However remember that in Most cpus(if not all); the Slave drives the bus much slower than the master.

There is a separate manual for the SPI. Look at the L138's home page for the link.

Tables  6.61 and 6.62 in the datasheet shows the slave is half the speed of the master and let's you calculate the max speed.

Your massages can be done in 3 pins mode. 4 pins has more control and 5 pins; even more control; so your choice.

good luck.

Ma

Amit,

If you are familiar with usb, USB is another option.  All the driver support is already there you just have to develop the application needed on top of the existing driver support.

regards

swami

amit yedidia said:

1. What is the bitrate capable in each one of the SPI 3/4/5 pin modes?

The bit-rate is the same for the different pin modes.  The extra pins do not add any data bandwidth -- they only add hardware control lines.  The max SPI clock is spec'd at 50MHz so it should cover the 15Mbps requirement. 

amit yedidia said:

2. IN the McASP, how the seializer is working? I read the datasheet and the user guide but didnt understand the basic fact:

If , for example, I want to send 3 words (16 bit each) while using only 1 serializer what are the proper valued for WNUMDMA and WNUMEVT

and if I wnat to send 1 word (16 bit) while using 8 serializers, what are the proper valued for WNUMDMA and WNUMEVT

 

McASP is designed to transmit serialized  data so if you provide a 32-bit word to one McASP Tx serializer, it will shift out the bits serially on one pin so it would be very difficult to transmit 1 word across 8 serializers.  You would have to break the 1 word into 8 words and then reconstruct it on the other side.

When selecting the WNUMDMA and WNUMEVT values, keep in mind that the AFIFO will copy the 32-bit values from the FIFO into the McASP XBUF registers so the WNUMx values will need to match your McASP configuration.  The WNUMDMA value must match the number of enabled Tx serializers.  WNUMDMA 32-bit words are copied from WFIFO to the XBUF registers of enabled serializers.

For simplicity, let's say that you want to send three 32-bit words at a time across one serializer.  You would set WNUMDMA to 1 and WNUMEVT to any value greater than or equal to 3.

It's unfortunate that EMAC is out of the picture because it would be fairly easy to setup chip-to-chip communication across the peripheral.  UPP, McBSP, and even EMIFA <-> UHPI are other options.

-Tommy

Tommy,

Thank you very much fot your detailed answer.

I have a limit of 4/5 wires between the 2 processors.

What is your propsals between UPP,McBS or EMIF<->UHPI ? 

(ethernet is not possible so EMAC is not relevant)

Amit.

Hi Amit,

In our design, we decide to use the McBSP port to communicate between OMAP-L138 and a C55X DSP.

It is a full duplex data path with clock rates up to 50MHz, uses 3+3 pins for TX and RX.

I don't know, if you are using linux or not. But Linux BSP has a nice Kernel API driver for managing the McBSP ports.

I am writing a linux character driver by using the Kernel API functions to allow McBSP communcation from user-space.

Alper

Amit,

It really depends on your own preferences and pinmux limitations.  Personally, I would go for the simplest peripheral where the drivers are already in place.  SPI is probably the easiest.  It sounds like Alper has had good results with McBSP so that would also rate highly.

-Tommy

Hello, Tommy:

There is a problem in the same category with McBSP of Experimenter board of OMAP-L138/TMS320C6748.

The FSR1 and FSR0 (Receive frame synchronization) signals don't work. The FSR1 signal can be brought

out through the GP0[4] pin of the general I/O Port under the control of register PINMUX1, according to

document SPRUGJ6A.pdf, User's Guide of TMS320C674x/OMAP-L1x Processor McBSP Interface. But the

FSR0 and FSR1 signals can not be brought out. To verify this problem, I first let PINMUX1 = 0x00808080 and

send a logic-one signal (3.3V DC) to GP0[4]. But this GP0[4] pin does not output 3.3V DC when I measure it

with my multimeter (volt/ohm meter), its output is always a constant 0.145V DC.  But the pins of GP0[2] and

GP[6] can output 3.3V DC correctly. This makes me suspect that there may be some silicon error with FRS0

and FSR1 inside DSP OMAP-L138/TMS320C6748.

Could you please send a logic-one signal to the GP0[4] pin and see if you are able to measure 3.3V DC

at this pin out?

I need to change my DSP from OMAP-L138/TMS320C6748 to OMAP-L137/TMS320C6747 if this is indeed

a silicon problem of the DSP chip. I need the McBSP to interface a 4-channel sigma-delta ADC (TI's ADS1274).

But, OMAP-L137/MTS320C6747 only has McASP but not McBSP. Is it possible to interface ADS1274 with McASP

of OMAP-L137/MTS320C6747?

Thank you in advance.

WL

WL,

This is not a known device problem.  Can you start a new thread for this topic?  Thanks.

-Tommy

It looks like the best solution …

Alper,

Why you have to "I am writing a linux character driver by using the Kernel API functions to allow McBSP communcation from user-space."

The driver don’t give full access to mcbsp from user?

Shaul

Shaul,

In the examples directory of the Linux SDK, there is "mcbsp_test" kernel module, it show the general usage of the McBSP API's. It is not a character driver with standard read/write access from a userspace application.

Regards,

Alper

Alper,

Thanks, the mcbsp_test.c is the one I'm looking for

Shaul