Pi vs BeagleBone-Black

If finding a cubieboard is a problem, you could take a look on Ebay at the Mele A1000 media player. It's pretty much a cubieboard without the gpio lines. It will cost more than a Pi, but it comes with a supply and a housing. It also has a vga output and connector fitted. It has wifi and ethernet embedded if I remember well. There even is the Mele A2000G with 1Gig of ram.

For GPIO, I prefer to use a dedicated microcontroller connected to the linux board with an usb interface. This approach might be a bit more expensive, but it makes it possible to switch from one linux board to another without much hassle. It also makes the system responsive to io changes after a fraction of a second instead of several seconds needed to boot the system. Maybe it's just me being conservative and used to embedded design on 8 bit microcontrollers. Linux adds connectivity to it and makes easy in system programming possible.

The Mele also uses the allwinner A10 soc, so booting linux is possible from the sd card. Placing it on the internal flash memory of the player should be possible as well.

Luc Cool wrote:

 

If finding a cubieboard is a problem, you could take a look on Ebay at the Mele A1000 media player. It's pretty much a cubieboard without the gpio lines.

At least for me, it's the GPIO that makes or breaks the device, without them I'm much less interested.

It will cost more than a Pi,

Approx 60 GBP, so around twice what the Pi costs. Sure it's not a straight comparison.

The A10 looks like it should be a good SoC and so far the cubieboard looks to be the closest to the sort of board I'm interested in. The danger, as always, is that something better and cheaper may come along by the time they start appearing in volume.

Either way, interesting times, and I'm really hoping we'll see more and more devices of this type.

What the raspberry pi foundation lying ?

Who would have thunk it ?

Actualy its ridiculous, they want everyone to think its an open hardware project despite the fact that you cannot buy the processsor unless you sell your soul to Broadcomm.

and wow they are going to release the gerbers, big deal, Ive got the schematic I could do my own layout if I wanted, only trouble is......its not open hardware and you cannot buy the processor.

Seriously stay away from the raspberry pi, it started life as an educational toy, got hijacked by some very strange people who think every embedded system has to run linux and several of my clients have tried to use it as the basis of their projects only to regret it.

The article in wired was pretty tyipcal of how they work, don't talk to engineers who have any experience of designing embedded systems, talk to jouralists who have not the slightest idea and they will repeat any bullshit you tell them if you take them to lunch.

Frippy Frippy wrote:

 

got hijacked by some very strange people who think every embedded system has to run linux

Lots of embedded devices do run linux (certainly not all), but what they run doesn't tend to resemble Debian, RedHat or any other 'full fat' distros.  It's my opinion that trying to force a full desktop distro onto the Pi was a mistake, it simply doesn't have the resources to handle all the crap in todays bloated distros.

Still, it had to run something. Whatever they put on it couldn't be too alien to their supposed educational audience either. Seeing them try to put VxWorks or Windows onto it might have been entertaining, but I suspect they wouldn't have sold as many as they have.  What OS would you have chosen ?

several of my clients have tried to use it as the basis of their projects only to regret it.

I've built a few things around the Pi and while I don't know that I'd go so far as to say I regret it, suffice to say that some other, incomplete, projects are being reworked to use the BBB instead.

Frippy Frippy wrote:

 

got hijacked by some very strange people who think every embedded system has to run linux

Lots of embedded devices do run linux (certainly not all), but what they run doesn't tend to resemble Debian, RedHat or any other 'full fat' distros.  It's my opinion that trying to force a full desktop distro onto the Pi was a mistake, it simply doesn't have the resources to handle all the crap in todays bloated distros.

Still, it had to run something. Whatever they put on it couldn't be too alien to their supposed educational audience either. Seeing them try to put VxWorks or Windows onto it might have been entertaining, but I suspect they wouldn't have sold as many as they have.  What OS would you have chosen ?

several of my clients have tried to use it as the basis of their projects only to regret it.

I've built a few things around the Pi and while I don't know that I'd go so far as to say I regret it, suffice to say that some other, incomplete, projects are being reworked to use the BBB instead.

I noticed that they were advertising for a senior hardware guy recently, not exactly the job where you are going to be overloaded with projects given their stated position that changes to the hardware are going to scare off the user base.

But yes it is difficult because your supposed education user base isnt going to be too keen on bare metal, but bare metal is what you need to teach if you are going to produce embedded engineers rather than software guys who  write C++ drivers for 8 bit processors or cannot write a driver for an RS232 port without it spilling bits all over the floor as I found recently.Embedded systems design is difficult and is quite different to normal software design, but teaching would be embedded systems engineers that its all the same isnt doing anyone any good.

