Pi vs BeagleBone-Black

Spring greetings to you all ...  this thread has brought me out of my forum sabatical, naughty naughty.

Seeing the Slashdot thread on BeagleBone Black made me warp over to here post haste, as I guessed you would all be talking about it ... and you were, hehe.  I agree with everything that's been said.

Two additional bits of information that slightly change the picture:

• Farnell UK says "18584 will be available for delivery on 3 May, 2013", so they're clearly taking this seriously and expect BB Black to sell in much higher volumes than the first BeagleBone.  No surprise of course, price is king.
  

• The BeagleBone's TI Sitara AM3359 contains a pair of integer-only realtime processors running at 200MHz, the Programmable Realtime Unit Subsystem or "PRU".  These can provide waaaaaaay better hard realtime interfacing performance than any program running in Linux user-space, so for hardcore techies who aren't afraid of getting their hands dirty with some pretty simple assembler, the BeagleBone is lightyears ahead of the Pi in interfacing capability.

Success has very little to do with engineering merit though, so I won't be making any guesses about how popular this new board will become.  However, for myself, the Pi Model B is now totally dead in the water since it lost its only advantage, which was price.

Needless to say, BeagleBone Black is on my shopping list as soon as they're in stock.

Morgaine.

Morgaine Dinova wrote:

 

Spring greetings to you all ...  this thread has brought me out of my forum sabatical, naughty naughty.

 

Was wondering where you'd been hiding recently

• Farnell UK says "18584 will be available for delivery on 3 May, 2013", so they're clearly taking this seriously and expect BB Black to sell in much higher volumes than the first BeagleBone.  No surprise of course, price is king.
  

 

