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. For more options, visit https://groups.google.com/d/optout.
