Comment by tyingq | Hacker News Reader

Comment by tyingq | Hacker News Reader

Was initially confused, because there was an earlier "BeagleBone Blue" (well, BlueSteel, I guess) that had nothing to do with robotics:

http://www.cnx-software.com/2014/06/18/bluesteel-basic-beagl...

The interesting part of this one, to me, is the Octavo packaging of the AM335X processor with on-die RAM. That makes the board much simpler. Though, I thought it would make a bigger difference in price. The BeagleBone wireless that uses the same chip is ~$68, which is $7 higher than the Black that has separate RAM.

If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs. It's like having the best of a normal linux board plus a microcontroller on the same board. Since the PRU shares memory with the main CPU, you can offload things that need to be realtime. That allows for things like a near professional-level LED matrix controller (https://trmm.net/LEDscape) or even a DIY video controller (https://trmm.net/Mac-SE_video).

The project that I am a part of uses the PRUs to implement an ultra-low latency audio platform: http://bela.io

It's open source, here's the PRU code: https://github.com/BelaPlatform/Bela/blob/master/pru_rtaudio...

This paper describes the platform in more detail: http://www.eecs.qmul.ac.uk/~andrewm/mcpherson_aes2015.pdf

This paper compares latency achievements using this strategy compared to Raspberry Pi, Arduino, Max/MSP, etc: https://qmro.qmul.ac.uk/xmlui/bitstream/handle/123456789/124...

Thanks! This looks a really good starting point for a project I am working on. Using PRU for I2S is genius :) Can you please point me to the detailed specifications somewhere on http://bela.io?

Cool! What are you working on? What kind of specification are you looking for? Feel free to get in touch info@bela.io or forum.bela.io

What's the advantage of this over the Bone's built-in I2S/McASP stuff?

Hi, there's a post about this on our forum: https://forum.bela.io/d/20-pru-vs-mcasp

Here's an excerpt:

"Bela uses both the McASP and the PRU. The McASP actually streams the data to the codec, but the PRU handles passing data to and from it, as a sort of sophisticated DMA controller. We use the PRU here because it can also do SPI transactions with the other ADC and DAC and it can sample the GPIOs, all aligned on a sample-by-sample basis with the audio clock. The PRU then puts the results in a memory buffer for the CPU to work with.

To take any advantage of that, you need a Xenomai kernel, because this lets you write audio code that can interrupt the entire rest of the OS. If you don't have this, then you're stuck with the timing uncertainty that regular Linux provides, meaning you need larger buffer sizes (= longer latency). It also means that audio performance may depend on system load, which is not true of Xenomai (rather the reverse: rest-of-system performance depends on audio load)."

Interesting. Never heard of Xenomai before.

Can any of this feed into the TSN(Time sensitive networking)/AVB(audio video bridging) standards?

I haven't found anything useful in that space.

> If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs.

Allwinner SoCs have an OpenRISC microcontroller used for managing deep sleep modes. [0]

I don't think anyone has figured out how to use it for other tasks yet, but it would be really great if there were more SoCs that included these kind of companion cores.

[0] http://linux-sunxi.org/AR100

Oh, wow...companion core in a cheap board would be popular if someone figures out how to leverage it. The OrangePI Allwinner boards are amazingly inexpensive...$10 shipped, including WiFi (https://www.aliexpress.com/store/product/New-Orange-Pi-Zero-...)

Related, the lowRisc RISC-V project has a concept of minion cores: http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-...

The iMX7 is a low power single or dual A7 core with an extra Cortex-M4 core on the die for real-time applications. Looks like they also took out some of the multimedia blocks to try and get the price down compared to the iMX6.

http://www.nxp.com/products/microcontrollers-and-processors/...

NXP also nuked a lot of their free support from orbit when they bought Freescale. Doing stuff like deleting a bunch of the SD card images for their sabre boards. We were told by NXP that some Indian support firm still had them for like... a $20k support contract.

They really pissed us off with that crap, and our shop at least probably won't be buying NXP parts for a while.

Why couldn't you rebuild the SD image from Yocto?

> Why couldn't you rebuild the SD image from Yocto?

Because the vendor should provide an SDK for development?

It's fine if the vendor's image is based on Yocto, but you should still be able to download something from them with instructions.

Because the vendor should provide an SDK for development?

That's literally what Yocto builds for you.

you should still be able to download something from them with instructions.

As an example, here's Freescale/NXP's github with their Yocto recipes. It was not "nuked from orbit" on the purchase.

https://github.com/Freescale/fsl-community-bsp-platform

And a sample build guide:

http://www.nxp.com/assets/documents/data/en/release-notes/IM...

> If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs.

This is something I plan to do once I get one of these beasts, although they're probably beyond my level of comprehension. Anyway, if they can be used to synthesize signals at very high speed, what about using them to build a DVB-T transmitter? When TV went digital we lost the ability to send a signal to a TV using an extremely cheap modulator, and last time I checked the only units around are priced several hundred quids, so if doable an application like that one could be truly interesting.

> Anyway, if they can be used to synthesize signals at very high speed, what about using them to build a DVB-T transmitter?

Not possible, unfortunately.

IIRC The PRUs run at 200MHz. I'm not an expert at signal magic, but unless somebody has a really smart trick up their sleeve, it means you can synthesize at most a 100MHz signal (assuming changing the state of an output takes only one cycle, which I believe it does).

Ah sorry, I didn't mean producing the radio frequency signal but the modulating one which would be paired with a carrier generated by a separate module. Admittedly I know next to nothing about digital modes so I have no idea if the PRU could stand the necessary bandwidth to do such a thing.

> If you haven't used a BB product, check out the thing that I think is the biggest upside of these...the built in pair of PRUs.

I've been looking at boards for days now trying to find the perfect one to suit my needs and this is exactly what I've been looking for. I've seen the beagleboard before but I never noticed this feature before. I'm glad I saw this post this morning!

The blog says that it was announced just on the 13th.

That board was announced on the 13th, but other BeagleBone boards have had this feature (the 2 PRUs) for a while.

Yeah, definitely. I assumed they'd been talking about some feature on the new board, although looking back in the thread, I can see how that might've been an unsound assumption.

I've actually got a Beaglebone Black sitting on the desk next to me. I haven't gotten around to playing with the PRUs, but I know of their existence and general capabilities.

Well, sort of: http://hackaday.com/2016/01/11/introducing-the-beaglebone-bl... It's been kicking around for more than a year...

Reply on news.ycombinator.com