Feasibility of BBB for ADC and GPS interfacing

GoogleGroups
1

Dear Community members,

I am willing to interface, 12 bit 4 channel, Simultaneous Sampling High-Speed ADC (Analog AD7864) to BeagleBone Black, and operate it at 100k sampling rate. My present thoughts are to use header P8 Digital I/O pins to control the ADC as well as to read the input data from the ADC (using interrupt(s) - EOC). I will also do a DFT on the received data samples.

I would also like to interface GPS over UART for timing signal and 1 PPS timing reference (but that is my secondary goal, so not worried at the moment).

So, Can you critique about the capability of the board for such a arduous task? Is board capable of doing this? if yes, can you guide what approach can I / should I take?

My existing search has led me to three things

  1. Use Sys/Bios as a real-time OS enable peripherals as DIO and interrupt source. ( right now I am digging dipper into this)
  2. Use a Debian patched with Ti’s RT-kernal ( I am interested in this but I am not sure about it’s interrupt support!)
  3. Xenomai ( No Idea)

Hoping to have some time-tested practical insight (and references) from you all.

Thank you and my sincerest gratitude to all.

References: (For others on the quest)

  1. https://eewiki.net/display/linuxonarm/BeagleBone+Black
  2. http://exploringbeaglebone.com/chapter13/
  3. http://brunosmartins.info/xenomai-on-the-beaglebone-black-in-14-easy-steps/
  4. https://e2e.ti.com/support/embedded/tirtos/f/355/t/312951
2

Hi Rathin!

3

Hello TJF,

Thanks for your suggestion, to clarify my side further, let me elaborate.

My requirement is 256 (samples per Cycle) * 50(cycles, power frequency) * 6 (channels) = 76.8 k SPS

So I need overall 100k(rounded off) 100k sampling.

And my input signal is between ± 10 Volts and I don’t want to scale for resolution purposes. Apart from that I need dedicated ADC for each channels so I’ll prefer separate ADC chip.
Does this make sense? Or I am wrong?

Thanks

4

I recommend that you look for a external ADC with a sample FIFO, then the samples are measured at predefined intervals and you could read them with the ARM processor and use the PRU for your timing requirements. I take it you will need a disciplined oscillator sync’d to the GPS 1pps, which can be done with the PRU. Using an ADC with SPI interface and FIFO means you could use DMA to transfer the samples, freeing up the CPU for more important work.

Regards,
John

5

Dear John,

Thanks for your suggestion. Yes I was thinking in same line but bit differently. I am still a rookie in all this so have few queries in your approach if you can clarify.

  1. Instead of PRU as oscillator, I was planning to use one of the 4 onboard timers. Wont it be better? why didyou suggested PRU instead of Timer? some benefit?

  2. My ADC chip (AD7864) has an inbuilt ring output ring register with circles among the outputs of 4 channels every time I pull down “READ” pin. So, do I still need a FIFO?

  3. Why SPI? wont 12 Digital parallel pin faster? and BBB uses pin addresses then how is DMA different from normal GPIO access?

  4. For utilizing PRU, are you recommending ASM coding or normal C coding using some library? I ham bit reluctant because of the assembly coding involved because I am not that good at it, yet!

Thanks a ton,
Rathin

My approach in brief for people’s feedback:

  1. Use Timer Interrupt using on-board timer periodically for generating SOC
  2. Detect EOC using interrupt from ADC, initiate read cycle (ISR) for all 4 channels
  3. second interrupt watching 1PPS from GPS, which would reset the Timer period (as disciplining sampling)
  4. Use pipe for passing each buffer to DFT.
  5. Use the timing info from UART to time-stamp the DFT output
6

Dear John,

Thanks for your suggestion. Yes I was thinking in same line but bit differently. I am still a rookie in all this so have few queries in your approach if you can clarify.

  1. Instead of PRU as oscillator, I was planning to use one of the 4 onboard timers. Wont it be better? why didyou suggested PRU instead of Timer? some benefit?

It depends on your absolute time accuracy requirements. If you are looking at 100mS accuracy, then by all means use the Timer with interrupts given the interrupt latency of Linux. If you want 1uS accuracy, then you need a disciplined oscillator which drives a 1MHz counter which can be read by the PRU so that you can time tag the ADC samples.

  1. My ADC chip (AD7864) has an inbuilt ring output ring register with circles among the outputs of 4 channels every time I pull down “READ” pin. So, do I still need a FIFO?

DMA has to arbitrate for bus access and isn’t efficient if you are only reading one or just a few samples at a time. You want to read at least 32 samples at a time to make DMA viable; hence you want a FIFO of at least 64 samples with an interrupt that occurs when the FIFO is almost full.

  1. Why SPI? wont 12 Digital parallel pin faster? and BBB uses pin addresses then how is DMA different from normal GPIO access?

Because the SPI driver already supports DMA transfers.

  1. For utilizing PRU, are you recommending ASM coding or normal C coding using some library? I ham bit reluctant because of the assembly coding involved because I am not that good at it, yet!

It doesn’t matter, both will work just fine.

Thanks a ton,
Rathin

My approach in brief for people’s feedback:

  1. Use Timer Interrupt using on-board timer periodically for generating SOC
  2. Detect EOC using interrupt from ADC, initiate read cycle (ISR) for all 4 channels

The processor overhead for 100ksps will mean the CPU will be running at close to 60% just to service the interrupts. Not a good idea. Using DMA, CPU will be less than 3%.

  1. second interrupt watching 1PPS from GPS, which would reset the Timer period (as disciplining sampling)