However after getting an 'in stock' notification from Newark (strange when I'm in the UK), Newark now show 0 in stock and more expected to ship on 28th June - no qty listed...

So I'm not holding my breath just yet.

Success has very little to do with engineering merit though, so I won't be making any guesses about how popular this new board will become.  However, for myself, the Pi Model B is now totally dead in the water since it lost its only advantage, which was price.

 

I'd hoped to see something like this where the price difference (in the UK anyway) is approaching zero. Regardless of the merits of each device, it'll be interesting to see what happens next.

Gary Stewart wrote:

 

Is their 280 mA with or without USB (keyboard/mouse etc.) or Ethernet connections ? Is your 410 mA with or without USB or Ethernet connections ? I pull

The SRM says their figures are with HDMI monitor, usb hub, 4G thumb drive, ethernet @100Mb, serial debug cable. I basically have Pi, ethernet, sdcard, max3232 and a few temperature sensors, no usb devices for 410mA. So a reasonably similar setup.

I'm about 310mA with the switchers and a GPS receiver for an NTP clock. As single purpose devices I don't tend to have much running on them - ntp isn't exactly processor intensive.

So I'm waiting impatiently for my BBB to arrive so I can swap out a Pi and compare it in the same environment.

The previous argument about linear LDOs was simply that they were not the best solution (some even said they were a bad engineering solution which is silly)

for  powering the Pi. There is some merit to the argument of using a switcher as far as allowing a wider selection of input voltages and efficiency goes however

given the pricing and size contraints of what it was designed for (again) there really is not much choice. It would also have required either a multi-output

switcher or the same number of LDOs (one for 3.3V and one for 1.8V) already on the Pi.

I really don't have a problem with the LDO's (and my switchers cost way too much to use on the Pi), I'm just interested in the different design compromises. Especially when the costs are so similar.

Yes time and technology marches on, but it does make you wonder that if the BBB can use a composite pmic (with some switchers and some LDO's) while being so close in cost, could the Pi have done so too ?  Or if it couldn't a year or more ago, could it do so today..

selsinork wrote:

 

Gary Stewart wrote:

 

Is their 280 mA with or without USB (keyboard/mouse etc.) or Ethernet connections ? Is your 410 mA with or without USB or Ethernet connections ? I pull

 

The SRM says their figures are with HDMI monitor, usb hub, 4G thumb drive, ethernet @100Mb, serial debug cable. I basically have Pi, ethernet, sdcard, max3232 and a few temperature sensors, no usb devices for 410mA. So a reasonably similar setup.

 

I'm about 310mA with the switchers and a GPS receiver for an NTP clock. As single purpose devices I don't tend to have much running on them - ntp isn't exactly processor intensive.

 

So I'm waiting impatiently for my BBB to arrive so I can swap out a Pi and compare it in the same environment.

 

The previous argument about linear LDOs was simply that they were not the best solution (some even said they were a bad engineering solution which is silly)

for  powering the Pi. There is some merit to the argument of using a switcher as far as allowing a wider selection of input voltages and efficiency goes however

given the pricing and size contraints of what it was designed for (again) there really is not much choice. It would also have required either a multi-output

switcher or the same number of LDOs (one for 3.3V and one for 1.8V) already on the Pi.

 

I really don't have a problem with the LDO's (and my switchers cost way too much to use on the Pi), I'm just interested in the different design compromises. Especially when the costs are so similar.

Yes time and technology marches on, but it does make you wonder that if the BBB can use a composite pmic (with some switchers and some LDO's) while being so close in cost, could the Pi have done so too ?  Or if it couldn't a year or more ago, could it do so today..

Yes the prices are close. However one of the major design considerations for the Pi was the $35 price point which they achieved. I'm sure there are more than one or two things

they would have preferred to do differently but that is how engineering works when rubber meets road. I know, I've been there a few times. Although there is a good degree of crossover

in what they both do I still feel that they are fundamentally aimed at different markets. The Pi market is much more narrowly focused. The BB Black is much more general purpose. That

probably accounts for most of the price difference. Personally I'm very excited about the BB Black.

One of the nice things RPF did do recently was to double the memory for the same price. So there is room for improvements as technology advances. It will be interesting to see

what happens to both of them (and others to come ?) over the next couple of years.

s ork wrote:

Did you catch the table in the BBB SRM showing power consumption ?   I was very interested in the Kernel Idling Display Blank figures of 280mA @ 5v, my Pi shows ~410mA in the same condition. So something is doing a better job.

BBB, with external 5V supply using the barrel connector, max3232 serial adapter and 100Mb network, no capes, sdcard, or usb devices

~230mA with kernel idle and ondemand cpu governor, cpu running at 300Mhz. Switch to performance governor, cpu at 1GHz, and ~300mA.

If anything, the figures from the SRM are worst case - I don't seem to be able to reach them without adding a good number of extras.

Maybe it's the PMIC doing an awesome job of being very efficient.  It's the same TPS65217C as used on the white BeagleBone, and the more I read about its capabilities, the more it's clear that it's quite a little star in its own right.

I suspect that the kernel isn't clever enough yet to control it dynamically through I2C, but in principle a board that uses this PMIC could be run very frugally when not all its subsystems need to be powered at the same time, and some parts put on standby.

I suspect there's several factors contributing to the better power figures. There does appear to be some communication between kernel and PMIC, as I saw a reference in some of the kernel docs that enabling pwm mode causes problems for ethernet (or was it usb, I forget) and it does appear to be used for the power button and shutdown.

I'm sure things will improve, it's still quite early in it's lifetime..

selsinork wrote:

 

I suspect there's several factors contributing to the better power figures. There does appear to be some communication between kernel and PMIC, as I saw a reference in some of the kernel docs that enabling pwm mode causes problems for ethernet (or was it usb, I forget) and it does appear to be used for the power button and shutdown.

I'm sure things will improve, it's still quite early in it's lifetime..

It is not clear from your description, were you using the BB Black as stand alone (using HDMI video) or tethered to a PC (not using HDMI video) ? If you were not that

would explain some of the difference.

Morgaine wrote:

I suspect that the kernel isn't clever enough yet to control it dynamically through I2C, ...

I'm quite sure that the kernel is clever enough since it has been handling power for years on notebooks, netbooks, smart phones, and more recently tablets. It has

been using the motherboard version of I2C (SMB) for years too so no problems there either. Whether the people who ported the kernel were clever enough is another

story but since both the Linux C and header files for using the TP65217 exits I assume they were.

Gary Stewart wrote:

 

It is not clear from your description, were you using the BB Black as stand alone (using HDMI video) or tethered to a PC (not using HDMI video) ? If you were not that

would explain some of the difference.

 

I was quite clear about what I had plugged in. Specifically so that others could duplicate the test.  Yes there will be differences, but unless both you and I have exactly the same things plugged it then the numbers can't be compared anyway. Although the SRM gives some general idea of what was connected there isn't enough detail - was their usb hub powered or not, what was the precise make and model of the thumbdrive etc.

So, for avoidance of doubt, here's some photos of what's connected along with the current reading. this is with the default angstrom build which uses the ondemand cpufreq scaling

root@beaglebone:~# cat /proc/version

Linux version 3.8.6 (koen@rrMBP) (gcc version 4.7.3 20130205 (prerelease) (Linaro GCC 4.7-2013.02-01) ) #1 SMP Sat Apr 13 09:10:52 CEST 2013

root@beaglebone:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

ondemand

root@beaglebone:~# cat /proc/cpuinfo

processor       : 0

model name      : ARMv7 Processor rev 2 (v7l)

BogoMIPS        : 297.40

Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls

CPU implementer : 0x41

CPU architecture: 7

CPU variant     : 0x3

CPU part        : 0xc08

CPU revision    : 2

Hardware        : Generic AM33XX (Flattened Device Tree)

Revision        : 0000

Serial          : 0000000000000000

Whether the people who ported the kernel were clever enough is another

story but since both the Linux C and header files for using the TP65217 exits I assume they were.

The driver exists and is in use, what it's capable of is a different question. From https://github.com/beagleboard/kernel/tree/3.9

• PMIC: working
• PMIC PWM: working, kills ethernet

so it should be clear that some of the drivers are still a work-in-progress at this point.

It appears that as of 3.9 their external patch set is much reduced. As they get more into the upstream kernel we can expect improvements and better integration with the existing power management.

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.

(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).

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.

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.

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.

shabaz wrote:

 

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.

Actually, if done properly - you'll need the i2c driver and rtc driver built into the kernel along with some devicetree magic - you can have the kernel do it all for you.

There's an option in the kernel config to select which rtc is used to set the clock. It defaults to rtc0, but needing to have both the onboard rtc driver to deal with power on/off and a driver for an external rtc is what makes stuff somewhat more complex.

shabaz wrote:

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!

No, that's actually quite poor..  The cheap Microchip MCP79410 i2c rtc I've been using states 5uA standby current with the clock running.

1.8v battery could also be rather akward as it rules out using the usual 3v coin cell without additional circuitry - datasheet says max 1.890v recommended, absolute max ov 2.1v.  There does seem to be a lot more stuff tied into VDDS_RTC which makes it that much more difficult too.

Oh, so sorry you're quite right! It's quite late! So the summary seems to be, an external RTC is most probably the way to go, because the internal one is only useful for short periods of time, plus the complications with the supply routing and the limit on the voltage.

Have you any device in mind? Are you planning on using the Microchip one that you mention? If so, I'll order the same one.

most likely will use the 79410, they're cheap, have kernel support, can operate from 1.8 to 5.5v without level shifters, and I still have some left over from R-Pi projects.

Cheap doesn't necessarily mean they'll be better or worse that anything else, reasonable accuracy is good enough for most purposes and at a third the cost of a 5v only ds1307 you can always buy a better crystal