[Jason Holt] wrote in to tell about of the release of his PRUDAQ project. It’s a dual-channel 10-bit ADC cape that ties into the BeagleBone’s Programmable Realtime Units (PRUs) to shuttle through up to as much as 20 megasamples per second for each channel. That’s a lot of bandwidth!
The trick is reading the ADC out with the PRUs, which are essentially a little bit of programmable logic that’s built on to the board. With a bit of PRU code, the data can be shuttled out of the ADC and into the BeagleBone’s memory about as fast as you could wish. Indeed, it’s too fast for the demo code that [Jason] wrote, which can’t even access the RAM that fast. Instead, you’ll want to use custom kernel drivers from the BeagleLogic project (that we’ve covered here before).
But even then, if you don’t want to process the data onboard, you’ve got to get it out somehow. 100 mbit Ethernet gets you 11.2 megabytes per second, and a cherry-picked flash drive can save something like 14-18 megabytes per second. But the two 10-bit ADCs, running full-bore at 20 megasamples per second each, produces something like 50-80 megabytes per second. Point is, PRUDAQ is producing a ton of data.
So what is this cape useful for? It’s limited to the two-volt input range of the ADCs — you’ll need to precondition signals for use as a general-purpose oscilloscope. You can also multiplex the ADCs, allowing for eight inputs, but of course not at exactly the same time. But two channels at high bandwidth would make a great backend for a custom SDR setup, for instance. Getting this much ADC bandwidth into a single-board computer is an awesome trick that used to cost thousands of dollars.
We asked [Jason] why he built it, and he said he can’t tell us. It’s a Google Research project, so let the wild conjecture-fest begin!
I would say that the PRU’s are a bit more than a “little bit of logic”. They are two independent RISC processors that run at 200 Mhz. I would call the PRU units the flagship feature of the BBB. You get an ARM running at 1 Ghz and a pair of independent processors each running at 200 Mhz, … pretty cool in my book.
They ought to be the flagship feature of the BBB but I haven’t seen that many ppl using them. There even are quite a few projects that use an external Arduino or something for timing critical stuff…
It’s really strange. It’s not that they are horribly complicated to use…. *shrug*
In the beginning it was difficult to the PRUs. The documentation was rather sparse, the only way to program them was to learn PRU assembler. I’ve done it, it wasn’t tremendously difficult, but the learning curve was rather steep. Today there is much more knowledge floating around the internet, there is a C compiler, and if you look at the traffic on beagleboard mailing list, PRU topics pop up almost every day. This does not mean it’s a no-brainer and still can be intimidating for some people.
Arduinos will always be used instead of PRUs by people who do not want to, or are too afraid to learn something new. And there is nothing wrong with it. If people want to stick to what they’ve already learned – it’s their problem. Usually those are weekend hobbyists for whom Atmels are the best RT technology they know. It worked with RPi, there is no reason why it should not work with BB. However the embedded hard RT processors are what makes Beaglebone so special. Without them it would be just another ARM board.
Ah, it totally wasn’t my intention to belittle people using arduinos/AVRs for stuff in connection with a BBB! “Whatever floats your boat and matches your skillset is completely up to you and not for anyone to judge” is my way of thinking regarding hacking in ones free time! (I see lots of bashing and destructive criticism here, and I hate it…)
But I remember a few projects by seemingliy adept people cursing the GPIO latency of the BBB and using some microcontroller for timing-critical stuff. (There even was a benchmark for GPIO Latency, where the BBB would have blown the competitors out of the water, but completely missed the point by omitting PRU usage…)
When I looked at the BBB first, the PRU stuff was already quite well documented. I wasn’t quite aware of all the hassle in the beginning.
The criticism is targeted not at those who do not know how to use PRUs, but at those who treat *duinos as a solution for all the world’s problems. Now we have RPi worshippers who even a suggestion that their beloved board is not a good fit for their problem take as a great personal offence. I noticed that there is a huge overlap between these two groups.
Latencies in communication with GPIOs on BB occur on the bus connecting all the internal components. What is important for RT applications, the latency is not constant and may change at random moments depending on the traffic on the bus. It’s not a problem with the processor; The same happens when PRU talks to a GPIO through the interconnect. This is why some GPIO pins are wired directly to the PRU registers. This connection bypasses all the internal components, the timings are 100% predictable and depend only on the program running on the processor.
Hrrrmmm, with decent USB 3.0 sticks in 2.0 fallback mode, you should be able to nearly max the USB 2.0 bandwidth as long as you don’t have a lot else on the root hub. So theoryyy-eticaly you can suck one channel dry at max sample rate.
Then also, maybe getting data out via HDMI might be plausible…
1920x1080x colour depth. The HDMI 1.3 specification defines bit depths of 30 bits, 36 bits and 48 bits. So that would be 59.33MiB/sec, 71.19MiB/sec and 94.92MiB/sec. So yea interesting lateral thinking on a unique data transfer technique. So even if you could only update one screen full every second it could be useful.
Sorry I’m wrong, I forgot to divide by 8 so it would be: 7.42MiB/sec, 8.9MiB/sec and 11.87MiB/sec. So you would need a minimum of 7 frames a second to transfer 10bits dual channel 20MSPS.
1920×1080 is 2 million pixels per frame. At 8 bits per channel and three channels, that’s 6 million bytes a second. At 24 frames a second (or 23.976), that’s about 142 MB/second. Plenty fast enough, even with padding to make parsing captured data easier.
Doing the math: 10 bit DACs doing 20 MSPS = 200Mb/s = 25MB/s..
Modern storage systems do a lot more than that. A single hard drive will easily sustain 3x-4x the data rate you’re describing and good SSDs are 10x-20x those data rates. Not necessarily stuff you see on most micro-controllers,. but easy for a relatively low end ARM to sustain.
My intent is not to denigrate the power of the PRUs, but to say that storing that data isn’t really a problem for modern systems.
“Modern storage systems do a lot more than that.”
Over what interface? SATA. Which none(?) of the single-board computers have at their disposal. So you’re stuck with USB or networking, and you’re back to square one.
Allwinner A20 chips had SATA on the SoC, though with writes oddly limited to 40MB/s and all but one of the boards using it having less than 2GB of RAM how useful that is I don’t know. Running up against this problem myself for NAS-y reasons, but USB 3.0 to eSATA adapters are a thing and capable of 35MB/s so that’s an option up to a point. After that you’re looking at odroid with their emmc modules.
Gah, 35MB/s on USB 2.0, idk about 3.0, that’s kinda rare on SBCs. Odroid XU-4s are the best bet there, though they’re nudging $100 with shipping to my country so they’re not in the same league as the $30-50 offerings.
GNU radio?
To be honest the first thing I thought is that this is plagiarism of my main ideas presented in my doctoral dissertation on the need for pre-processing of fast (mega sample) ADC on SoC platforms for future IoT systems, but this is much less then that. All that we can see is just is another rapid in-memory pass-through storage solution for ADC reading, and to/for what SoC (BeagleBone ARM CX8) is not required.
Try a little more so that you make the most of the CPU processing of this data in the fly, rather than just dump them in memory until you fill it, and process never.
That would be cool, to catch them up to 1991s state of the art in PC video capture systems, since ISA bus was kinda limited. Had this big ole card with a flash ADC, high bandwidth and a DSP and CPU and RAM onboard…. never had the sucker working though, drivers were impossible to find.
TBH at first I thought this was would be a comment pointing out how modern hobby level electronics can at least provide some of the functionality of high end science equipment. Followed by an analysis and comparison to cutting edge researchh, with some emeaningful and helpful advice from the “experts” in how to improve the syste, without looking down on the hard work of others.
But this is much less than that.
Try a little harder to be constructive.
Like.. with a link to your dissertation so the original author can review, learn, implement your concept and cite you prominently.
Right, but unfortunately has only single core 1-GHz Sitara™ ARM® Cortex®-A8 32-Bit RISC Processor but as we know it support some NEON SIMD and Ti integrated some FPU/DSP in it right?
Now try to use it in your advantage and process some of that data.
But do not expect to much of it really, I limited my research to 1.5-2MSPS with 15MB/s of real-time ADC data stream (initial 40byte of transaction info prove to much for Pi3 USB2.0 storage so I cut amount of descriptive data that follow ) much and that was challenging much stronger players than BB, like Raspberry Pi2/3 and Odroid XU4.
On Pi3 you can at least compress in real-time some of that data :)
To be quite honest, family, at first I thought this would be a comment containing wittier snark and demonstrating how modern hobby level auto-correcting spell checkers can at least provide some of the functionality of a proper education, followed by an observance of correct punctuation, with some encouragement of moral and grammatical vigilance and an appeal to the comments section to vocally demand an improvement of this site, all while viciously looking down on the fresh dank memes of others.
But this is much less than that.
I’d like to “like” that.
The silly thing is he was an “English Teacher” (aka human tape recorder) for 8 years or something.. You would have thought his English would be spot on after milking a humanities visa for so long.
“English teacher” / a.k.a. / triple period ellipsis. Thank you.
Hi deril, you get it wrong 10bit ADC will be written as 2 bytes (16bit but 4 of them empty/zero) then you need to add some info about real/relative time of acquisition and you end up with no less then 4-5 bytes per single ADC read.
Now comes the best part 4 bytes * 20M acquisitions/s = 80MB/s of pure real-time data stream that MUST NOT be interrupted and has to be inserted in RAM (easy solution) or on the storage/disk systems.
Now no uSD or even eMMC card will provide you insert/write bandwidth that need to be 1.5-2x times greater to be sure that no data is lose in transfer.
Not to mention system data bus throughput , memory etc. That 80MB/s in real time will be big problem even for smaller SATA Raid disk configurations on servers.
Could just use it like a Digital Storage Scope. Send a start capture and the scope overwrites until manually stopped or a condition is met.
20 MS/sec is far from”blindingly fast,” especially for a 10-bit ADC. For that bit depth, a “blindingly fast” ADC would be 500 MS/sec, but of course that would cost thousands of dollars. So this cape is a nice, fast, and (presumably) cheap ADC. That’s very good. Just not worthy of the hype.
More like 200USD for the 12bit IC. For 8-bit less than 100.
What hype?