Pi vs BeagleBone-Black

I'd like to add another pro for the BeagleBoard Black.

With the exceptions of the integer real time processors PRU-ICSS (not sure at this point why that is), and the PowerVR GPU for

well known reasons, the AM3359 technical documentation from TI is excellent to the point of overwhelming. The Technical Reference

Manual is over 4000 pages. No I did not accidentally add any zeros !

Gary Stewart wrote:

 

With the exceptions of the integer real time processors PRU-ICSS (not sure at this point why that is), and the PowerVR GPU for well known reasons, the AM3359 technical documentation from TI is excellent to the point of overwhelming.

You're right about the proprietary GPU, that seems to be an endemic problem for open source in the industry.  It's not true for the PRU-ICSS though.

The PRU-ICSS is fully documented in the Technical Reference Manual SPRUH73C, with the entirety of chapter 4 (250 pages) devoted to it.  Also, there is a full package of PRU-related materials on Github, including more documentation and source code of the PRU's PASM assembler, a Linux loader, demos, etc.  I've even checked that the assembler compiles and it does.

The BeagleBone materials on Github are at https://github.com/beagleboard/am335x_pru_package

The PRU has been used successfully in quite a number of projects as a quick web search shows, and this long predates the BeagleBone Black since the original BeagleBone uses a slightly different version of the same AM3359 SoC.

Morgaine.

Addendum: Repeating the link to TI's wiki pages on PRU which I gave in my first post on this thread, in case it was missed when looking for docs.  There is a developers' link at the bottom of that first page.

Morgaine Dinova wrote:

 

Gary Stewart wrote:

 

You really need to get better acquainted with real time Linux.

 

And you really need to stop attacking other forum members with personal remarks like this that don't advance the argument. Focus on the message, not the person delivering it.

And you really need to stop attacking other forum members with personal remarks like this that don't advance the argument. Focus on the message, not the person delivering it.

Original message:

The Unix model of operating systems just isn't designed for realtime programming, and no matter what realtime patches you apply or which realtime scheduler you enable (I've played with both), you're never going to get anything like the low response latency and absence of jitter that you can get from the cheapest of microcontrollers.  A far better approach is therefore to combine a bare-metal micro with a *nix system, and let the latter control the former with high-level commands which the micro then executes with very tight timing constraints.

That was an attack on the message. I can't help if you take it personally. As far as that and your far better approach goes see the remaining responses.

I agree, 100us is pretty poor response latency for most realtime requirements, and the jitter isn't even quantified.

It is still, and forever will be dependent on the application (of course) and there are a lot of applications where 100 uS works just fine whether you want to admit it or not. As far as

jitter qualification goes we are not doing a tutorial on real time we are discussing whether real time Linux works (depending on the applications of course). There are many companies

that find real time Linux perfect for their needs. There are a few big time RTOS companies, QNX and LynuxWorks are two that come to mind, that offer a full feature RTOS

approach and not your "far better approach" when is not better (depending on the application of course). There are quite a few full feature free RTOS's that do to. Perhaps you

should go tell all of them that they are wrong. I'm sure they would value your opinion on that subject.

Here's an interesting quantitive study comparing the performance of ordinary SuSE with realtime SuSE.

The study is on a real-time Linux for enterprise servers using 8 core Opterons, not a typical real time application (and with different needs than the typical real time applications),

not your typical real time hardware (boy is that an understatement), and certainly not typical of real time applications discussed here. Enterprise servers anyone ?

Hard realtime response doesn't just seek to reduce response latency, but also its jitter.  What's more, a common goal is to reduce jitter to effectively zero ("effectively zero" in this case typically meaning sub-clock period) by using edge detection on input and running a fixed set of instructions to deliver a fixed-latency response.

This was a general discussion of using real time Linux. Hard real time was mentioned but it is not the specific subject. The specific subject is people like you and others saying real time Linux doesn't work

despite lots of evidence that says otherwise (and taking it personally when somebody points this out, see I told you I'd get back to that). The statement about jitter in hard real time is correct. While the goal

is to reduce jitter to effective zero, like most goals in the real world it can not always be achieved. For the record there are commercial products that use hard real time Linux (depending on the application of

course) so it seems that they have tamed the jitter monster enough to make it work anyway. That's called engineering. I'm sure they would like to hear from you to set them strait on why it doesn't really work.

Sorry about the massive redundancy but that simple statement just keeps flying over some peoples heads.

Gary Stewart wrote:

 

Original message:

 

The Unix model of operating systems just isn't designed for realtime programming, and no matter what realtime patches you apply or which realtime scheduler you enable (I've played with both), you're never going to get anything like the low response latency and absence of jitter that you can get from the cheapest of microcontrollers.  A far better approach is therefore to combine a bare-metal micro with a *nix system, and let the latter control the former with high-level commands which the micro then executes with very tight timing constraints.

 

