Sample rate of 2kHz

13 views
Skip to first unread message

assueros...@gmail.com

unread,
Aug 6, 2017, 9:25:29 AM8/6/17
to BeagleBoard
I'm starting in the beaglebone and I've read in several forums that PRU is able to give real-time answers using the libpruio library, but I'm not able to use it, I need a 2kHz sample rate in my AD, transform an analog signal into digital In a sampling of 2kHz, one sample every 250 microseconds. I am using a code that I found created for a beagleone black in a beaglebone white, because the sampling rate is small. where is the problem? I appreciate the advice and opinions that can help me. Thank you.

TJF

unread,
Aug 6, 2017, 12:51:50 PM8/6/17
to BeagleBoard
HI Assuero Savio, your question is confusing!


Am Sonntag, 6. August 2017 15:25:29 UTC+2 schrieb Assuero Savio:
I'm starting in the beaglebone and I've read in several forums that PRU is able to give real-time answers using the libpruio library, but I'm not able to use it, I need a 2kHz sample rate in my AD, transform an analog signal into digital In a sampling of 2kHz, one sample every 250 microseconds. I am using a code that I found created for a beagleone black in a beaglebone white, because the sampling rate is small. where is the problem? I appreciate the advice and opinions that can help me. Thank you.

250 us = 4 kHz and 2 kHz = 500 us

With libpruio you can develop controllers running on ARM up to 10 kHz, if you're happy with ~50 us time shifts (due to linux interrupt handling. If you have stronger real time requirements, you'll have to use a PRUSS for the controller. With libpruio you can start on ARM and switch later to the PRUSS, if required.)

Why aren't you able to use libpruio, what have you done on which kernel, and what's your problem?

Regards

Dennis Lee Bieber

unread,
Aug 6, 2017, 1:03:13 PM8/6/17
to beagl...@googlegroups.com
On Sat, 5 Aug 2017 20:26:33 -0700 (PDT),
assueros...@gmail.com declaimed the
following:
Not sure I understand the question... Other than to comment that the
PRU is not a DSP (if that is what you are trying to achieve). (TI's full
name for them is programmable real-time unit & industrial communication
sub-system). From the TRM:

"""
The PRU is a processor optimized for performing embedded tasks that require
manipulation of packed memory mapped data structures, handling of system
events that have tight real-time constraints and interfacing with systems
external to the SoC. The PRU is both very small and very efficient at
handling such tasks.
"""

{Caveat: I'm attempting to interpret multiple PDF specification sheets and
manuals -- so there may be some errors in my thoughts here}

Note that the ADCs are on the other side of the L3/L4 interconnect --
which may mean access can be hindered by what is running on the ARM
processor. The ADC max rate is 200K/sec -- if the clocks and configuration
are optimal (otherwise the clock has to run through a divider which will
reduce the max rate available)...

200K/sec => 2K/msec

... seems like it should be doable. You ask for 2K/sec, or 2/msec... But
then you ask for a sample every 0.25msec (250usec), which means you are
asking for 4 samples per msec, not 2! Perhaps some error in specifying the
ADC configuration?
--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

Reply all
Reply to author
Forward
0 new messages