PRU SPI ADC communication

[davidvaran...@gmail.com]

Hi,

I adapted the code from  Derek Molloy example - http://exploringbeaglebone.com/chapter13/ - https://github.com/derekmolloy/exploringBB/tree/master/chp13/adc - to read this adc - ad4000 - http://www.analog.com/media/en/technical-documentation/data-sheets/AD4000.pdf with a 500kHz sampling.

The only thing i changed, according to communicate with this adc, is that i read 16 bits on the PRUADC.p and TIME_CLOCK is 1 (12.5Mhz for SPIclock). I'm not an assembly expert, so i really can't figure out the problem.

I tried read the this adc from the SPI0 of BBB(using Derek Molloy exampels too http://exploringbeaglebone.com/chapter18/) , of course not with a 500kHz sampling, just for test, but the problem is the same, i'm working on this for more than 4 weeks, and i can't solve the problem, and is not a hardware problem.

In this examples, i have in the analog input of the adc, a square wave(3.3 V), and 3 constantes voltages(680mV,1.8V,3.3V), all examples done on PRU, and this are the results:

- Y axis -> Volts

- X axis -> Number of sample

- Vref of the adc is 4V.

Any help would be aprecciated.

Best Regards,

David

[Graham]

Hi David:

I think it is a hardware problem.

It looks like you are not doing a good job referencing your ground input for the ADC, or you have a very dirty Voltage reference for the ADC.

Either way, it is picking up some serious offset from a switching power supply (The PMMIC ???) somehow.

I think you need to do an audit of the power going to the Voltage reference for the ADC, and the connection of the positive and negative Voltage references, and the negative input on the ADC.

--- Graham

==

[Graham Haddock]

Hi David: I am glad to hear that you got it fixed. I am posting your reply back to the Beaglebone reflector, so others can benefit from the discussion. If you are talking about RAM in the PRU, perhaps some PRU expert can answer your question. (I am not a PRU expert.) If you are talking about RAM in the main Sitara memory space, use the Linux command "free".  You can Google that. In order to write to a uSD card, I am sure that you will need to have a small application that will take the data from the PRU and move it to the uSD card. --- Graham == David Caniceiro
to me

Hi Graham,

Thanks for your answer, i solved the problem minutes after, and it was a hardware problem in the reference.

I dont know if u can answer me, but i have another two question. What is the max RAM i can allocate to the samples from PRU, and if is possible to write directly to an uSDcard working as external memory from the PRU. If not, i can do the a discuss about this.

Best Regards,

David

--
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/i13Z9oe3EzM/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/b94014a1-7158-4dee-a304-edab41c21e4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

> I dont know if u can answer me, but i have another two question. What is the max RAM i can allocate to the samples from PRU, and if is possible to write directly to an uSDcard working as external
> memory from the PRU. If not, i can do the a discuss about this.

Theoretically, you should be able to access and use all of the ARM's system memory. Realistically, I'd say you could probably use up to around 300M-400M of the main processors memory. The system needs around ~100M for processes, and buffering. With all that said, your bottleneck is going to be the medium you choose to store your samples to. I would avoid the emmc, as repeated writting / erasing to the emmc would make "short work" of the emmc. e.g. You'd probably kill the emmc pretty fast. An sdcard will probably die much quicker.

So the way I see it is that you have two viable options. Some sort of networked storage, or use an external USB hard drive. Of these two when I tested this, USB was the fastest option at around 20 Megabytes/second throughput. The onboard Ethernet is really fast for ethernet at around  ~11 Megabytes / second with the correct tweaks.

Maybe what you really need is a fast C application that grabs the data from the PRU's memory directly, in real-time, and shuttle that data out just as fast as you need to. Just off the top of my head, 500ksps will probably be between 6-7 Megabytes a second, in plain text format. If you dream up some sort of data packing format, perhaps a good bit less.