That was an attack on the message. I can't help if you take it personally. As far as that and your far better approach goes see the remaining responses

You are deliberately misreferencing.  Your personal attack was not the comment on the above, but the comment below:

Gary Stewart wrote:

 

You really need to get better acquainted with real time Linux.

That has nothing to do with the subject matter, and everything to do with attacking the messenger.  Don't do it.

And then because your earlier personal attack wasn't enough, you did it again:

Gary Stewart wrote:

 

Perhaps you should go tell all of them that they are wrong. I'm sure they would value your opinion on that subject.

and again

Gary Stewart wrote:

 

I'm sure they would like to hear from you to set them strait on why it doesn't really work.

Just stop it.  Talk about the technical topic, don't criticise fellow forum members when you reply to them, it adds nothing to the discussion.

Your technical comments are welcome, and interesting.  If you disagree with an observation, just say you disagree and provide contrary evidence.  You don't need to attack the messenger as part of your rebuttal.  It's not a valid form of engineering discussion.

This is in reply to the technical subject matter, which is interesting.

Gary Stewart wrote:

 

      Morgaine wrote:

 

      I agree, 100us is pretty poor response latency for most realtime requirements, and the jitter isn't even quantified.

 

It is still, and forever will be dependent on the application (of course) and there are a lot of applications where 100 uS works just fine whether you want to admit it or not. As far as

jitter qualification goes we are not doing a tutorial on real time we are discussing whether real time Linux works (depending on the applications of course). There are many companies

that find real time Linux perfect for their needs. There are a few big time RTOS companies, QNX and LynuxWorks are two that come to mind, that offer a full feature RTOS

approach and not your "far better approach" when is not better (depending on the application of course). There are quite a few full feature free RTOS's that do to.

I agree, it is always dependent on the realtime requirements of an application, and a poorly performing realtime system may well be good enough for an application that has only weak realtime requirements.  There are undoubtedly many applications for which the 100us or so latency and unspecified jitter of realtime Linux is perfectly adequate, or at least acceptable.  I even use it myself for MIDI work (I use Linux for everything, realtime for MIDI musician apps), and it is on the verge of being acceptable if one isn't very demanding.  One could never call it great though, as the hand-ear-brain system easily notices the poor latency.

We're not doing a tutorial, but we are discussing the technical merits of different approaches to achieving realtime performance in an embedded Linux system, and there is not the slightest doubt that the realtime performance of realtime Linux is very poor compared to that of any old bare metal embedded microcontroller.

That's not in any doubt because it's not a matter of opinion but a matter of measurement.  You seem to be disputing the quantitive study that I linked because it used high-end machinery, but high-end machinery will almost always yield better performance in a realtime operating system simply because everything runs faster, so I can't agree with your dismissal of that study.  On a low-end Linux system, naturally the performance would have been even worse.

Morgaine.

I wonder why I gave up on the Pi forums.

It used to be so much more peaceful here.....

Mark

I noticed your interesting blog post about evaluating the Freescale Freedom-KL25z board. 

That's a very nice little Cortex-M0+ microcontroller and a well-featured board, especially for frugal low power standalone applications.  Have you tried linking it to the Pi for I/O expansion and better realtime response?  The very low price would seem to make it quite a good companion for the Pi, and your "easy to use" comments were encouraging, inasmuch as the barrier for budding engineers to get to grips with microcontroller programming would be quite low.

Morgaine Dinova wrote:

 

Gary Stewart wrote:

 

Original message:

 

The Unix model of operating systems just isn't designed for realtime programming, and no matter what realtime patches you apply or which realtime scheduler you enable (I've played with both), you're never going to get anything like the low response latency and absence of jitter that you can get from the cheapest of microcontrollers.  A far better approach is therefore to combine a bare-metal micro with a *nix system, and let the latter control the former with high-level commands which the micro then executes with very tight timing constraints.

 

That was an attack on the message. I can't help if you take it personally. As far as that and your far better approach goes see the remaining responses

 

