Perhaps you should be thinking of using an external dedicated processor for your application ? Something that has decent on die ADCs. Something like the TI C2000 line ?
There are many dev kits here which include but are not limited to just the C2000 products: http://www.ti.com/lsds/ti/tools-software/launchpads/launchpads.page If one of those processors / dev kits would be good enough, then the problem just becomes how to get that data over to the Beaglebone. Assuming a Beaglebone would still be required. As far as the PRUs go. There is a project on github called "BeagleLogic" that claims to be able to Sample up to 14 channels, 8-16bit data, at 10-100Mhz. So maybe you could sift through the project information, and source code to *maybe* figure out a way to make what you want to do - Work. On Sun, Nov 27, 2016 at 8:25 AM, Ruth Ivimey-Cook <[email protected]> wrote: > Hi > > I'm new to BB but not new to hardware/software engineering. My reason for > posting is that I am struggling to connect it to the Beaglebone in a way > that permits fast data capture, and I am hoping that someone might be able > to offer suggestions. > > My (hobby) idea is to create a device that can read 6 to 8 channel audio > and use sonar data analysis such as audio beamforming to analyse > environmental sound, in the first instance to identify the direction sounds > are coming from: https://en.wikipedia.org/wiki/Acoustic_source_ > localization > > I have been looking to use a high-speed ADC such as the £12 AD7761 - an 8 > channel, 16-bit true simultaneous sampling converter capable of 100HKz > sampling, which uses SPI for device control but a much simpler serial data > channel (using 1, 2 or 8 lines) for the analog samples. The max audio data > rate is thus approx 12MBits/s sustained (96KHz sample rate). However, each > 16-bit sample on the 7761 is output as a 24-bit value, with the 8 > additional bits including channel/sample metadata. Thus the device-level > data rate is around 18.5MBits/s for all 8 channels. The recommended Data > I/O clock rate for the device is, however, 32.6MHz. Although it will work > slower, there are impacts elsewhere. > > The device has 8 serial output data lines and a sync line indicating start > of the 24-bit data frame on the data lines. The next sample (either next > channel or next in time, depending on configured # channels and outputs) > follows on immediately. The device can either interleave all sample data on > 1 line, split it across 2 lines, or use 1 dedicated line per channel. > Byte-parallel output is not possible. > > Something like: > > DS ____-_____-_____-__ > Ch1 ____XyyyyyXyyyyyXyy > .. > ChN ____XyyyyyXyyyyyXyy > > X=first bit of frame, y=other bits in frame. > > Ideally I was hoping that I could use a PRU to read the data stream, so > that the host ARM-8 could be left running the analysis software in peace. > The analysis will involve performing continuous FFTs or similar so the A8 > won't be idle! Ideally the PRU will move the channel data into > pre-allocated host memory buffers, one buffer per channel, so that the host > can do its stuff. I'm thinking something like a DMA-based Ethernet chip > works. > > Initially I hoped to use the GPIO pins for serial or byte-parallel input: > > - I don't think even a PRU can 'bit-bang' the port fast enough to work at > even 20MHz, let alone 32MHz. > > - I cannot see a way of using the 28-bit serial input(s) on the BB: the > pin seems to be in use by the BB, and even if available, how can I only > grab 24 bit not 28 bit data, and take note of the DS line? Very curious as > to why this port is not 32 bit and triggered more flexibly. > > - Byte-parallel input would help with data rate issues but I cannot seem > to find a group of 8 sequential pins on the same PRU input port other than > the LCD pins, which seem to be needed for HDMI output. If that could be > sorted at one point I was thinking of reading 4 bytes of 6 bits at a time > and using the 2 bits per byte as a counter, so as to ensure the PRU remains > in sync with the stream. I would much prefer not to, but HDMI/LCD could be > sacrificed. > > - I looked at using a dedicated chip: of these the 74HC673 16-bit > serial-parallel converter looked very helpful, but I wasn't sure how to > read 16-bits then 8 bits at a time and retain sync, and again, which 16 > lines can be read by a single 16-bit PRU read? > > - I looked into FPGA use, and still think that would probably work and > may even offer some real advantages, but the assembled LOGI-bone uses an > obsolete FPGA and is expensive, the LOGI-bone 2 is even more so, and though > a cheap 44-pin FPGA is not, there is still quite a bit of faff getting it > connected and programmed. If an FPGA were the answer I would like to > implement a small (8-word?) FIFO in it, but otherwise it's job would mainly > be to interface the ADC to the Sitara. > > - I keep wondering about SPI, but I need one Sitara SPI channel for the > ADCs own use of SPI and I know the BB uses one Sitara SPI channel itself; I > think that leaves one channel left. Could the BB SPI (even if I can convert > the data stream properly) handle data at ~ 20Mbits/sec including protocol > overheads? > > Any thoughts/advice gratefully accepted! > > Ruth > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beagleboard/80611f79-af0e-43d4-9658-d7b50e84c680%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/80611f79-af0e-43d4-9658-d7b50e84c680%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrvjjeGPNCh_9aYYheXqqurqpi9sgR2WsHgwx_7qGLsNw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
