5

I'm hoping to interface a Raspberry Pi 4 with an 8 channel, 48 kHz ADC. Ideally a 24 bit ADC, which if my math is right means 9.216 megabits per second. But a 16 bit ADC would be acceptable: that would bring the requirement down to 6.144 Mbit/s.

I haven't selected the specific ADC yet, so I have some freedom to choose one that supports an interface most amenable to the Pi.

I imagine the Ethernet and USB interfaces are capable of this speed, but for reasons of cost and simplicity I have to rule those out. I've yet to find an ADC that interfaces with Ethernet. There are a few with a USB interface, but they are aimed at low-cost consumer electronics and have insufficient performance for my application. Of course there are professional USB audio interfaces with excellent performace, but they cost an order of magnitude more than the Pi which would rather defeat the purpose.

Bit-banging in Python or even C over the GPIO pins, if it can work at these speeds at all, probably won't leave enough CPU to do anything useful with the data.

So I'm looking at the hardware peripherals like I2C, SPI, I2S, etc. Documentation on these is pretty scant, and it's not always clear if the limits of what actually works differ from the limits of what's configurable. So I thought I'd ask: has anyone been down this road that can confirm an interface that would meet my required speeds?

Improve this question
8
  • 1
    Yes, generally it is a taxing procedure, usually one creates a dedicated sampling controller which in modern times is an ASIC (just makes the interfacing so much easier if you implement the sample protocol as a peripheral). Of course you can bang it in software, you might be able to get enough CPU to sample and resend the sample on Ethernet and there you have created an ethernet ADC for your purposes. SPI is commonly seen or SPI derivative (QSPI...)
    – crasic
    Commented May 2, 2020 at 1:42
  • 1
    @tlfong01 he needs a 48KSPS ADS1255 which doesn't exist, and he needs 8 of them. ADS1255 is $10 a piece, so even at 30KHZ thats $80 in ADC IC"s alone, not counting auxiliary components. There is a reason the pro gear is pricey.
    – crasic
    Commented May 2, 2020 at 2:53
  • 1
    @crasic I appreciate what you are trying to do with the edit, but now you've made answers about ADC selection, which is not the problem I need help solving. Whatever ADC I select, it's going to have some minimum bandwidth. My problem is finding something on the GPIO pins that can support that bandwidth. If I need to select a different ADC, or add some external digital logic to convert formats, I can figure that out. What I need help with is finding a way to get 9216000 bits per second in through the GPIO header, somehow.
    – Phil Frost
    Commented May 2, 2020 at 4:24
  • 1
    @crasic ADS1255 would be inappropriate for my application, even if I had 8 of them and they could do 48 kHz. Please don't make this question about ADC selection. Although I haven't chosen a particular one, I do have a number of candidates. The decision comes down to which of them can interface with the Pi.
    – Phil Frost
    Commented May 2, 2020 at 4:31
  • 1
    SPI at 10Mhz works with the Pi, this is 10MBit/s therefore if you insist as is your question is trivial and should be closed. But that is not what you are asking. The detail is synchronizing 8 devices at once, which also can be done via SPI if you are clever, hence the change in question
    – crasic
    Commented May 2, 2020 at 6:44

3 Answers 3

Reset to default
4

When sampling parallel ADC's the synchronization becomes more problematic than the raw bandwidth. You have not really made it clear what your application is but I assume audio.

Your quickest turn around would be to use a COTS sampling device over USB at the best performance point you can afford.

Simultaneous sampling ADC's are an option but generally have specalized application and complex interfacing, for example ADS7850 Uses the SPI clock to sample at up to 750KHz on two channels simulataneously, but streams the data to two SPI inputs at once, known as "Dual SPI", there is also Quad SPI (QSPI), neither is supported on the Pi.

enter image description here]1 From ADS7850 Datasheet

Multiplexed ADC's are out of the question for audio applications, as they typically do round robin sampling which is fine for process control (e.g. temperature) but not for audio sampling. An example of a high perfomance multiplexed ADC is the ADS1256

enter image description here Image from ADS1256 Datasheet showing the round robin channel cycling of the ADC

So you are left with the option of sampling 8 ADC's in parallel

That mandates a low level interface, that is, 8 USB devices will not suffice. Too much jitter and overhead and very difficult to synchronize for audio sampling purposes.

Typically one sees SPI in the domain. (High Precision, moderate sampling rate)

Unfortunately SPI is a serial Bus so that means we are looking for devices that have onboard data buffers and support SPI Clocks of >10MHz* . Because we still need to clock the data out of the SPI bus before the next sample comes around