You are deliberately misreferencing.  Your personal attack was not the comment on the above, but the comment below:

 

Gary Stewart wrote:

 

You really need to get better acquainted with real time Linux.

 

That has nothing to do with the subject matter, and everything to do with attacking the messenger.  Don't do it.

 

And then because your earlier personal attack wasn't enough, you did it again:

 

Gary Stewart wrote:

 

Perhaps you should go tell all of them that they are wrong. I'm sure they would value your opinion on that subject.

 

and again

 

Gary Stewart wrote:

 

I'm sure they would like to hear from you to set them strait on why it doesn't really work.

 

Just stop it.  Talk about the technical topic, don't criticise fellow forum members when you reply to them, it adds nothing to the discussion.

 

Your technical comments are welcome, and interesting.  If you disagree with an observation, just say you disagree and provide contrary evidence.  You don't need to attack the messenger as part of your rebuttal.  It's not a valid form of engineering discussion.

  You are deliberately misreferencing.

No, you are. The statement:

  The Unix model of operating systems just isn't designed for realtime programming, ...

the "attack":

You really need to get better acquainted with real time Linux.

Pretty sure that is a response to the message not an attack on the messenger and directly related to that statement, subject matter or not.

  Just stop it.  Talk about the technical topic, don't criticise fellow forum members when you reply to them, it adds nothing to the discussion.

Does your regular use of fanbois or Raspberry Pi fanbois in completely non-technical posts of yours count as criticizing fellow forum members ?

We're not doing a tutorial, but we are discussing the technical merits of different approaches to achieving realtime performance in an embedded Linux system, and there is not the slightest doubt that the realtime performance of realtime Linux is very poor compared to that of any old bare metal embedded microcontroller.

Not sure how discussing hard real time jitter relates to discussing the performance of real time Linux compared to any old bare metal processor. Seems like it would be more appropriate if we were discussing real time Linux performance verses

any other full feature RTOS performance (apples to apples).

Your technical comments are welcome, and interesting.  If you disagree with an observation, just say you disagree and provide contrary evidence.

I do, and you do your best to ignore it. Well until now at least.

I agree, it is always dependent on the realtime requirements of an application, and a poorly performing realtime system may well be good enough for an application that has only weak realtime requirements.  There are undoubtedly many applications for which the 100us or so latency and unspecified jitter of realtime Linux is perfectly adequate, or at least acceptable.

OK, thanks ? But excuse me if I add that the quality of the performance is in the eye of the people building the application and the performance of the application itself not what negative spin you

want to put on it. Your continual use of damming with faint praise, adding "poorly performing", "weak realtime requirements", and "at least acceptable" to your sentences are classic examples,

clearly show bias on your part. You keep using absolute terms (always negative) to describe relative qualities (for the dependent part). The poor performance you speak of is prettymuch in line

with most commercially available full feature RTOS's given equivalent hardware and the weak real time requirements are common to a lot of applications. I'm not sure how, technically speaking of

course this makes them weak and I'm sure that the commercial RTOS people would hotly dispute the description of their RTOS as poorly performing.

We're not doing a tutorial, but we are discussing the technical merits of different approaches to achieving realtime performance in an embedded Linux system, and there is not the slightest doubt that the realtime performance of realtime Linux is very poor compared to that of any old bare metal embedded microcontroller.

Not sure how discussing hard real time jitter in Linux relates to discussing the performance of real time Linux compared to any old bare metal processor. Seems like it would be more appropriate if we were

discussing hard real time Linux performance verses any other full fearture RTOS hard real time performance (apples to apples).

You seem to be disputing the quantitive study that I linked because it used high-end machinery, but high-end machinery will almost always yield better performance in a realtime operating system simply because everything runs faster, so I can't agree with your dismissal of that study.

No, I clearly disputed the study because it was for enterprise class servers which is not even close to a typical real time application, and it did not use hardware that was even close to typical hardware. I now add that it was not a

hard real time test even though you used it as an example for explaining hard real time jitter problems and the test results for one particular version of non-hard real time Linux optimised for the enterprise server environment does

not tell me anything about others that are optimised for more general hard real time and real time applications.

I agree Mark.  This thread has lost focus. 

It WAS about a comparison of the Raspberry Pi to BeagleBone Black and how we'll use each.  Now we have gotten down to Real Time OS and FPGA like abilities.  95% of the market is going to use BOTH boards for hobbies and prototyping.  I was one of the first people to say my preferences (RPi Model A for small stuff because of power consumption and BBB for large projects because it has more of the features I'm looking for like IO.)