selsinork wrote:

 

Still, it had to run something.

BBB is one of the few ARM boards that can run a Linux distro to provide almost instant gratification to the *nix legions and at the same time offer very tight realtime response through its PRUs.  A dedicated RTOS wouldn't provide that instant gratification except to its  small community of adherents.

This *nix host + RTcores approach seems to be the best of all worlds for embedded work.  There probably isn't an RTOS in existence that offers the breadth of languages, networking, UIs, APIs, and other facilities provided by Linux, and yet BBB can still be made to behave as tightly as a microcontroller.

IMO, every SoC used for top-end embedding should provide something along these lines.  And before somebody answers "RT Linux", no, just no.  Use hardware, don't compromise.  A little RISC core requires very few gates to implement, an insignificant number compared to the gatecount on the entire SoC.

Morgaine Dinova wrote:

 

BBB is one of the few ARM boards that can run a Linux distro to provide almost instant gratification to the *nix legions and at the same time offer very tight realtime response through its PRUs. 

...

 

IMO, every SoC used for top-end embedding should provide something along these lines.  And before somebody answers "RT Linux", no, just no.  Use hardware, don't compromise.  A little RISC core requires very few gates to implement, an insignificant number compared to the gatecount on the entire SoC.

Hi Morgaine,

That's spot on. I really hope TI focus in this area and come up with even more powerful PRUs as time progresses of course (although the current ones are pretty amazing!), but also equally importantly have lots of documented examples of the types of things one can do with them (for example, currently I'm struggling with getting high-speed input in the GPIO mode (not GPI mode) via the PRU simply because of a lack of examples - whereas high speed output is well understood now. I know the PRU is capable, it just needs some more understanding. I can't really complain since at least the documentation is intensive - just needs a few examples code.

Also, in future revisions it should be extended to allow the ultra high-speed (i.e. GPI and GPO modes) on even more pins.In terms of instruction set, it is already excellent, it has a rich set of registers and no restrictions on what registers get manipulated with what instructions. Also, recently the PRU documentation was updated - apparently there is MAC capability too! - for fast FFT type calculations, plus additional register banks. (see here - plus debugger information from Michael Haberler is there too).

@Morgaine

A few problems you forgot to mention:

1) Real time programming and real time program debugging in assembly language is a real pain. Any idea of "almost instant gratification" is not being realistic and it assumes that the

     person can actually program in assembly in the first place which is already highly unlikely and getting more unlikely every year. You actually need to know and understand the

     underlying hardware well to do this effectively and the PRUs are not simple hardware.

2) The resources available to the PRUs in terms of code (8 KB that's only 2 K instructions, see 3 below), and data RAM (8 KB with another 12 KB shared between the PRUs) is extremely

     limited.

3) It uses only 32 bit instructions which increases code size and further limits what a PRU can do with its limited code space. This is the reason for the 16 bit Thumb instruction set used

     in ARM CPUs.

4) Given the resources avaiable you are at best talking about a process scheduler with a small queue, event handler, and some timer functions. This is about as primitive an "RTOS" as it gets.

There are probably a few more but I've already wasted too much time pointing out the obvious.

And before somebody answers "RT Linux", no, just no. Use hardware, don't compromise.

But compromise and knowing how to make the right compromises is what real world engineering is all about. As you already know, but apparently fail (or as far as I can tell don't even attempt to)

comprehend, it totally depends on what level of real time you need in terms of response times and what resources the real time application requires as far as code and data space goes. Very tight

real time response is not always needed so why would you waste hardware (and money) to get something you don't need ? Your one size "use hardware, don't compromise" fits all is the epitome

of bad engineering. Sometimes RT Linux will work, sometimes it won't. Why, in the face of lots of evidence to the contrary (it's being used every day in real world research and commercial applications,

even NASA uses it) do you keep insisting that it won't ?

And by the way, all RTOS's that I am aware of already run on hardware, no compromise needed for that.

Gary Stewart wrote:

 

1) Real time programming and real time program debugging in assembly language is a real pain. Any idea of "almost instant gratification" is not being realistic and it assumes that the

     person can actually program in assembly in the first place which is already highly unlikely and getting more unlikely every year. You actually need to know and understand the

     underlying hardware well to do this effectively and the PRUs are not simple hardware.

I think you misread what I wrote.  The "instant gratification" referred to the use of Linux on the host application processor, not to the programming of its embedded cores.  Assembly language and realtime programming both require detailed understanding of what you're doing, so for that part of the job there are no shortcuts.  However, when the rest of the applications processor is running Linux, everything else you do becomes easy, and the embedded realtime core can make use of powerful and easily testable services it couldn't dream of harnessing otherwise.  That's the instant gratification part, the Linux part.

