• State Answer Suggested
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 2160 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Strategy for interfacing with a fast SPI AD-Converter

Martin Wiingaard
Prodigy 190 points

Hey There,

I'm running on the BeagleBone Black, with the default Debian Image. I'm about to interface a fast ADC (2 x 24bit @ 65536 Hz) to the AM335x, and I'm wondering what would be the best solution. The ADC has a DRDY (Data Ready) signal which is indicating when the when a convertion is done and the sample is ready to be read. DRDY is toggling at 65536 Hz. The converter is connected to an external precise clock, which is enabling the desired samplerate. The converter is communicating to the processor via SPI. So when data is ready (DRDY goes low), the processor should generate the SCLK to the converter, and read the sample like a regular SPI-connection.

It is crucial that the processor is picking up every sample. Im consireding two (maybe) possible solutions:

1: Using the McSPI-module. But I'm not sure if I can make the DRDY trigger the SPI-transfer with little enough latency, to transfer the sample, before the next sample has to be transfered (~11 micro sec)

2: Using the PRU. I could read the SPI sample with the right timing to the DRDY signal, simply by bit-banging all the signals, and then transfer the samples to some buffer on the host system.

I'm not sure which solution I would have the most chances with? Maybe it is possible to mix the two solutions somehow?

I hope that I've made myself clear. I'm looking for some kind to best practice of implementing a fast SPI-connection with strict timing requirements to the AM335x.

EDIT: Figure below inserted to clarify timing requirements

 

  • 0
    Intellectual 440 points
    "It is crucial that the processor is picking up every sample." -> so, I would say: none of both solutions.
    As far as I know, there is no hw connection in the McSPI module to "start a transfer" in master mode driven by an external pin.
    Does you ADC supports SPI master mode?
    Generally speaking, I "will" never (never!) recommend to connect a critical function (chip) as a slave: if a function is critical, then it has to be the master of the communication or the only communication of your CPU (which is not the case)
    Oh yeah, it will "work" if your chip is in slave mode, but you cannot certify that you will never lose a sample (never, even if it is the highest task): from my experience, this inverted logic was specified by a stupid "sw architect" for multimedia flow ( (sound/image synchronization), you cannot imagine how many hours (and guys and money) has been spent to try to fix issues, and never solved, (only workarounds...) !
    If you cannot put your ADC in master mode, then try considering adding "buffers" between adc and cpu.
    Again, this is because you said "crucial" ^^

    Regards.
  • 0
    Genius 3685 points
    Wire your DRDY line to an external event input or to a GPIO0 or GPIO1 input. Start a DMA transfer from this event. Let the DMA transfer the data from the SPI to the memory.
  • 0 in reply to Wolfgang Muees1
    Prodigy 190 points
    But starting a DMA transfer wouldn't start the SPI transfer, so the sample data will never be shifted into the SPI. Or what? I'm not sure i understand?
  • 0 in reply to Martin Wiingaard
    Genius 3685 points
    If you use the DMA to write a word into the SPI transmit register, what will the SPI do? Use a second DMA channel to receive the words from the SPI receive register. Maybe use the receive FIFO.
  • 0 in reply to Wolfgang Muees1
    Prodigy 190 points
    Okay, so when the SPI transmit register is filled up by the DMA, it will start the SPI-transfer and thereby receive the sample from the ADC. But is the delay-time from the external event input or GPIO to the SPI-transfer begins, guarantied to be lower than the max allowable delay (~11 micro sec.)?
  • 0 in reply to Martin Wiingaard
    Genius 3685 points
    11us is a very long time. DMA and Event processing is done in hardware, not software. You should have a good safety margin. Simply try it out on your beagle board.
  • 0 in reply to aaj
    Prodigy 190 points
    Yeah, I see, it not optimal to let a critical device be slave.
    I've checked the ADC, and its not possible to make it run in master-mode, because it is daisy-chained to another ADC, and have some other requirements.
    You don't think that the PRU-solution could work? Why is that, if I keep to the ADC timing requirements?
  • 0 in reply to Martin Wiingaard
    Intellectual 440 points
    "daisy-chained to another ADC, and have some other requirements. "...
    Without the requirements, it would be difficult to give food advice, so let me just give some tips only...
    I don't know PRU enough; I do not see on TRM page 201 what could solve your problem: I do not see any SPI dedicated interfaces.
    Does your ADC support SPI protocol only? is it possible to have continuous SPI transfers or do you need to activate/deactivate "Chip Select"?
    If it was "my" project, and considering the "crucial" point (to me, it is like "wrong medical diagnostic for a person whose live is in danger"). Considering that the adc cannot be in adc master :
    I would add a small external chip that will do this critical function and only that one. I would connect the adc to that chip with spi bus, this chip function is to create buffers of samples. I would connect this chip to the main CPU via serial or spi (I would prefer UART for hw, timings and sw simplification)
    This chip will be allowed to delete the samples only when the main CPU acknowledges the reception of samples (communication with CRC). This external chip can be a simple atmel (xmega) or ti (msp430) (or whatever chip you trust in) whose cost is about 1$... But this is also a 10minutes study that I would not trust in without deeper analysis.

    Summary: buffer through an external chip that will save every sample and that is allowed to flush buffers only when main CPU fetches samples. KISS principle and FMECA.

    Regards.