We also want devices that can be mutually synchronized so that they complete a conversion at the same time and sample the same portion of time as one another.

An example of this is the ADS1255 device which is a single channel variant of the ADS1256 above, however this device does not support 48KHz sampling, but it does have synchronization pin that can be used to synchronize multiples in parallel.

enter image description here

You would issue syncs to all the devices at once and then read the sample when ready.

So to support your application I would look for:

  • Single Channel ADC
  • SPI Interface
  • 48Ksps
  • 24Bit
  • External Sync
  • Internal Buffer
  • Support SPI clock 10 MHz

And get 8 of them. Unfortunately the ADS1255 is only up to 30KSPS

* You can split sampling across the 3 SPI buses on the RPI and reduce the clock rate requirement

Improve this answer
3
  • 1
    Are you saying the Pi's SPI will work at 10 MHz (assuming some care in layout of course) or that the 3 SPI interfaces can operate simultaneously and in a synchronized manner? Can you elaborate on that please?
    – Phil Frost
    Commented May 2, 2020 at 4:38
  • 1
    @Phil Both actually, the ADC's are synchronized per their external sync option, SPI is used to read out. You need to read out the sample data before the next sample trigger comes along and clears the ADC buffers for the next sample. If you have one interface you will need to read 24*8 = 192 bits every 20 micro seconds, which is 10MHz SPI clock assuming no overhead for read commands. If you use 3 SPI interfaces each affine to a seperate core you can split the load to 3 buses and relax the frequency requirement. In that case, the sync is still external but you read out on 3 buses at once
    – crasic
    Commented May 2, 2020 at 6:47
  • 1
    @crassic can you please elaborate on that in your answer? Information like the maximum support SPI speed, and that there are 3 SPI interfaces that can be used simultaneously (or not) is information relevant to the question. Your suggestions on ADC selection which currently form the bulk of the answer are not especially relevant, as you've assumed a lot of requirements that I don't actually have, and failed to account for other requirements I do have.
    – Phil Frost
    Commented May 2, 2020 at 21:36
4

There is a big difference between 6..9 MHz clock speed (which according to the BCM2835 datasheet is derived from 150MHz core_clk with a power-of-two 16-bit integer divider CDIV, I assume the Pi 4 is similar) and 6..9 Mbit/s data rate which you won't achieve if you can only read 2-3 bytes at a time. The overhead of IO library and drivers will limit you to tens of thousands SPI transfers per second.

If you find an ADC that can be configured to buffer samples and them stream them over SPI in large chunks, it may just work with a direct SPI connection. However, ADCs which require you to read out the last sample before they can produce a new one will require external buffering.

Look at FT42XX products: those are USB to SPI/Quad SPI bridges supporting up to 30 Mbit/s clock rates. FTDI offers drivers for ARMv7 and ARMv8 as a part of their libft4222 package, so there's a good chance those bridges will work with a Pi.

Digikey sells FT4222H modules for $18 a piece.

Improve this answer
3

To answer your topic question.

The SPI peripheral can work at those speeds. I2C can not. I do not know about I2S.

However I have not heard of any software which allows continuous SPI readings at those (or any other) rates. I doubt it is possible without periodic interruptions.

As you suggest bit banging via software is out of the question. I doubt it would work in assembler in bare metal let alone under Linux.

Improve this answer
3
  • 2
    It is a challenge, and active area of research, my experience shows that the OS has enormous jitter, even in dual kernel configurations like Xenomai. One option is to run a heterogenous system and use several cores as bare metal cores, basically an arduino zero inside the rpi. At that point you are basically hacking in an ASIC and the BCM SoC is by far not the best for this. Hence my original comment that this is done with dedicated IC's or dedicate cores with very tight code. There are heterogenous core micros with Heavy 32 bit cores and lighter 8 bit cores on one IC.
    – crasic
    Commented May 2, 2020 at 16:39
  • 1
    @crasic if you want to say that 6.144 Mbit/s is not feasible over the Pi's GPIO header, that would make an excellent and highly relevant answer.
    – Phil Frost
    Commented May 2, 2020 at 23:30
  • 1
    @PhilFrost There is a big difference between 6.144 MHz clock speed (which is possible on a Pi) and 6.144 Mbit/s data rate which you are unlikely to achieve if you read 2-3 bytes at a time.
    – Dmitry Grigoryev
    Commented May 3, 2020 at 1:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.