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 39479 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..

Parents

  • 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 !

Reply

  • 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 !

Children
  • in reply to gdstew

    Gary Stewart wrote:

     

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

    One of the other boards I have some interest in is the Sabre-Lite, Freescale have a ref manual for their iMX6 that's bigger, close to 6k pages if memory serves.

    Similar omissions for the GPU and their secure boot module though.

     

    I couldn't agree more, copious documentation like these two have is the way forward and really should become the norm instead of the exception.

  • in reply to gdstew

    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.

  • in reply to morgaine

    Morgaine,

     

    A search of the TI website for SPRUH73C turns up with zero results. SPRUH73H gives me the same technical reference manual I already have. That manual has a very brief

    two page description of the PRU-ICSS but little else, not even a block diagram. According to that technical reference manual this is an upgraded version of the original so it

    may be that the documentation hasn't been released yet. I have also searched the TI website for PRU-ICSS which turns up 5 hits, all of them from entries in forums. A couple

    of the entries clearly show that more hardware information is available but no hint as to which one or where.

  • in reply to gdstew

    Gary Stewart wrote:

     

    A search of the TI website for SPRUH73C turns up with zero results. SPRUH73H gives me the same technical reference manual I already have. That manual has a very brief

    two page description of the PRU-ICSS but little else, not even a block diagram. According to that technical reference manual this is an upgraded version of the original so it

    may be that the documentation hasn't been released yet. I have also searched the TI website for PRU-ICSS which turns up 5 hits, all of them from entries in forums. A couple

    of the entries clearly show that more hardware information is available but no hint as to which one or where.

    It seems that SPRUH73 has shrunk from H to C.  I tried to find some Am335x documents and it looks like the TI site is currently screwed up.  Maybe the people who know how to fix it are all at Design West (formerly ESC).

     

    The PRUSS documentation is definitely in version C.  Maybe TI decided to put it into a separate document, but have screwed up access to that document or else it hasn't been approved for release.  You might try searching for SPRUH73C on the Internet to see if you can download it from somewhere else.

     

    It's also possible that TI decided to omit PRUSS from the Am335x TRM and make people use the wiki.  If that's true, it's too bad because the TRM is a lot better formatted and prints better.  Some PRUSS documentation has never been in the TRM, such as opcode encoding (which is in the wiki).

  • in reply to gdstew

    SPRUH73C is considered the "canonical" AM335x TRM by the BeagleBone community and a lot of people have mirrored it  --- the very first hit in Google will get you it, for example.  Documents are always in transition and the TRM is no exception, which appears to be the reason why the latest SPRUH73H has only a 2-page placeholder for that chapter.  We're only guessing and I haven't seen it confirmed yet, but I suspect the technical author just has a lot of work.  It's not like the PRU were a secret or anything, it's already been documented officially in SPRUH73C and used extensively in the community.

     

    I'm still trying to get some info on whether a forthcoming SPRUH73  'I' release will contain updated PRU info or whether we should continue using SPRUH73C from here on, but it doesn't make a huge amount of difference --- just grab SPRUH73C for now.  The BeagleBone Black's slightly upgraded AM3359 is still a AM3359 after all, and its PRU hasn't changed since the original BeagleBone was released or there would be a new datasheet for it.

     

    We have the required info available to the community already, but if the large hole in the latest SPRUH73H concerns you massively then perhaps you could ask someone who can answer authoritatively about it?  I'd be interested in the answer too.  I'd certainly prefer the latest doc to be complete, but I can't obsess about it when the BeagleBone community already has the PRU info in SPRUH73C and considers it canonical for BeagleBone ... and hence for BeagleBone Black too.

     

    Morgaine.

  • in reply to morgaine

    Found it, thanks. Weird that TI does not seem to have a copy of this document on their site. In an earlier search I googled PRU-ICSS but did not see any PDFs.

    Obviously I didn't look through enough pages.

     

    I'm not massively interested but I was thinking about using one or both of them to help with a project I have in mind so I wanted to an idea of what they were

    capable of, how many of their non-communications I/O pins were available to use on the BB Black, and how they shared data with the ARM.

  • in reply to gdstew

    The PRU is certainly a very interesting facility, and I'm looking forward to playing with it myself.  It'll be quite nostalgic to return to assembly code programming and examine a new set of instruction encodings.

     

    This is actually very topical in this Pi group, because in many threads I've been promoting the idea that the best way of using Pi for hardware interfacing is with the help of a bare metal microcontroller.  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.

     

    The two PRU cores will of course be the "bare metal microcontrollers" in our AM3359-based scenario, and we won't need a single bit of extra glue logic to achieve it.  This is certainly going to make for some very interesting projects.

     

    Morgaine.

  • in reply to morgaine

    I agree upon the idea of a bare metal microcontroller for real time behavour.

    Programming in assembly however doesn't seem an efficient way of doing things.

    It's like almost 10 years ago I used assembly, and only to create small procedures that were called from C.

    On the other hand, it will limit your design to just the beagle boards.

    Most modern microcontrollors already contain the glue logic for an usb or spi interface.

    Not needing extra hardware will reduce the hardware price of your design, but the development effort and time will be bigger.

  • in reply to Former Member

    That's true, yes.

     

    Well it wouldn't be too huge a task to port smallc to issue PASM code for the PRU, as long as totally dumb code generation is OK.  A lot of the 200MHz would be used up in overheads though, and the tradeoff may not be worth it.  I guess this would have to examined on a case by case basis.

     

    In a more "Pi-oriented" context, programming small pieces of tight code in assembler would have immense educational benefit for budding future engineers, so programmer efficiency and code maintainability would not be so high up on the list of requirements as they are in industry.  Programming the PRUs in assembler would be an effective way of exposing inquisitive minds to low level details.

     

    I could have put this kind of integrated architecture to very good use back when I was churning out EE degree students.  It provides very significant educational gains for very little staff and student pain, and EE students absolutely must understand what's going on at an instruction set level and below otherwise they'll have no hope of one day designing such hardware.  The PRU SS gets a big thumbs up from that angle.  Experience will tell how this works out in practice.

     

    Morgaine.

  • in reply to morgaine

    Morgaine Dinova wrote:

     

    The PRU is certainly a very interesting facility, and I'm looking forward to playing with it myself.  It'll be quite nostalgic to return to assembly code programming and examine a new set of instruction encodings.

     

    This is actually very topical in this Pi group, because in many threads I've been promoting the idea that the best way of using Pi for hardware interfacing is with the help of a bare metal microcontroller.  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.

     

    The two PRU cores will of course be the "bare metal microcontrollers" in our AM3359-based scenario, and we won't need a single bit of extra glue logic to achieve it.  This is certainly going to make for some very interesting projects.

     

    Morgaine.

     

    You really need to get better acquainted with real time Linux. There are many companies that use it for products and several that specialize in producing real time tools and solutions using Linux.

     

    First and foremost the "amount" of real time needed is very application dependent. Real time versions of Linux are able to handle latency requirements below 100 uS. This puts a wide range of hard

      and soft real time applications within its reach and it is quite capable of handling them.