Hi Thomas,
 Thanks for the information! Greatly appreciated. I was leaning in the direction you mentioned actually since I was not sure what kind of signal I'd get out of the ALSA libs. (ie scaled, or processed into float etc.) I've got the skeleton of a char driver written, and I've been trying to transmit some data out of McBSP3 using a Chestnut board (no LCD attached). So far, I've re-compiled u-boot with the following in my overo.h file:

MUX_VAL(CP(MCBSP3_DX), (IEN  | PTD | DIS | M4)) /*GPIO_140*/\
MUX_VAL(CP(MCBSP3_DR), (IDIS | PTD | DIS | M4)) /*GPIO_141*/\
MUX_VAL(CP(MCBSP3_FSX), (IEN  | PTD | DIS | M4)) /*GPIO_143*/\
MUX_VAL(CP(UART2_CTS), (IDIS | PTD | DIS | M1)) /*McBSP3_dx*/\
MUX_VAL(CP(UART2_RTS), (IEN  | PTD | DIS | M1)) /*McBSP3_dr*/\
MUX_VAL(CP(UART2_TX), (IDIS | PTD | DIS | M1)) /*McBSP3_clkx*/\
MUX_VAL(CP(UART2_RX), (IEN  | PTD | DIS | M1)) /*McBSP3_fsx*/\

I'm using (and always will be) an Overo Water, so there is no bluetooth mounted. The above should route McBSP3 to the GPIO144,-147 on the 40pin header if I read and understood everything correctly.

From there my omap_mcbsp_reg_cfg looks like this:

struct omap_mcbsp_reg_cfg ads1274_cfg = {
0x0000 | FREE, //spcr2
0x0000, //spcr1
0x0000, //rcr2 RPHASE (bit 15) | RFRLEN2 (14 - 8) | RWDLEN2 (7-5) |RREVERSE(4-3) | RSVD 2 | RDATDLY
0x0038, //rcr1  -- 24 bits 4 words
0x0000, //xcr2
0x0038, //xcr1
GSYNC | FSGM | FPER(200), //srgr2 -- sample rate generater
FWID(10) | CLKGDV(8), //srgr1
0x0000, //mcr2
0x0000, //mc1;
CLKXM | CLKRM | FSXM | FSRP | FSXP , //pcr0;
0x0000, //rcerc;
0x0000, //rcerd;
0x0000, //xcerc;
0x0000, //xcerd;
0x0000, // rcere;
0x0000, // rcerf;
0x0000, // xcere;
0x0000, // xcerf;
0x0000, //rcerg;
0x0000, // rcerh;
0x0000, // xcerg;
0x0000, //xcerh;
0x0000, // xccr;
0x0000, //rccr;
0x0308 //syscon

I can request the BSP, start it, and poll write to it with no error. The problem is after I start the McBSP I see my clock on the header, but I never see any data on any of the lines. DX and FSX never change. I'm almost positive it's something simple like not configuring the clocks correctly. You were correct about my goal, the ADC I'm interfacing to will be running at 96 KHz on 4 channels. So my goal is to use the internal SRG to run everything and DMA the four 24 bit frames into memory.

I also tried the SPI wrapper found in the platform driver code with similar results, I'd get a free running clock, but no data would ever come out. Ideas anyone? 

Best Regards,

On Sun, Dec 27, 2009 at 7:39 AM, Thomas Søhus <list@ceepro.dk> wrote:
Hi Alex,

Depending on your specific use case for the ADC, I would not consider using
the ALSA drivers. I guess you want to use McBSP in SPI mode and use the
frame sync signal for sample generation? – Then the best choice is to write
an ADC char driver that utilizes the McBSP library directly.
I have written an ADC char driver that does exactly this. I had to correct a
few small errors in the Linux McBSP library code and in the DMA library as
well to get it to work, but other than that it went pretty smooth.
If you have any additional questions, feel free to ask.

Best Regards,
Thomas Søhus, CeePro | Embedded solutions, www.ceepro.dk

From: Alex Stewart [mailto:kingsquirrel@gmail.com]
Sent: 22. december 2009 15:28
To: General mailing list for gumstix users.
Subject: [Gumstix-users] ADC/ McBSP advice and questions about writing a

Hello gumstix list!
Hopefully some kind sole can  help me.
My goal is to connect a serial ADC to McBSP3. It must be a McBSP (and not
McSPI) so we can use the sample rate generator to run the sample clock. I've
got an overo water and a chestnut board. My question is what is the best way
to go about writing the code. I see I can either write a driver that
interfaces to the McBSP library in the kernel, or add the ADC into the ALSA
framework. Initially I thought adding to the ALSA framework would be the
easier task, but as a hardware engineer I quickly got lost in the layers of
abstraction and could not figure it out. So I tried writing a simple char
driver wrapper for the McBSP library. Am I correct in thinking the steps to
get this all working are to request the bsp, stop the bsp, configure it,
then issue a mcbsp start, at which point I can call things like
omap_mcbsp_xmit_word? Thats what my code currently does but it hangs at the
"wait_for_completion" line in the xmid_word code.

I realize seeing my driver code would help, but I wanted to get to the root
question first. Is writing a simple char driver to DMA my raw adc data into
a userspace buffer easier than simply not reinventing the wheel and adding
support for my adc into the ALSA stuff...? 

Thanks for the help and advice!

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.717 / Virus Database: 270.14.117/2581 - Release Date: 12/22/09

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
gumstix-users mailing list