I would say lets fork the BBB technical talk to another thread (maybe in the BeagleBone forum) because that seems to all this is now.

Morgaine

Not yet, as I'm waiting for the headers to arrive. Silly me expected jaycar to carry them, but no...

I did order 3 more to go with the ione E14 sent. How could you resist.?

An expansion board is lacking as well, which is a shame as the number of I/O make this better priced than a Mega.

I have a cunning plan, but need to sit down and discuss it with someone for doing the boards and then selling them to make them very affordable.

If you've been following the top members forum, you'll also see that currently mbed.org is my best option for programming it, and someone has kindly done half a library that allows the existing arduino sketch to be used.

I've ordered another Pi interface so eventually it will get connected, or a normal arduino and this used as a remote using the built-in accelerometer and touch slider.

Cheers

Mark

Ervin Kosch wrote:

  I was one of the first people to say my preferences (RPi Model A for small stuff because of power consumption and BBB for large projects because it has more of the features I'm looking for like IO.)

I'm curious what your power consumption figures are like for the model A as the BBB SRM has some interesting power consumption figures that on paper appear a good deal better than the B under somewhat similar circumstances.

Ervin

I'm all up for a good debate, however this (from an outsiders view point) has turned into something else, resembling kids squabbling over he said, she said.

I think everyone needs to take a deep breath, and quieten down.

I've seen a written sentence interperated different ways by different readers before, and neither reader got it right, because that wasn't the way it was intended.

It just so happened that the writer hadn't phrased it as well, hence it wasn't as clear as they intended.

I'm sure both boards will have their place in our world, and one might be favoured over the other for xyz reason(s).

I haven't seen a direct comparison between the both to enable a begineer to make choices.

I'm sure that with all the intellect in this group, we should be able to draw up a chart, so that someone could do that, and yes price may be one factor.

So how about it people?

cheers

Mark

Ervin

I'm all up for a good debate, however this (from an outsiders view point) has turned into something else, resembling kids squabbling over he said, she said.

I think everyone needs to take a deep breath, and quieten down.

I've seen a written sentence interperated different ways by different readers before, and neither reader got it right, because that wasn't the way it was intended.

It just so happened that the writer hadn't phrased it as well, hence it wasn't as clear as they intended.

I'm sure both boards will have their place in our world, and one might be favoured over the other for xyz reason(s).

I haven't seen a direct comparison between the both to enable a begineer to make choices.

I'm sure that with all the intellect in this group, we should be able to draw up a chart, so that someone could do that, and yes price may be one factor.

So how about it people?

cheers

Mark

Mark,

> I haven't seen a direct comparison between the both to enable a begineer to make choices.

There is a summary comparison for beginners here:

   http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=41489&start=81

I found user gyeben's response interesting, which says:

     "Took a look at the article mentioned in the first post (http://roboteurs.com/beaglebone-black-vs-raspberry-pi/) and that article is clearly unfair to the Pi. 

        | Some people have clocked the Pi up to 1Ghz but its pretty risky.

     It's NOT risky. Overclocking the CPU is not risky at all."

Mark Beckett wrote:

 

I'm all up for a good debate, however this (from an outsiders view point) has turned into something else, resembling kids squabbling over he said, she said.

 

I think everyone needs to take a deep breath, and quieten down.

 

...

 

cheers

Mark

The following comment is to be taken humorously and with hopes that this shadow hasn't offended:  It does seem to the casual observer that some of the above discussion appears to be arguing-for-the-sake-of-arguing rather than a productive exchange of ideas.  Personally, some of it calls to mind a Shakespeare play in which a young man and a young woman are constantly sniping at each other through the first few acts but then they realize that all the arguing is really because of repressed sexual tension and that they're really in love with each other and become an item at the end.

Hmm, now what was the name of that play?

coder27 wrote:

 

Mark,

> I haven't seen a direct comparison between the both to enable a begineer to make choices.

 

There is a summary comparison for beginners here:

   http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=41489&start=81

 

I found user gyeben's response interesting, which says:

 

     "Took a look at the article mentioned in the first post (http://roboteurs.com/beaglebone-black-vs-raspberry-pi/) and that article is clearly unfair to the Pi. 

        | Some people have clocked the Pi up to 1Ghz but its pretty risky.

     It's NOT risky. Overclocking the CPU is not risky at all."

Here's what I wrote at in the same RasPi forum discussion:

What are some of the things you get for that extra US$10 versus RasPi?

 

Faster processor: 1 GHz Cortex-A8 versus 700 MHz ARM11.

Far more I/O pins.

Ethernet that connects directly to SoC instead of over USB.

Two RISC engines for low-level programmable I/O.

BBone white has rounded corners so it actually fits in an Altoids box.  I think BBone black is the same form factor.

 

According to my observations, I would say RasPi has better community support so is a better choice for new users.  IMO Beagle has always targeted developers rather than users -- I don't know if there will be an effort to change that.  Also, it may only be my own impression.

 

[Edit: Beagle does have good community support -- it just seems to me that RasPi's is better and that it's easier for a new user to get up to speed with RasPi than Beagle.  For example, it's easier with RasPi to find a recommended OS version and install it.  JMO/YMMV]

Today I would also add that BBone Black has 2GB eMMC on the board which is pre-loaded with Ångström so it boots right out of the box and is immediately useful.  BBone's Cortex A8 supports other GNU/Linux distros such as Ubuntu which haven't been ported to RasPi.  (Personally, I prefer the Debian on RasPi to Ubuntu on my x86 PC -- chacun a son goût.)

OTOH, for video RasPi's media processor is probably better.  Like Morgaine, I have no need for it so it's not an advantage.

Also, I wrote the above comment before discovering that beagleboard.org had just reformatted their web site and it appears now to be a lot easier to get OS distros (for example).

Luc, Mark and Ervin, I agree completely about the pointless digression into realtime Linux.  That's why I didn't respond to the latest salvo, it's clearly a non-productive argument, so I ended the interchange unilaterally.  The merits or otherwise of realtime Linux are entirely irrelevant to the discussion about BBB versus Pi.  I tried to end it through reasoned discussion, but that failed.  Sorry.

In contrast, the BBB's PRUs are entirely relevant in the comparison, because it's a salient built-in feature of the BeagleBones and is so powerful that it has front-page bullet points on beagleboard.org's BBB page.  It's clear that they rate it highly, and not discussing it in a comparison with Pi would be remiss.

Also, let's not forget that even Eben Upton has publicly expressed support for the idea of coupling the Pi to an Arduino.  He's an engineer, and he knows full well that the gains in interface expansion and in realtime performance are really quite enormous when you combine the two.  Even the Gertboard has a microcontroller on-board, and despite not being an RPF product, it certainly has their blessing.

Well, because of its PRUs, the BBB requires no additional microcontroller to achieve the same kind of gains in interface expansion and realtime performance, so this enters very strongly into the comparison.  Pi can handle a small amount of interfacing without additional hardware, whereas BBB can handle a lot more.  Pi can satisfy very very weak realtime requirements with its standard kernel, whereas BBB can meet very hard realtime constraints with its standard kernel because it has a couple of PRUs that are dedicated to I/O.  For ambitious applications, that's a very big deal.

PS. This was about one feature only, where BBB happens have superior functionality.  Both boards do of course have both pros and cons, that's very clear, and it means that there is no "best board".  There is only "best board for your particular requirements", and so the answer will vary with the person.

Morgaine.

> OTOH, for video RasPi's media processor is probably better.  Like Morgaine, I have no need for it so it's not an advantage.

I think the details are still unclear about the BBB's usability for home theatre.

Apparently it mainly uses the cpu for mpeg decoding.  So does that mean that VLC

will be usable (unlike on the RPi where only omxplayer is hardware accelerated?)

It seems to me it is a bit unfair comparing TI's second generation BB to the RPF's

first generation product.  The RPi's big advantage now is that it is in mass production,

but the BBB is just announced and temporarily out of stock, with no clear idea of how

fast production can be ramped.  We have yet to hear when the RPi's educational release

will be or what it will include, but release 3.0 and/or 2nd generation is said to be coming.

I think it's noteworthy that the BBB is FCC/CE certified for sale to residential users,

but the current RPi as far as I know is not.  I think it's also noteworthy that the BBB

claims to support the Microsoft wireless 800 keyboard.  I think it's noteworthy that the

Fedora ARM folks support the BB directly, rather than indirectly through Seneca as a Remix.

coder27 wrote:

 

I think the details are still unclear about the BBB's usability for home theatre.

How welll it will perform in that role remains to be seen, but one thing is absolutely crystal clear.  It was not designed for that purpose, so if it works well as a media centre it will be as a lucky side effect of providing a working X11 desktop or Arduino UI. (*)

I've now read about half of the BBB System Reference Manual, and they make it abundantly clear that the board was developed to support engineers, technical enthusiasts, makers, and educators+students.  Reading between the lines, and from interacting with the BB community directly, there is considerable {concern,hostility,apathy} towards those that jumped on the Pi educational bandwagon purely because they wanted a cheap media centre.  The views vary of course, but I think it's safe to say that nobody considers the BBB to be a media centre platform, even if it works.

That area still belongs entirely to the Pi, and any competition for media centre eyeballs is unlikely to be coming from the BB stable.

Morgaine.

(*) PS. Lucky side effects are not impossible.  BBB has been shown running Quake 3.

> if it works well as a media centre it will be as a lucky side effect of providing a working X11 desktop or Arduino UI. (*)

Or perhaps as a lucky side effect of supporting Android with Flash and/or html5.

The RPF actively encouraged media centre users, and I think they account for

a significant fraction of sales.  I think a lot of folks justify the purchase by saying

"I'll buy it to learn programming, and if that doesn't work out, I can still use it as a

media center."  So quite a successful sales tactic.

Morgaine Dinova wrote:

 

coder27 wrote:

 

I think the details are still unclear about the BBB's usability for home theatre.

 

How welll it will perform in that role remains to be seen, but one thing is absolutely crystal clear.  It was not designed for that purpose, so if it works well as a media centre it will be as a lucky side effect of providing a working X11 desktop or Arduino UI. (*)

 

I've now read about half of the BBB System Reference Manual, and they make it abundantly clear that the board was developed to support engineers, technical enthusiasts, makers, and educators+students.  Reading between the lines, and from interacting with the BB community directly, there is considerable {concern,hostility,apathy} towards those that jumped on the Pi educational bandwagon purely because they wanted a cheap media centre.  The views vary of course, but I think it's safe to say that nobody considers the BBB to be a media centre platform, even if it works.

 

That area still belongs entirely to the Pi, and any competition for media centre eyeballs is unlikely to be coming from the BB stable.

 

Morgaine.

 

(*) PS. Lucky side effects are not impossible.  BBB has been shown running Quake 3.

BBone has a powerful 3D graphics engine.  I don't know how it compares to RasPi -- I hear opinions about RasPi's being better but haven't seen any independent benchmarks.  So BBone is great for synthesizing graphical images.  Now for decoding purchased (or not) video content or video encoding, it's probably true that RasPi is better, but "those frills cost money" -- you may have to purchase licenses for the RasPi Codecs.

Regarding {concern,hostility,apathy}, my own feeling is mostly "pity" as in "here you have a pretty decent GNU/Linuix box and you just want to watch silly videos?"  My chief annoyance with "RasPi as naked Roku2" users is that they made it really hard to get a RasPi when it first came out.  OTOH, those "other users" help drive the price down, which benefits everyone in the long run.  As a free-as-in-freedom proponent, I want to be able to use hardware I buy for whatever I want so I must support the right for others to do the same.

John Beetem wrote:

 

Regarding {concern,hostility,apathy}, my own feeling is mostly "pity" as in "here you have a pretty decent GNU/Linuix box and you just want to watch silly videos?"

I haven't detected "pity", so I'll add yours to the list.

I have noticed a fair bit of ridicule too, although I don't think any of the above 4 accounts for it.  It seems to stem from simple peergroup reinforcement, blowing raspberries at "that other lot" not for any solid reasons but to sound cool in company.  Unfortunately IRC seems to encourage it.  I think it's softened a bit now compared to 9-12 months ago, possibly because a large number of BB owners now have Pi boards too.

I like all the boards, they all have a specific niche where they shine.  Pi-B's niche is narrowing now though.

Morgaine Dinova wrote:

 

Pi-B's niche is narrowing now though.

Indubitably.  When BBone was US$89 plus US$50 for a DVI-D card the combination was 4X a RasPi model B.  Now it's just 30% more (US$45 versus US$35).  If you're a teenager, that's a lot fewer cars to wash or lawns to mow.  Teen geeks should charge more for resetting digital clocks after power failures.

IMO BBone Black is the clear winner for a maker.  RasPi is IMO still better for a newbie mostly interested in software or very simple hardware.