From: RJ <ra...@bl...> - 2009-09-03 17:51:19
|
> At 11:50 PM 8/27/2009 +0800, S°ren wrote: > > >I assume you are talking about the Overo? If so, then a data rate of > >300kHz x 10 bits + overhead is not possible. The ADC is read via the > >dedicated PMIC I2C bus, which has a top speed of around 3.3Mbits/s. > > > > Yes, that's unfortunate; we'll have to look at another ARM for the > > real-time process implementation needed. > > Thanks. > > Hold on. In case it's OK to use an external ADC the OMAP has absolutely no > problem handling the task. > > I'm currently working on a project where we are transferring ~100kHz 16-bit > data from an external ADC using McBSP. Transferring of this to main memory > using DMA is requiring as little as 1% of the ARM CPU power all included > (measured using top). > > You therefore don't need another ARM - Just another ADC, which might require > another board in case you don't plan to do any HW on your own - Agree :-) Ahh, nice. That's what I'd hoped to hear. I may pick you brain later for the nitty details on said DMA code. We'd like to use the Overo for a near-real-time data-feedback device, and so the DSP should then be free to do some 256N FFTs in its spare time as part of it. Adding an ADC is no problem; we might even be able to use 8 bits if we AGC appropriately - bandwidth and FFT performance usually go way up. Any idea as to the max DMA rate for the Overo? I have a personal project with 14 bit CCD data looking for a device to drive it, using http://www.analog.com/en/audiovideo-products/cameracamcorder-analog-front-ends/ad9990/products/product.html# that I got samples of. I'm currently pairing it with my Cypress FX2 http://www.acquiredevices.com/sermod100.jsp card, but being able to DMA direct to memory or flash would be preferable. Thank you, Ray |
From: Jason C. M. <jas...@am...> - 2009-09-03 19:41:08
|
I get the following error when I trying to compile the kernel (outside of bitbake) arm-angstrom-linux-gnueabi-gcc: error trying to exec 'cc1' : execvp: No such file or directory This error came as a complete surprise because everything was working fine a month or so ago when I left it. In fact I even created a nice VMware snapshot of everything working. All I had to do was enter in export PATH=${PATH}:/home/gumstix/oe/tmp/cross/armv7a/bin export PATH=${PATH}:/home/gumstix/oe/tmp/staging/i686-linux/usr/bin For the path for the cross compiler, and the utility to create the uimage Then I'd enter in make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage It is entirely possible that some linux update got applied before I saved the snapshot, but after I did the last successful kernel build. It's also possible that I'm forgetting some step. the cc1 is in /usr/lib/gcc (under i486-linux-gnu). Hopefully by sending this email I'll remember the second after I send it. On Sep 3, 2009, at 10:51 AM, RJ wrote: > At 11:50 PM 8/27/2009 +0800, S°ren wrote: > > >I assume you are talking about the Overo? If so, then a data rate of > >300kHz x 10 bits + overhead is not possible. The ADC is read via the > >dedicated PMIC I2C bus, which has a top speed of around 3.3Mbits/s. > > > > Yes, that's unfortunate; we'll have to look at another ARM for the > > real-time process implementation needed. > > Thanks. > > Hold on. In case it's OK to use an external ADC the OMAP has absolutely no > problem handling the task. > > I'm currently working on a project where we are transferring ~100kHz 16-bit > data from an external ADC using McBSP. Transferring of this to main memory > using DMA is requiring as little as 1% of the ARM CPU power all included > (measured using top). > > You therefore don't need another ARM - Just another ADC, which might require > another board in case you don't plan to do any HW on your own - Agree :-) Ahh, nice. That's what I'd hoped to hear. I may pick you brain later for the nitty details on said DMA code. We'd like to use the Overo for a near-real-time data-feedback device, and so the DSP should then be free to do some 256N FFTs in its spare time as part of it. Adding an ADC is no problem; we might even be able to use 8 bits if we AGC appropriately - bandwidth and FFT performance usually go way up. Any idea as to the max DMA rate for the Overo? I have a personal project with 14 bit CCD data looking for a device to drive it, using http://www.analog.com/en/audiovideo-products/cameracamcorder-analog-front-ends/ad9990/products/product.html # that I got samples of. I'm currently pairing it with my Cypress FX2 http://www.acquiredevices.com/sermod100.jsp card, but being able to DMA direct to memory or flash would be preferable. Thank you, Ray <ATT00001.c><ATT00002.c> |
From: Søren S. C. <li...@ss...> - 2009-09-08 20:23:27
|
> I may pick you brain later for the nitty details on said DMA code. We'd like to use the Overo > for a near-real-time data-feedback device, and so the DSP should then be free to do some 256N > FFTs in its spare time as part of it. Adding an ADC is no problem; we might even be able to > use 8 bits if we AGC appropriately - bandwidth and FFT performance usually go way up. > Any idea as to the max DMA rate for the Overo? Hi Ray, You are welcome. Sorry for first getting back to you now, but Im currently pretty much in a hurry :-) With Respect to OMAP max DMA rate, I really think it's normally only limited by the IP blocks requesting the DMA operation and the overall data ports (SDRC/GPMC) in/out rate. In case you choose to use the ISP for capturing data from the AD9990 chip, I think you should easily be able to go with the maximum rate of 65MSPS (with 8 bit data width this is only ~5-6% + overhead of the overall DDR memory bandwidth). The ISP goes to around 130MSPS (in 8 bit mode). More info can be found at: http://focus.ti.com/lit/ug/sprufa2b/sprufa2b.pdf Best regards - Good luck Søren |