Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 358 replies
  • Subscribers 674 subscribers
  • Views 39700 views
  • Users 0 members are here
Related

Pi vs BeagleBone-Black

Former Member

So, just over a year on from the initial availability of the R-Pi and the new BeagleBone Black is upon us.  They've obviously taken a leaf out of the RPF's playbook and produced a cost reduced version at a price only marginally above the Pi.

 

I find it interesting that the compromises are very different, for example there's a proper PMIC and the ethernet is not troubled by being connected to USB, however the on-board HDMI seems less capable.

 

Other differences are in the documentation, I'm currently viewing the pcb gerbers for the beaglebone..  Have yet to see any sign of those for the R-Pi a year later. There's even an up to date devicetree capable kernel too.

 

Technology has also moved on somewhat, we get a 1GHz Cortex A8 which is better than the Pi, along with various other stuff and lots more GPIO's too.

 

Ok, so it's clear that I like the look of the new beaglebone, and given the price I'm likely to put any further R-Pi plans on hold until I have a chance to play with this. It's also making things like the Olinuxino-maxi I bought recently look very slow/expensive while still being cheaper than the similarly specced Olinuxino-A13

 

Some details of the beaglebone-black here http://circuitco.com/support/index.php?title=BeagleBoneBlack

 

What do the rest of you think ?   I don't expect this to displace the Pi anytime soon, but I expect it to be very attractive to those people who don't simply want to put XBMC on it and duct tape it to the back of the TV..

  • in reply to Former Member

    There are substantial differences in your test set up and theirs so differences in current readings are to be expected. A couple of these differences stand

    out. Since they did not specifically say the hub was powered I assume it was not. And it makes more sense that for power testing purposes to not power

    the hub externally. They stated that the HDMI was connected so I assume the GPU was in use. Between the two port hub, the thumb drive and the GPU

    I'd be surprised if that didn't account for most if not all of the differences you are seeing.

     

    I did a little checking and with a 400 KHz I2C it would take ~ 840 uS to change all three voltages (~ 280 uS for one) due to level two password

    protection of all three registers which have to be individually unlocked before writing to them. This definitely limits just how "dynamic" it can be.

    Still within the limits this sets it can be used to provide a substantial power savings when used.

     

    I received my BeagleBoard Black yesterday and had just enough to power it up tethered and spent about an hour to check it out. Not really all that

    impressed with the tethered mode as you can already do everything it does with a PC and the beagleboard.org URL. Didn't have enough time (or the

    HDMI cable) to check out anything more than that. I do have an RS232 converter I could use to hook up to the serial port so I might try that today.

  • "I'm currently viewing the pcb gerbers for the beaglebone..  Have yet to see any sign of those for the R-Pi a year later."

     

    The stated goal for Pi was to make it so it couldn't be copied. The goal for this board is a reference to copy. Of course you could use the BB as a PI was intended if you can stand the extra $10.

  • in reply to pmoyle111

    Peter Moyle wrote:

     

    "I'm currently viewing the pcb gerbers for the beaglebone..  Have yet to see any sign of those for the R-Pi a year later."

     

    The stated goal for Pi was to make it so it couldn't be copied. The goal for this board is a reference to copy. Of course you could use the BB as a PI was intended if you can stand the extra $10.

    I don't remember ever seeing that as a "stated goal" -- do you have a link?  I think non-copyability is simply a consequence of selecting a Broadcom SoC.  The stated goal of the RasPi Foundation is to provide a really cheap computer so that children can learn to program without fearing the consequences of breaking something expensive.  RPF has always stated that they don't mind competition that furthers the same goal, although one can get a different impression from some of the comments made by RasPi admins and moderators at raspberrypi.org.

  • in reply to johnbeetem

    It has been a  numvber of months ago and I read so many publications and belong to so many groups that I have no idea where I read it. But it was an article that was either an interview or a feature by/of a few of the architects. In it they talked about how it came to be, a number of their goals, and other aspects such as funding. One of these goals mentioned was that they specifically didn't want it to be copied (and I am loosely paraphrasing this) and as I remember that was one of that reasons for choosing the BCOM chip.

     

    You might google to try to find the article.

  • in reply to pmoyle111

    hmmm... I just had a thought that it might have been on the Register.uk. I don't often read this anymore, but I go there sometimes to reads the rumors about layoffs. When I worked for one of the big chip companies that was the place to find out things and I still have a lot of friends there.

  • in reply to johnbeetem

    They've actually said many times that they do plan to release the designs:

    https://www.element14.com/community/thread/17870

     

    http://www.raspberrypi.org/archives/1090#comment-20586

     

    http://www.raspberrypi.org/archives/1090#comment-20591

     

    and the sticking point always seems to be that the Broadcom SoC isn't easily available. but that can only be repeated so many times before people stop believing it - and the world catches up, then overtakes.

  • in reply to pmoyle111

    It is totally incorrect to suggest that a goal of RPi was to prevent it being copied.  In fact, pretty much the opposite is true, officially at least.  Here is an excerpt from the Raspberry Pi Foundation "About" page (my bolding for emphasis):

     

    Raspberry Pi Foundation wrote:

     

    We don’t claim to have all the answers. We don’t think that the Raspberry Pi is a fix to all of the world’s computing issues; we do believe that we can be a catalyst. We want to see cheap, accessible, programmable computers everywhere; we actively encourage other companies to clone what we’re doing. We want to break the paradigm where without spending hundreds of pounds on a PC, families can’t use the internet. We want owning a truly personal computer to be normal for children. We think that 2012 is going to be a very exciting year.

     

    The BeagleBone Black is therefore exactly what the RPi Foundation is encouraging and happy to see emerge.

     

    And BBB is cheaper too (you don't need to buy an extra SD card), which RPF are undoubtedly happy to see since it reduces the barrier for youngsters even further.

     

    Morgaine.

  • in reply to Former Member

    (Reviving an old thread!)

    The hwmon and ADC drivers that Zubair will work on may be helpful for predicting how long power will last before the board should shut down, since the 12-bit ADC should have sufficient resolution for detecting a small drop in supply voltage hopefully if a scaled supply voltage is used for one ADC channel.

     

    I had a few minutes to experiment with battery power again today.

    With the Olimex battery (which takes up no additional volume, because it can fit between the header connectors, the BBB should run for at least 3.5 hours, without any efforts to reduce power consumption. The battery does charge too, despite the charge voltage setting being incorrect (it should be 4.2V, but it is 4.1V with the current build).

     

    With a battery connected, today the power switch (S3) on the BBB does not shut down the board, however the software can power down ('shutdown now' works). When that happens, the power consumption drops to 20uA (this hit the resolution and accuracy limit of my multimeter though). Then, it is possible to start up the BBB again by pressing S3.

     

    So, in summary, a controlled power down to near-zero curent works today. The connection on S3 is brought out to a header too, so can be brought to ground to power up the board (so we could implement an external timer or RTC to power up the board again, so that the CPU could program itself a wakeup time).

  • in reply to shabaz

    shabaz wrote:

     

    So, in summary, a controlled power down to near-zero curent works today. The connection on S3 is brought out to a header too, so can be brought to ground to power up the board (so we could implement an external timer or RTC to power up the board again, so that the CPU could program itself a wakeup time).

    Could the built-in RTC be used for this ?  I see that all the power up/down logic is done via the onboard rtc driver anyway.  However as far as I can tell there's no way to add a 3v coin cell to power the onboard RTC, you seem to have to use a rechargeable battery like you're doing.

     

    I'd already planned to add an external rtc due to not really wanting to add a rechargeable battery, but then found the power up/down stuff being done by the onboard rtc which complicates stuff somewhat if you want to set the clock from the external one.

  • in reply to Former Member

    Ohhh I'd forgotten there was an on-board RTC. I just checked the schematic, and it looks like the VLDO1 supplies the VRTC and VIO. However, it is through a resistor to VRTC, so technically it could be possible to run a separate supply by removing the resistor.

    The datasheet only has a 'max' current consumption reported (5mA!) but on a forum some people asked. The link off that forum has a much better value of 370uA at 1.8V which seems pretty good!

    I'm wondering though, would a coin cell be better, or one of those supercap things? Normally I use a coin cell, but I'm wondering with the low voltage requirement, maybe a supercap may be easier (although bigger I guess). Or feed from the LiPo cell if it is needed for the application. Hard to know what to do :-( With the external RTC, I was expecting to write some script to query it via (say) I2C, and then set the time each time the board powered up. But an internal RTC is very cool if we can get it working.