Pi vs BeagleBone-Black

Jonathan Garrish wrote:

 

selsinork wrote:

 

John Beetem wrote:

For example, there's a real photo of me somewhere at element14 but have fun finding it

 

Challenge accepted,  http://www.element14.com/community/community/members/blog/2013/04/25/having-a-blast-at-design-west

 

I'm relieved to note that John bears a passing resemblance to a 21st century Jules Verne.

My mother says "all bearded men look alike"

I agree with you, Drew and jamodio.

Superior experience for beginners out of the box, superior experience for experts later, with far more extensive hardware interfacing potential, the programming of PRUSS, and the creation and stacking of capes.  We were talking about a simple comparison table between Pi and BBB, but I don't think that's likely to indicate just how much more advanced the BBB experience and potential really is.

The Pi is a nice little gadget if your application can work within its limits and foibles, and it has no same-price challengers yet as a home media center.  What's more, Pi Model A has no directly comparable challengers on price at all.  However, the Pi's range of "Best for application X" has now been reduced very sharply by BBB.  And somewhat embarassingly, BBB has much more education potential than Pi, and most of the Pi educational examples will work just as well or better on BeagleBones because they are typically generic Linux applications.

This is a great time to be involved with ARM, so many excellent choices.

Morgaine.

John Beetem wrote:

 

PSoC has had limited success, largely because the chips have been rather expensive.  PSoC4 is supposed to change this by providing a highly capable SoC for US$1.

Did you notice that the  CY8CKIT-042 PSoC4 Pioneer Kit board contains, in addition to the PSoC4 target device, a PSoC5 device that's used for board programming and debug?  (The intro video mentioned it.)  If PSoC4 is the cheap device, you'd think they'd use a second PSoC4 to provide that function on this cheap board.

It seems a little bizarre, but I guess they already had PSoC5 code developed for the required function, and don't expect to sell enough boards to recoup additional development required to use the cheaper part instead.

Morgaine Dinova wrote:

 

John Beetem wrote:

 

PSoC has had limited success, largely because the chips have been rather expensive.  PSoC4 is supposed to change this by providing a highly capable SoC for US$1.

 

Did you notice that the  CY8CKIT-042 PSoC4 Pioneer Kit board contains, in addition to the PSoC4 target device, a PSoC5 device that's used for board programming and debug?  (The intro video mentioned it.)  If PSoC4 is the cheap device, you'd think they'd use a second PSoC4 to provide that function on this cheap board.

 

It seems a little bizarre, but I guess they already had PSoC5 code developed for the required function, and don't expect to sell enough boards to recoup additional development required to use the cheaper part instead.

Yes, I saw that.  It's not at all unusual to have a much more capable part as the program/debug interface.  If I've read the data sheets correctly, the PSoC4 only has 32KB flash and 4KB SRAM, while the PSoC5 has 256KB flash and 64KB SRAM.  It's hard to squeeze much into 32K+4KB, particularly if the code is written by people who didn't grow up carrying around boxes of punched cards (2000 cards per box * one box per arm * two arms per human = 4000 lines of code that you can "comfortably" carry around if you have two arms).

Reminds me of an LPXpresso board I have for the LPC1114FBD48/301,1LPC1114FBD48/301,1 -- a Cortex-M0 with 32KB flash and 4-8 KB RAM.  It's controlled by an LPC3154 -- an ARM9 with 192KB RAM.  I don't know how this compares to an mbed because my mbed has the controller's part number erased.

It's often the case that the control SoC is the one to play with, provided that the vendor hasn't disabled access.

John Beetem wrote:

 

Reminds me of an LPXpresso board I have for the LPC1114FBD48/301,1LPC1114FBD48/301,1 -- a Cortex-M0 with 32KB flash and 4-8 KB RAM.  It's controlled by an LPC3154 -- an ARM9 with 192KB RAM.

Haha.  That's a pretty severe case of an application processor in servitude to a microcontroller.  It can't be impressed.

