Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 16, 2017, at 1:55 PM, Rathin Dholakia  wrote:
> 
> 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 :)
That will be great. 
> 
> I cant thank you enough, John! 
You are most welcome

Regards,
John
> 
> 
> On Mon, Apr 17, 2017 at 1:53 AM, John Syne  > wrote:
> 
>> On Apr 16, 2017, at 6:20 AM, Rathin Dholakia > > wrote:
>> 
>> 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
>> 
>> On Sunday, April 16, 2017 at 2:40:48 AM UTC+5:30, john3909 wrote:
>> 
>>> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia > 
>>> wrote:
>>> 
>>> 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. 
>>> 2. 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.  
>>> 3. 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. 
>>> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI 
>>>  
>>> 
>>> 
>> Regards,
>> John
>>> 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[Rathin Dholakia]

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 :)

I cant thank you enough, John!


On Mon, Apr 17, 2017 at 1:53 AM, John Syne  wrote:

>
> On Apr 16, 2017, at 6:20 AM, Rathin Dholakia 
> wrote:
>
> 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
>
>
> On Sunday, April 16, 2017 at 2:40:48 AM UTC+5:30, john3909 wrote:
>>
>>
>> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia 
>> wrote:
>>
>> 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.
>>
>> 2. 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.
>>
>> 3. 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_Exam
>> ple_Code#PRU_edmaConfig
>>
>> This example is a good one to show you how to monitor the EDMA transfer
>> completion with the PRU.
>>
>> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI
>>
>>
>> Regards,
>> John
>>
>>
>> On Sat, Apr 15, 2017 at 8:13 PM, John Syne  wrote:
>>
>>>
>>> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia 
>>> wrote:
>>>
>>> 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.
>>>
>>>
>>> 2. My ADC chip (AD7864) has an inbuilt ring output ring register with
>>> 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 16, 2017, at 6:20 AM, Rathin Dholakia  wrote:
> 
> 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
> 
> On Sunday, April 16, 2017 at 2:40:48 AM UTC+5:30, john3909 wrote:
> 
>> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia > > wrote:
>> 
>> 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. 
>> 2. 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.  
>> 3. 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. 
>> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI 
>>  
>> 
>> 
> Regards,
> John
>> 
>> On Sat, Apr 15, 2017 at 8:13 PM, John Syne  
>> wrote:
>> 
>>> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia >> > wrote:
>>> 
>>> 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.  
>>> 
>>> 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?
>> 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 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[Rathin Dholakia]

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 

On Sunday, April 16, 2017 at 2:40:48 AM UTC+5:30, john3909 wrote:
>
>
> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia  > wrote:
>
> 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. 
>
> 2. 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.  
>
> 3. 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. 
>
> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI 
>
>
> Regards,
> John
>
>
> On Sat, Apr 15, 2017 at 8:13 PM, John Syne  > wrote:
>
>>
>> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia > > wrote:
>>
>> 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.  
>>
>>
>> 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?
>>
>> 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. 
>>
>>
>> 3. 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. 
>>
>>
>> 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! 
>>
>> 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%.
>>
>> 3. second interrupt watching 1PPS from GPS, which would reset the Timer 
>> 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 15, 2017, at 1:06 PM, Rathin Dholakia  wrote:
> 
> 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. 
> 2. 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.  
> 3. 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. 
> 2. https://groups.google.com/forum/#!topic/beagleboard/UPbU2WoVzVI 
>  
> 
> 
Regards,
John
> 
> On Sat, Apr 15, 2017 at 8:13 PM, John Syne  > wrote:
> 
>> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia > > wrote:
>> 
>> 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.  
>> 
>> 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?
> 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. 
>> 
>> 3. 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. 
>> 
>> 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! 
> 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%.
>> 3. 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.
>> 4. Use pipe for passing each buffer to DFT.
>> 5. Use the timing 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[Rathin Dholakia]

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



On Sat, Apr 15, 2017 at 8:13 PM, John Syne  wrote:

>
> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia 
> wrote:
>
> 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.
>
>
> 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?
>
> 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.
>
>
> 3. 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.
>
>
> 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!
>
> 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%.
>
> 3. 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.
>
> 4. Use pipe for passing each buffer to DFT.
> 5. 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
>
>
>
>
> On Sat, Apr 15, 2017 at 4:38 AM, John Syne  wrote:
>
>> 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
>>
>>
>>
>>
>> On Apr 14, 2017, at 12:46 PM, Rathin Dholakia 
>> wrote:
>>
>> 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 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

