Comparing BeagleBone Black & Raspberry Pi

A bit more documentation-friendly:

Shabaz wrote:

and as we know it can run to a highly impressive 200MHz on some of the pins.

If you are talking about PRU I/O (I've seen you make this claim before) then the best you can do is output a 100 MHz square wave (inline code taking two instructions, 5 ns to output 1, 5 ns to output 0, 10 ns cycle time)

for a limited time (up to ~102 uS) depending on how much code space you want to use doing it and it can maintain this only as long as it is the only thing the PRU is doing during this output and you don't care about it

affecting any other I/O pins. Congratulations you have just turned a 200 MHz PRU into a non-continuous 100 MHz oscillator. With all these limitations I don't see this as being particularly useful. Any useful I/O will probably

be limited to 50 MHz or less by  the time the simplest logic is applied to use some input to decide what value to output and again it can maintain this only if it is the only thing you are doing with the PRU and you don't care

about affecting other I/O pins. At this point you have turned a 200 MHz PRU into a logic gate or maybe all the way up to a comparator.

Despite previous assertions by others in other E14 forums that the BeagleBoard Black has faster memory, the Raspberry Pi has twice the memory bandwidth available, 3.2 GB/s max vs. 1.6 GB/s max. To put this in some

perspective displaying video at 1920 x 1080p60 takes about 31% of the BeagleBoard Black's memory bandwidth just to keep the screen refreshed. For some reason this clear design limitation does not get much attention

as I seem to be the only one to bring it up (twice now) so far.

I still see the BeagleBoard Black as clearly being more useful for most embedded applications (depending on video and I/O needs) and engineering students. After all, unlike the Raspberry Pi (and others assertions about

the Pi to the contrary)  that is what it was designed for. There is some

Actually, I've mentioned in other posts that it should be possible to generate waveforms of the order of 50MHz or so.

Why would one want to turn a PRU into a 100MHz oscillator? However, others may be interested in triggering an output within 5nsec, 10nsec, 15nsec or even 50nsec or 500nsec -  it is determinate, unlike a Linux app. This means that I can use it for serial and parallel protocols that run to high speed.

An example: I recently needed an adjustable pulse generator, and as a quick hack I was able to use a PRU to generate pulses in increments of 5nsec. It was fantastic. As a suggestion, if anyone has time, it is possible to load PRU code on the fly, so it is possible to create the code for (say) a 5nsec, 10nsec, 15nsec etc.. pulse to any arbitrary limit, assemble from within the Linux executable if required! load it into the PRU and execute. Before this, I would have had to program a CPLD for the task. I don't keep my programmable logic toolchain and test tools on my day-to-day laptop, so it was an inconvenience if I'm traveling (which I was).

Currently I'm investigating high-speed parallel capture (to around 30MHz, but I'm using an external oscillator - for my use-case it would be very poor form to rely on an internal oscillator for this.

By the way, for data capture, it is possible to use a serial mode which can clock in at 200MHz apparently (i.e. I have not tried it to confirm it or not), but I'm very happy if I can achieve a rate of the order of tens of Mbytes per sec of data in (parallel mode). This is non-trivial without a FIFO and CPLD or FPGA, and is great that it is possible with such a board.

Gary Stewart wrote:

 

I still see the BeagleBoard Black as clearly being more useful for most embedded applications (depending on video and I/O needs) and engineering students. After all, unlike the Raspberry Pi (and others assertions about the Pi to the contrary)  that is what it was designed for.

I agree on most of this. I'm not interested in running a desktop with the BBB, but that's me, it doesn't matter. Not all schoolchildren have access to a desktop (nor Internet at home, for that matter), so I'm very happy if the RPI can help their education. I don't think many dispute that aspect. The RPI has it's flaws, and as an Engineer I can't help but point them out. The BBB has it's flaws too - for example currently some image restrictions are hampering me.

By the way, regarding your memory comment - I'm not sure this is true - see here. I believe Wikipedia's entry to be wrong on the matter. Perhaps we can ask Jason Kridner to confirm or not, he frequents the forum.

Shabaz wrote:

Actually, I've mentioned in other posts that it should be possible to generate waveforms of the order of 50MHz or so.

It says 200 MHz here (and in several other posts) which is what I am responding to and is clearly not obtainable on the outputs at least.

Shabaz wrote:

Why would one want to turn a PRU into a 100MHz oscillator?

Or a logic gate ? Next time I'll put up a sarcasm alert.

Shabaz wrote:

By the way, regarding your memory comment - I'm not sure this is true - see here. I believe Wikipedia's entry to be wrong on the matter. Perhaps we can ask Jason Kridner to confirm or not, he frequents the forum.

The bandwidth is quoted directly from the latest version of the BeagleBone Black reference manual which states that the memory is running at DDR400 (800 MT/s) for 1.6 GB/s. It is impossible to

determine the speed of the memory used on my BBB because it is marked with a "generic" 4 Gb SDRAM part number (I have the data sheet it references) that does not include the speed grade.

Actually the lowest speed grade according to the data sheet is DDR533 so some overclocking may be possible. For now I'll go by what Beagleboard.org says.

Gary Stewart wrote:

 

 

Or a logic gate ? Next time I'll put up a sarcasm alert.

 

You know I hope what they say about sarcasm.. Are you saying that I thought better of you than I should have :-)

Or, one could use their imagination and explore what can be done beyond an oscillator or single logic gate - such as a 5nsec granularity adjustable pulse generator which I mentioned, and worked rather well.

Morgaine Dinova wrote:

 

Just linking John's well researched comparison of the state of openness and/or documentation for the two boards here, so that it doesn't get lost.  That thread in the Pi Group is growing like topsy.

Thank you for the kind words, but as I said at the beginning of the comment it's just a quick comparison -- not at all what I'd call well-researched.  It's just that I've spent a reasonable amount of time with the documents -- and huge amounts of time with similar documents -- so it was easy to point out some obvious differences.

One part which I appreciated a lot was your pointing out the difficulties of comparison:

John Beetem wrote:

 

Interrupts: BCM has 10 pages, not sure if it covers what you need to write an OS.  TI has 200 pages.  Don't know if this is just because TI is more versatile, or whether it covers more ground.

It's this kind of problem that I think makes it quite impossible to rank "degree of openness" quantitively, as is being suggested over in the Pi Group.  The difficulties are so great that anything other than a plain statement of the facts that A, B and C are not documented is going to be nothing but massaging the truth, even if that is not the intention.