I guess it's only a matter of time before Cortex-A series devices are given such roles too, particularly if a small realtime microcontroller needs a full-function IPv6 stack and comprehensive networking apps, and the simplest way of providing this is by giving it an entire Linux subsystem on a different SoC.

Morgaine Dinova wrote:

 

I guess it's only a matter of time before Cortex-A series devices are given such roles too, particularly if a small realtime microcontroller needs a full-function IPv6 stack and comprehensive networking apps, and the simplest way of providing this is by giving it an entire Linux subsystem on a different SoC.

Actually, at some point it might be a good idea just to have the vendor's eval board be a BeagleBone cape.  That way they don't have to design their own controller hardware.  One problem with this is that the vendor has to worry about whether the user has a compatible operating system.  I don't have experience with Linux device drivers, but it may also be that it's a lot easier to write the whole debug controller on a bare chip than to write the Linux driver   Note that I didn't mention RasPi -- the vendor needs an open hardware project so it's not stuck if the controller board is discontinued.

John Beetem wrote:

Note that I didn't mention RasPi -- the vendor needs an open hardware project so it's not stuck if the controller board is discontinued.

How is any ARM SOC with a proprietary GPU considered to be open hardware ? Isn't that a contradiction of terms ?

Gary Stewart wrote:

 

John Beetem wrote:

 

Note that I didn't mention RasPi -- the vendor needs an open hardware project so it's not stuck if the controller board is discontinued.

 

How is any ARM SOC with a proprietary GPU considered to be open hardware ? Isn't that a contradiction of terms ?

Well, technically you're right since open source hardware (OSH) requires that all chips be fully documented.  However, my example of using BeagleBone as the controller for a chip's demo board doesn't need the GPU so for this application BeagleBone is indeed OSH.  You have open schematics, everything documented except GPU (I personally believe the PRUSS omission in latest TRM is an oversight), Gerbers, BOM, and all chips can be purchased in low volumes.  This is very different from RasPi, where most of the SoC is undocumented and it cannot be purchased in low volumes, and there are no Gerbers.

I don't know what discussion OSH advocates are having about GPUs.  I suspect some argue that if you provide a GPU + binary blob, then as long as the API interface is fully documented you can think of the GPU as an OpenGL black box that happens to be implemented with downloadable black-box microcode.  However, in that case I would say you can't call it a GPU -- it's an embedded OpenGL engine where the implementation is hidden the same way you don't expose the innards of the ARM implementation.  IMO if you call it a GPU, then you have to let me program it or it's not OSH.

I find the fact that FPGA bit streams are undocumented is much more annoying.  Yet, OSH champions like FPGAs since it lets them design their own open CPU architectures.  So plenty of opportunities to argue about how many angels can dance on the head of a pin.

John Beetem wrote:

 

Well, technically you're right since open source hardware (OSH) requires that all chips be fully documented.  However, my example of using BeagleBone as the controller for a chip's demo board doesn't need the GPU so for this application BeagleBone is indeed OSH. 

There's no argument that GPU's are a problem and are likely to remain locked up behind a wall of patents, cross licensing and whatnot. So regardless of other issues the Pi isn't on the same playing field here. Most other SoCs are an Arm core with an undocumented, propriatary, GPU along for the ride, you can ignore the GPU, probably even turn it off and still use the rest of the SoC. For the Pi, you have an undocumented, propriatary Videocore GPU, with an Arm along for the ride - you can't get to the Arm without the GPU as the SoC is first and foremost a GPU.

Even if the interface into that black box was fully documented it doesn't matter. A patent or licensing dispute could render you unable to legally use the GPU firmware and so unable to access the Arm.

Another advantage for the BeagleBone Black, beyond OSHW, is that the BeagleBoard.org development community (TI employees, Linux kernel maintainers & various individuals) have been working hard to get all remaining patches accepted by the mainline.  jkridner has told me that is an important goal for the project to be able to just git clone Linus's kernel and go.