Pandora Pandora Omap Mcbsp's?

[sampo_v2]

Hi,

I'm new to this board, so I guess I need to introduce myself. I'm a Linux audio geek. I mostly work on a DAW called Ardour but I also do some DSP and help around with the infrastructure (jack audio server, ffado firewire drivers).

Both the beagleboard and the pandora project have tickled my interest. The beagle as a potential base for a portable multitrack (8-16 input) recorder and the pandora as a gaming / sub-netbook platform. Then I realized: I might get both in one box, in a pandora box (lame pun intended). For proper audio i/o I need the McBSP ports in the OMAP. If I've understood correctly, I can attach digital audio i/o to it. For example ADAT could be connected with something like this:

http://www.profusionplc.com/pro/gex/pcatdt...partno=AL1401AG
http://www.profusionplc.com/pro/gex/pcatdtl0?ipartno=AL1402G

So, my question is: are there any McBSP ports available on pandoras OMAP?

I would also appreciate any comments if this is feasible / will it work / does someone have any experience with digital audio + omap. One important factor is also how well the physical construction of the pandora allows for easy access to the McBSP traces and is there room for extra connectors.


Sampo

 

[Exophase]

Two things you should know about the OMAP3530. One, the pins are very heavily muxed, so even if Pandora is not using all 5 McBSPs it'd have to have some not muxed for other functionality. Two, the OMAP3530 package is BGA so unless it brings out I/Os for McBSP somewhere on the board, maybe as test points, then it won't really be feasible to wire something to them. Everything's crammed pretty tight in the case so I don't think you'll find a ton of room for another connector, although a single McBSP should only take 6 pins, 7 if you have an external sample generator clock.

Also, I don't think there's any user space support for accessing McBSP directly so you'll probably have to write kernel drivers to accomplish it. Or bang the hardware yourself through /dev/mem but I don't recommend that.

 

[MWeston]

The good news: McBSP3 is muxed onto pins wired to the A/V connector (MCBSP3_DX,DR,CLKX and FSX). These are the same four pins brought to the expansion connector on the Beagle board too. I made an effort to specially chose these four pins because they can be PWM signals, a full UART interface or a full McBSP interface (with master clock derived internally).


Here's the bad news: The Bluetooth chip uses McBSP3 on the PCB. If you want to take over those pins, you will have to turn the BT's I2S interface into GPIO pins and set the levels so that the clock line is inactive, inputs are floating, etc. You will also want to make sure no driver is running that tries passing audio data over the BT link or it might hang waiting for buffers to change but they never will. I think the code is smart enough to just time out though.


So, the connector interface is rather easy (without ever cracking open the Pandora), the software changes are probably reasonable if you are a linux guru and about the most difficult part you will find is likely not being able to sync up to the master clock of an external pro audio device or ADC/DAC chip.

I even think the OMAP3 supports TDM for multi-track recording on one interface, but don't quote me on that. You will need to study the datasheet better.

 

[Exophase]

.

Hey, this is not a complete McBSP interface ;D It's good for SPI style master/slave but if you want independent full duplex clocking and frame sync you'd need CLXR and FSR... of course usually that's not what you want so I'm just nitpicking.

, the software changes are probably reasonable if you are a linux guru and about the most difficult part you will find is likely not being able to sync up to the master clock of an external pro audio device or ADC/DAC chip.

Are CLKX and FSX being made unidirectional somehow? Are they being ran through any buffers/level shifters or anything like that? Is the connection to the BT chip locking this? I just wonder if you can change the direction on them so they can be externally driven, since McBSP normally allows this.

I even think the OMAP3 supports TDM for multi-track recording on one interface, but don't quote me on that. You will need to study the datasheet better.

Yep, that's what the "multi-channel" part of the name specifies.

 

[MWeston]

Yes, only the 4 pin interface is available, not the 6 pin which would have CLKR and FSR. McBSP1 is the only channel on OMAP3 to do this and those pins are not available at all due to pin muxing elsewhere.

- McBSP can be both master or slave so you could drive externally as that will change each pin's direction
- The BT interface uses completely different pins to connect to OMAP (just muxed internally to McBSP3) so no conflict on pin drive at the A/V connector, just between BT and OMAP if not setup correctly.
- no buffer exists on A/V connector pins, they are raw 1.8V signals with ESD and overdrive protection (but you'd fry the pin well before the overdrive kicks in at about 6.1V) so level shifting externally is required. As mentioned a while back, these pins do not attach to anything used inside the Pandora so that if someone takes these down, they don't take down some other feature.

I now see TDM support right in the TRM. I would love to daisy chain a couple of these for full 8 channel simultaneous digital recording some day: http://www.akm.com/prodfolder-adc.asp?p=AK5388

Probably easier to just buy a USB based multi-track device, but where's the fun in that?

 

[sampo_v2]

Thanks for the quick replies. Before I continue, I have a disclaimer: I'm much more a software hacker than hardware. I've only really dealt with analog electronics plus a bit of playing around with an arduino. I do like a challenge, so that's why I'm playing around with this idea. Hence the myriad of questions..

So to sum up: For me to use the McBSP3, bluetooth needs to be physically disconnected from the OMAP?

Hey, this is not a complete McBSP interface ;D It's good for SPI style master/slave but if you want independent full duplex clocking and frame sync you'd need CLXR and FSR... of course usually that's not what you want so I'm just nitpicking.

With independent full duplex clocking, do you mean a separate clock signal for TX and RX? With audio I'm definitely interested in a single clock for input and output streams. But I do need to supply the clock from the digital input (ADAT in my case). Is this possible with the exposed 4 pins?

I'm very interested in documentation and/or schematics related to the extension port. Do you have links handy?

Regarding using an USB interface: yeah, it would be a lot easier. There are a few big gotchas with that: 1) USB1 audio devices don't do high channel counts, 2) I have bad experiences with USB1 + jack (it might work though), 3) there are no Linux drivers for USB2 devices, 4) it would be less portable.

If the OMAP would have a pci bus, then...