2) The resources available to the PRUs in terms of code (8 KB that's only 2 K instructions, see 3 below), and data RAM (8 KB with another 12 KB shared between the PRUs) is extremely

     limited.

3) It uses only 32 bit instructions which increases code size and further limits what a PRU can do with its limited code space. This is the reason for the 16 bit Thumb instruction set used

     in ARM CPUs.

4) Given the resources avaiable you are at best talking about a process scheduler with a small queue, event handler, and some timer functions. This is about as primitive an "RTOS" as it gets.

 

Sure, the PRUs are very restricted, but then they don't need to do much when the host is a full Linux, just handle input and close the loop with low-latency output in response, then pass a message to the host for the non-realtime part of the operation.  Doing any complex work on the PRUs is missing the point of there being an application processor available to work in tandem.  It would be a mistake even if the PRUs were large and as fast as the ARM.

As you already know, but apparently fail (or as far as I can tell don't even attempt to)

comprehend ...

 

[the rest, all irrelevant as it slides downhill into a typical Stewart rant interlaced with attacks]

You failed, completely, 1) to read what I wrote about "instant gratification", 2) to understand how PRUs are best used and instead are looking for a full RTOS, 3) to understand how poor the realtime behavior of realtime Linux is (we've had that discussion before and repeating it is pointless because you insisted on making an erroneous conclusion from known facts), and 4) you also fail by turning every engineering discussion into a personalized argument.

It is always you who takes that first step, and I do not turn the other cheek.  You fail utterly, I reciprocate.  (Is this what you're looking for?)

We're never going to  be able to hold a sensible engineering discussion if you always insist on personalizing your comments into attacks.  Make your choice next time.  Either technology, or brickbats.  They don't mix, they derail.

Link to benefit people if they want to read Stewart's opinion on RTOSs - and other's opinions.

The fact that timing can be engineered down to 5nsec for critical timing with the PRU means that all of a suddent things like controlling custom displays and stepper motors while running Linux become possible on a single chip. RTLinux could not have done that. I'm talking about events of the order of tens of nanosec, because that's the space where lots of modern hardware operates.

I think it's clear to see by simple google that many people are finding real-world use-cases for the high-speed that small processors like PRU offers in conjunction with Linux applications. I think people who try it will really adopt this method. So, possibly times have changed. Also, that was clear tens of years ago, when other RTOS's attempted at reducing latency down to tens of usec speed levels for the processors at that time.

To summarize, for anyone who wants to be able to control signals at high speed (i.e. MHz, tens of MHZ approaching 100MHz), and even down to tens of kHz, while maintaining the benefits of being able to use Linux apps and existing libraries of code, it is highly worth considering the PRU i.e. separate core method - which integrates nicely with the application processor. With the RPI, a CPLD or add-on microcontroller is a suitable method.

@Morgaine

The "instant gratification" referred to the use of Linux on the host application processor, not to the programming of its embedded cores

Must have been the at the same time part. As you yourself explain they must be programmed to use them with the "instant gratification" Linux part. And the "instant gratification" Linux part must be

programmed too. None of this programming happens in an instant.

I wrote:

Very tight real time response is not always needed so why would you waste hardware (and money) to get something you don't need ? Your one size "use hardware, don't compromise" fits all is the epitome

of bad engineering. Sometimes RT Linux will work, sometimes it won't. Why, in the face of lots of evidence to the contrary (it's being used every day in real world research and commercial applications,

even NASA uses it) do you keep insisting that it won't ?

No rant or irrelevancy here, just facts. Why won't you answer the questions (rhetorical) ? There was only one "attack" and it was on your failure on several occasions past and present to simply acknowledge that

there are applications where RT Linux does work instead of "just say no". As always when you get questions you would rather not answer your response is to attack the message and the messanger. Fine.

@ shabaz

I wrote:

Sometimes RT Linux will work, sometimes it won't.

This is not an opinion and I have always framed my arguments around that. You always respond with cases where it won't. They do not in any way negate cases where it will.

 

Gary Stewart wrote:

 

This is not an opinion

I didn't say it was. I said the link was to your opinion - and in fact your first sentence at that link is

"You really need to get better acquainted with real time Linux." - That's your opinion.

Gary Stewart wrote:

 

You always respond with cases where it won't. They do not in any way negate cases where it will.

I think you're right; because these are precisely the cases I'm hitting. If you're hitting cases that you can solve with 100usec latency, then this is great too.