From: Alex S. <kin...@gm...> - 2009-12-22 14:28:15
|
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! -Alex |
From: Thomas S. <li...@ce...> - 2009-12-27 12:56:26
|
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:kin...@gm...] Sent: 22. december 2009 15:28 To: General mailing list for gumstix users. Subject: [Gumstix-users] ADC/ McBSP advice and questions about writing a driver. 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! -Alex 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 09:09:00 |
From: Alex S. <kin...@gm...> - 2009-12-28 15:03:09
|
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: /*Bluetooth*/\ 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_CLKX), (IDIS | PTD | DIS | M4)) /*GPIO_142*/\ 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, -Alex On Sun, Dec 27, 2009 at 7:39 AM, Thomas Søhus <li...@ce...> 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:kin...@gm...] > Sent: 22. december 2009 15:28 > To: General mailing list for gumstix users. > Subject: [Gumstix-users] ADC/ McBSP advice and questions about writing a > driver. > > 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! > > -Alex > 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 > 09:09:00 > > > > ------------------------------------------------------------------------------ > 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 > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Alex S. <kin...@gm...> - 2009-12-29 17:38:16
|
Hello group! Maybe a kind sole out there can point out my error or miss configuration. I'm trying to get a char driver written that uses McBSP3 on the Overo Chestnut breakout board. I'm using an overo water (no bluetooth or wifi) and I've recompiled u-boot with McBSP3 Muxed out over what used to be the pwm gpio (see previous post below for Mux settings). I've also disabled the init code that sets those lines up for the LCD as GPIO, and disabled the bluetooth daemon. Currently my McBSP config is as follows: static struct omap_mcbsp_reg_cfg mcbsp_regs = { .spcr2 = FREE, .spcr1 = RINTM(0), .rcr2 = RFRLEN2(OMAP_MCBSP_WORD_8) |RWDLEN2(OMAP_MCBSP_WORD_8) | RDATDLY(1), .rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_8), .xcr2 = XFRLEN2(OMAP_MCBSP_WORD_8) | XWDLEN2(OMAP_MCBSP_WORD_8) | XDATDLY(1), .xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_8), .srgr1 = FWID(15) | CLKGDV(50), .srgr2 = CLKSM | CLKSP | FPER(255), //| FSGM .pcr0 = FSXM | CLKXM | CLKRM | FSRM | FSXP | FSRP | CLKXP | CLKRP, //.pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ }; My driver sets up McBSP3 for polled mode, when I start it up with the FSGM bit set, I see my FSX line toggling as expected, however when I look at the DX line and try to send a byte: ret = omap_mcbsp_pollwrite(OMAP_MCBSP3, 0x53); Nothing happens. With the FSGM bit not set (IE FSX happens when the transmit buffer is not empty), my FSX lines stops toggling. Any call to omap_mcbsp_pollwrite does not generate a FSX or any data on DX. I'm sure its something simple I'm missing here. Printing the value of SPCR2 before and after calling pollwrite shows the XSR always empty.... Any help or pointers would be very appreciated. Cheers! -Alex ps - Also in the above scenarios, the McBSP lib never returns an error, all the pollwrites and configures return 0. On Mon, Dec 28, 2009 at 10:02 AM, Alex Stewart <kin...@gm...>wrote: > 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: > > /*Bluetooth*/\ > 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_CLKX), (IDIS | PTD | DIS | M4)) /*GPIO_142*/\ > 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, > -Alex > > > On Sun, Dec 27, 2009 at 7:39 AM, Thomas Søhus <li...@ce...> 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:kin...@gm...] >> Sent: 22. december 2009 15:28 >> To: General mailing list for gumstix users. >> Subject: [Gumstix-users] ADC/ McBSP advice and questions about writing a >> driver. >> >> 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! >> >> -Alex >> 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 >> 09:09:00 >> >> >> >> ------------------------------------------------------------------------------ >> 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 >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> > > |
From: Alex S. <kin...@gm...> - 2009-12-30 19:09:20
|
After much reading , it would seem that the McBSP poll read and write functions in the API do not work for the omap 3530 out of the box. They refer to DXR1 and DXR2 (the 3530 only has a 32bit DXR)... Changing everything to DXR and DRR brought them back to life. My char driver can send and receive data using the low speed poll methods. Now that it works, I'm turing my attention to trying to get all this working with DMA. Does anyone out there have any pearls of wisdom about the mcbsp library in the kernel? Has anyone used the DMA base omap_mcbsp_xmit/recv_buffer calls successfully? Any help would be greatly appreciated! -Alex On Tue, Dec 29, 2009 at 12:38 PM, Alex Stewart <kin...@gm...>wrote: > Hello group! > Maybe a kind sole out there can point out my error or miss configuration. > I'm trying to get a char driver written that uses McBSP3 on the Overo > Chestnut breakout board. I'm using an overo water (no bluetooth or wifi) and > I've recompiled u-boot with McBSP3 Muxed out over what used to be the pwm > gpio (see previous post below for Mux settings). I've also disabled the init > code that sets those lines up for the LCD as GPIO, and disabled the > bluetooth daemon. Currently my McBSP config is as follows: > > static struct omap_mcbsp_reg_cfg mcbsp_regs = { > .spcr2 = FREE, > .spcr1 = RINTM(0), > .rcr2 = RFRLEN2(OMAP_MCBSP_WORD_8) |RWDLEN2(OMAP_MCBSP_WORD_8) | > RDATDLY(1), > .rcr1 = RFRLEN1(OMAP_MCBSP_WORD_8) | RWDLEN1(OMAP_MCBSP_WORD_8), > .xcr2 = XFRLEN2(OMAP_MCBSP_WORD_8) | XWDLEN2(OMAP_MCBSP_WORD_8) | > XDATDLY(1), > .xcr1 = XFRLEN1(OMAP_MCBSP_WORD_8) | XWDLEN1(OMAP_MCBSP_WORD_8), > .srgr1 = FWID(15) | CLKGDV(50), > .srgr2 = CLKSM | CLKSP | FPER(255), //| FSGM > .pcr0 = FSXM | CLKXM | CLKRM | FSRM | FSXP | FSRP | CLKXP | CLKRP, > //.pcr0 = CLKXP | CLKRP, /* mcbsp: slave */ > }; > > My driver sets up McBSP3 for polled mode, when I start it up with the FSGM > bit set, I see my FSX line toggling as expected, however when I look at the > DX line and try to send a byte: > ret = omap_mcbsp_pollwrite(OMAP_MCBSP3, 0x53); > > Nothing happens. With the FSGM bit not set (IE FSX happens when the > transmit buffer is not empty), my FSX lines stops toggling. Any call to > omap_mcbsp_pollwrite does not generate a FSX or any data on DX. I'm sure its > something simple I'm missing here. Printing the value of SPCR2 before and > after calling pollwrite shows the XSR always empty.... > > Any help or pointers would be very appreciated. > > Cheers! > -Alex > > ps - Also in the above scenarios, the McBSP lib never returns an error, all > the pollwrites and configures return 0. > > On Mon, Dec 28, 2009 at 10:02 AM, Alex Stewart <kin...@gm...>wrote: > >> 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: >> >> /*Bluetooth*/\ >> 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_CLKX), (IDIS | PTD | DIS | M4)) /*GPIO_142*/\ >> 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, >> -Alex >> >> >> On Sun, Dec 27, 2009 at 7:39 AM, Thomas Søhus <li...@ce...> 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:kin...@gm...] >>> Sent: 22. december 2009 15:28 >>> To: General mailing list for gumstix users. >>> Subject: [Gumstix-users] ADC/ McBSP advice and questions about writing a >>> driver. >>> >>> 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! >>> >>> -Alex >>> 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 >>> 09:09:00 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >> >> > |
From: Rand <ran...@ya...> - 2012-09-27 12:12:46
|
Hi all, My goal is to connect a serial ADC to McBSP (same as Alex) I'm using GUMSTIX fe com with SUMMIT board. Can anyone send me a c code that can help me at ran...@ya... Thanks a lot Rand -- View this message in context: http://gumstix.8.n6.nabble.com/ADC-McBSP-advice-and-questions-about-writing-a-driver-tp639140p4965517.html Sent from the Gumstix mailing list archive at Nabble.com. |