> On Apr 15, 2017, at 6:49 AM, Rathin Dholakia  wrote:
> 
> 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.  
> 
> 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?
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. 
> 
> 3. 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. 
> 
> 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! 
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%.
> 3. 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.
> 4. Use pipe for passing each buffer to DFT.
> 5. 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
> 
>
> 
> On Sat, Apr 15, 2017 at 4:38 AM, John Syne  > wrote:
> 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
> 
> 
> 
> 
>> On Apr 14, 2017, at 12:46 PM, Rathin Dholakia > > wrote:
>> 
>> 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
>> 
>> On Friday, April 14, 2017, TJF > > wrote:
>> Hi Rathin!
>> 
>> Am Freitag, 14. April 2017 16:58:58 UTC+2 schrieb Rathin Dholakia:
>> 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.
>> 
>> Your target isn't very clear. Do you mean 100 k overall sampling rate (2 x 
>> 25 k)? In this case you could use the internal ADC (up to 4 x 50 k sampling 
>> rate, 0-1V8). Otherwise you'll need the external.
>> 
>> 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[Rathin Dholakia]

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



On Sat, Apr 15, 2017 at 4:38 AM, John Syne  wrote:

> 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
>
>
>
>
> On Apr 14, 2017, at 12:46 PM, Rathin Dholakia 
> wrote:
>
> 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
>
> On Friday, April 14, 2017, TJF  wrote:
>
>> Hi Rathin!
>>
>> Am Freitag, 14. April 2017 16:58:58 UTC+2 schrieb Rathin Dholakia:
>>>
>>> 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.
>>>
>>
>> Your target isn't very clear. Do you mean 100 k overall sampling rate (2
>> x 25 k)? In this case you could use the internal ADC (up to 4 x 50 k
>> sampling rate, 0-1V8). Otherwise you'll need the external.
>>
>> Anyway, it should be possible when you fetch the samples by one PRU, and
>> use the other for DFT. Slow tasks can run on the ARM under Linux.
>>
>> Regards
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.
>> com/d/topic/beagleboard/ZufgBytqkOI/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscribe@ goo
>> glegroups.com .
>> To view this discussion on the web visit https://groups.google.
>> com/d/msgid/beagleboard/7f5699a8-b6ab-4e96-8fa2-
>> 18cc8343755e%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Rathin A. Dholakia
> "Dont GO through life, GROW through life"
>
>
> --
> 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 beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.
> com/d/msgid/beagleboard/CAJW6HtQV0Q0hEP9hy8%2BO%3DACnNU1pvjZOrLnt_xyoH-
> SDXLMNMQ%40mail.gmail.com
> 

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[John Syne]

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




> On Apr 14, 2017, at 12:46 PM, Rathin Dholakia  
> wrote:
> 
> 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
> 
> On Friday, April 14, 2017, TJF  > wrote:
> Hi Rathin!
> 
> Am Freitag, 14. April 2017 16:58:58 UTC+2 schrieb Rathin Dholakia:
> 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.
> 
> Your target isn't very clear. Do you mean 100 k overall sampling rate (2 x 25 
> k)? In this case you could use the internal ADC (up to 4 x 50 k sampling 
> rate, 0-1V8). Otherwise you'll need the external.
> 
> Anyway, it should be possible when you fetch the samples by one PRU, and use 
> the other for DFT. Slow tasks can run on the ARM under Linux.
> 
> Regards
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/beagleboard/ZufgBytqkOI/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to  
> <>beagleboard+unsubscribe@ 
> googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/7f5699a8-b6ab-4e96-8fa2-18cc8343755e%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .
> 
> 
> -- 
> Rathin A. Dholakia
> "Dont GO through life, GROW through life"
> 
> 
> -- 
> 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 beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAJW6HtQV0Q0hEP9hy8%2BO%3DACnNU1pvjZOrLnt_xyoH-SDXLMNMQ%40mail.gmail.com
>  
> .
> 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3879F2CA-33BA-444A-A055-A8C9290C6E3C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Feasibility of BBB for ADC and GPS interfacing

[Rathin Dholakia]

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

On Friday, April 14, 2017, TJF  wrote:

> Hi Rathin!
>
> Am Freitag, 14. April 2017 16:58:58 UTC+2 schrieb Rathin Dholakia:
>>
>> 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.
>>
>
> Your target isn't very clear. Do you mean 100 k overall sampling rate (2 x
> 25 k)? In this case you could use the internal ADC (up to 4 x 50 k sampling
> rate, 0-1V8). Otherwise you'll need the external.
>
> Anyway, it should be possible when you fetch the samples by one PRU, and
> use the other for DFT. Slow tasks can run on the ARM under Linux.
>
> Regards
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/ZufgBytqkOI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com
> 
> .
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/7f5699a8-b6ab-4e96-8fa2-18cc8343755e%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Rathin A. Dholakia
"Dont GO through life, GROW through life"

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAJW6HtQV0Q0hEP9hy8%2BO%3DACnNU1pvjZOrLnt_xyoH-SDXLMNMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Feasibility of BBB for ADC and GPS interfacing

[Rathin Dholakia]

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

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/60389908-cb53-44df-9fef-d58ad05cbfe3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.