First, the timer is derived from the CPU PLL which multiplies the CPU crystal oscillator. The frequency error can be 2 to 3%. Add to that the Interrupt Latency of Linux, and your timing error will be bad. Also remember that the timing error is accumulative so you will continue to see time drift. Temperature changes will affect the crystal frequency as well.

  1. Use pipe for passing each buffer to DFT.
  2. Use the timing info from UART to time-stamp the DFT output

Timing needs to be done way before you communicate this info. UART have significant latency as well.

Regards,
John

7

Dear John,

Thanks a lot for such a detailed insight!

Yes I will need a precise time,and I was misinformed about the timer so I was under impression that they are the clock source and hence driving force.

I will need some time to think and digest all but before I proceed let me rephrase what I have understood, so that you can correct me:

  • Use PRU0 as an timer (oscillator) for deriving SOC

  • Use PRU1 for DMA using SPI via FIFO, and also to time tag!?

  • Remaining ARM processor for DFT and other thing

Did I get it correctly?

But then my question are:

  1. I still need to detect EOC and assert READ signals then how will my FIFO or DMA free my processor?

  2. My PRU 1MHz, How can it be disciplined, it will still need an interrupt to detect 1PPS right?

  3. And How can it replace Time data from GPS?

Pardon me if above question sound novice! I have not worked on it before.

Maybe you are suggesting something like this:

  1. http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig
  2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI
8

Dear John,

Thanks a lot for such a detailed insight!

Yes I will need a precise time,and I was misinformed about the timer so I was under impression that they are the clock source and hence driving force.

I will need some time to think and digest all but before I proceed let me rephrase what I have understood, so that you can correct me:

  • Use PRU0 as an timer (oscillator) for deriving SOC

  • Use PRU1 for DMA using SPI via FIFO, and also to time tag!?

Use ARM SPI driver for reading ADC samples via EDMA, but use PRU1 to monitor the EDMA completion and then using the value from the 1MHz counter, time tag the ADC buffer. You don’t have to tag each sample because you know the sampling rate.

  • Remaining ARM processor for DFT and other thing

Did I get it correctly?

But then my question are:

  1. I still need to detect EOC and assert READ signals then how will my FIFO or DMA free my processor?

Not necessary as the FIFO half full will cause an interrupt and initiate the DMA transfer.

  1. My PRU 1MHz, How can it be disciplined, it will still need an interrupt to detect 1PPS right?

The 1pps is used with a PLL (phase lock loop) to tune the 1MHz crystal frequency so that the 1MHz is exactly 1MHz. In the case that the GPS is lost, the Oscillator continues to be accurate for several hours or more.

  1. And How can it replace Time data from GPS?

Same answer as above.

Pardon me if above question sound novice! I have not worked on it before.

Maybe you are suggesting something like this:

  1. http://processors.wiki.ti.com/index.php/PRU_Linux-based_Example_Code#PRU_edmaConfig

This example is a good one to show you how to monitor the EDMA transfer completion with the PRU.

  1. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI

Regards,
John

9

Dear John,

Ok, now I understood. So basically, I have to create a dedicated crystal based oscillator for time reference. I though you were telling to use PRU for that, sorry my bad.

Though I’ll have to figure out some way to convert my parallel digital outputs in to SPI compatible serial signals and also how to control ADC, FIFO and SPI all to gather. but that I will search! and will post here

Once again thanks and will tell you if there is some query.

Apart from that Can you suggest some soultion to convert my parallel ADC output

10

Dear John,

Ok, now I understood. So basically, I have to create a dedicated crystal based oscillator for time reference. I though you were telling to use PRU for that, sorry my bad.

Well, you can use the PRU as part of the PLL. Use the PRU to read the counter when the 1pps signal occurs. If the count is less than 1,000, increase the voltage from the DAC or decrease the DAC voltage if the count is higher than 1,000. The DAC voltage is controlling the VXCO (Voltage Controlled Crystal Oscillator). Typically the VXCO run at several MHz, you you need to divide that down to generate a 1MHz clock. The counter is reset to zero after reading the count.

Though I’ll have to figure out some way to convert my parallel digital outputs in to SPI compatible serial signals and also how to control ADC, FIFO and SPI all to gather. but that I will search! and will post here

Once again thanks and will tell you if there is some query.

Apart from that Can you suggest some soultion to convert my parallel ADC output

Why not use a ADC with a SPI interface? If you really want to use a parallel ADC, then GreenPAK has a nice solution.

http://www.silego.com/products/402/312/AN-1083.html

Regards,
John

11

Yes, I can setup a oscillator circuit, in fact my GPS board provides me 10 MHz oscillator output which is extremely stable, I can use that along with PRU (thanks for the tip).

And yes, completely agree, I am reconsidering my ADC choice, that would ease up my design many folds.

And I am also trying out TI’s 4.4-rt- kernel for reducing my overall latency.

I will document things here once I proceed a little, So others can also use it in future :slight_smile:

I cant thank you enough, John!

12

Yes, I can setup a oscillator circuit, in fact my GPS board provides me 10 MHz oscillator output which is extremely stable, I can use that along with PRU (thanks for the tip).

Just be aware that this 10MHz oscillator probably stops when you loose GPS lock. The purpose of a disciplined oscillator is that it acts like a flywheel and continues to run accurately even when the GPS signal is lost. When the GPS signal returns, the disciplined oscillator makes minor adjustments to sync up with the 1pps. GPS signal lost typically occurs during a bad storm.

And yes, completely agree, I am reconsidering my ADC choice, that would ease up my design many folds.

And I am also trying out TI’s 4.4-rt- kernel for reducing my overall latency.

If the PRU is doing the time tagging, there is no need for rt kernel.

I will document things here once I proceed a little, So others can also use it in future :slight_smile:

That will be great.

I cant thank you enough, John!

You are most welcome

Regards,
John