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.

shabaz wrote:

 

"100 uS will work for a wide range of real time applications"

 

In many cases, perhaps you really should be looking at additional

hardware to offload this and if required, a simple executive or maybe go completely

bare metal (or FPGA!).

 

You can achieve 20-50usec latency or less even with (say) 16MHz clock speed ancient

CPU targetted OS's, so 100usec with Linux =  not so amazing latency figure to use as an example.

 

Let's say you want to implement and test a new motor control algorithm for a

DC motor - the 100usec latency you quoted won't help, wherease 20usec becomes actually quite useful.

This is hardly an exotic example that I have chosen.

In many cases, perhaps you really should be looking at additional

hardware to offload this and if required, a simple executive or maybe go completely

bare metal (or FPGA!).

Again, thanks for pointing out the obvious.

You can achieve 20-50usec latency or less even with (say) 16MHz clock speed ancient

CPU targetted OS's, so 100usec with Linux =  not so amazing latency figure to use as an example.

I'd have to see a (say) real example of this because as far as I can tell you are (say) just guessing. I doubt that the (say) 16 MHz processor  would

be capable of running more than a couple of very simple tasks and certainly not enough for the motor control application you speak of and still manage

the 20 - 50 uS latency requirement. There is more to real time than just latency requirements, you have to be able to get the work done in time especially

if you are talking about hard real time. The only reason I bring this up is because you keep throwing straw men at me and I don't have time to respond to

endless "what ifs" from you. You  use the tool that is appropriate for what you want to do but some people on this forum do not know enough about real

time Linux to know how able it is (or is not) to do what they want to do. I am trying to nudge them into exploring this for themselves, not argue with

someone about the finer points of what is or is not needed for any particular RTOS application.

Nobody said anything about amazing, quit putting words in my mouth.

Let's say you want to implement and test a new motor control algorithm for a

DC motor - the 100usec latency you quoted won't help, wherease 20usec becomes actually quite useful.

This is hardly an exotic example that I have chosen.

Completely depends on the speed of the motor which also falls into "very application dependent". In fact there are real world applications

where real time Linux is used for motor control so you're right its not very exotic, or very useful as an example.

Again, and for the last time I would be very surprised if the number of real time applications needing 20-50 uS latency is not greatly outnumbered

by the applications that don't. If you do not need ultra rapid response, and you do need a full fledged POSIX compliant real time API and have the

resources to support or need more than just a bare bones RTOS then real time Linux is something you should look into.

Got it ?

Luc Cool wrote:

 

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.

My understanding of PRUSS is that it's very much like the hidden RISC processor in Freescale's (formerly Motorola's) QUICC SoCs.  QUICC implements serial protocols such as HDLC, Async HDLC, and ATM using either ROM microcode or downloadable microcode.  The huge difference is that PRUSS is an open architecture so you can program it for whatever you want (within its memory limitiations) rather than depending on "binary blobs".  While I haven't looked closely at PRUSS, it may be that it's hard to write a C compiler that would use it efficiently.  Or it may simply be that given the number of actual PRUSS programmers it's not worth the effort because the compiler would be too expensive.  This was the case for a long time with TI DSPs.  I once did an image processing application for a TMS320C40 and by extreme cleverness got a factor of 6 improvement over the C compiler by rewriting the compiler-generated ASM.  I don't know how well they do now, but each time pipelines get longer it gets harder for a compiler to do an optimal job.

Michael Kellett wrote:

 

I'll chip in my 2p worth at this point - I think the PRU is better imagined as a cross between DMA and a co-processor - it's much more tightly linked to the ARM core than an external processor could ever be and it's quite possible to imagine latency (if that's the right word with PRUs) down in the 10s of nS - ie two or three orders faster than a real time Linux or similar OS.

 

The reason there are two is that you don't really expect them to multi task.

 

I am a bit worried that TI are having cold feet about supporting user coding of the PRU - but I'm hoping that they'll stick with it because it seems me to offer quite a lot of the benefit of Xilinx's Xynq architecture but with a much easier entry.

 

MK

The main purpose of the PRUs is to provide support for industrial real time communications protocols. Luckily they decided not to limit them to that purpose. On the BB Black I count about

15 I/O pins (really hard to be sure due to the massive multiplexing of some of the chips I/O pins) that are connected to the PRUs and available on BB Black connectors. As always the number

actually available for use depends on what other things you are using the I/O for. As an example you will lose 8 - 12 of them if you want to use the 16 bit LCD interface. And there is only one

group of 8 sequential bits available which also happen to be in that 16 bit LCD interface.

On the software side I am also worried about software support from TI. They have said that they would release the assembler for public use at the end of this month, but they have already put

it off once before. I would also like to know if there are any assembly library functions to implement at least a rudimentary RTOS API available for use by the public. Given the status of the

assembler itself at this time I assume the answer is no.

Robert Olson wrote:

 

Do you have a recommendation for a real-time linux that works on the Pi?

At this time I do not know of any real-time distributions specifically made for the Raspberry Pi which somewhat surprises me. I have just begun to contemplate building one myself but I do not

know if or where I will find the time. First I need to check out http://www.xenomai.org to see how much effort it will take. I do know that real-time versions of Linux exists for ARM processors.

Gary Stewart wrote:

 

The main purpose of the PRUs is to provide support for industrial real time communications protocols. Luckily they decided not to limit them to that purpose.

 

...

 

I would also like to know if there are any assembly library functions to implement at least a rudimentary RTOS API available for use by the public. Given the status of the

assembler itself at this time I assume the answer is no.

I don't know how much RTOS you can fit into a PRU Core, which has only 8KB of program memory (2K instructions).

You're right about the comm protocols.  An obvious application for PRUSS is some of the strange SCADA protocols used by some legacy units -- things like async with 32-bit words.  It's a PITA to implement some of these protocols in the main CPU, so PRUSS is a very attractive way to do it.

John Beetem wrote:

 

Gary Stewart wrote:

 

The main purpose of the PRUs is to provide support for industrial real time communications protocols. Luckily they decided not to limit them to that purpose.

 

...

 

I would also like to know if there are any assembly library functions to implement at least a rudimentary RTOS API available for use by the public. Given the status of the

assembler itself at this time I assume the answer is no.

I don't know how much RTOS you can fit into a PRU Core, which has only 8KB of program memory (2K instructions).

 

You're right about the comm protocols.  An obvious application for PRUSS is some of the strange SCADA protocols used by some legacy units -- things like async with 32-bit words.  It's a PITA to implement some of these protocols in the main CPU, so PRUSS is a very attractive way to do it.

I don't know how much RTOS you can fit into a PRU Core, which has only 8KB of program memory (2K instructions).

Yea, I know. I was hoping that would be covered under rudimentary. How about very rudimentary ? They have to use something for the communications processing to handle the

real time aspects but you're right it can't be much.

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.

shabaz wrote:

 

You can achieve 20-50usec latency or less even with (say) 16MHz clock speed ancient

CPU targetted OS's, so 100usec with Linux =  not so amazing latency figure to use as an example.

 

Let's say you want to implement and test a new motor control algorithm for a

DC motor - the 100usec latency you quoted won't help, wherease 20usec becomes actually quite useful.

This is hardly an exotic example that I have chosen.

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

Here's an interesting quantitive study comparing the performance of ordinary SuSE with realtime SuSE.  It highlights well how the realtime version can eliminate the very bad outliers beyond 400us, yet does nothing for response jitter which is still very noisy without the outlier spikes.  It also shows how the average response latency is increased in the realtime kernel compared to the average of a normal kernel's non-outlier responses.  It's just the high latency outliers caused by scheduler task switching that the realtime kernel eliminates.

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.

Full operating systems can rarely achieve such high-quality realtime behavior, and realtime Linux certainly doesn't, whereas even a 50-cent microcontroller does it with ease.  The way to go is pretty clear if one's realtime application has any kind of strong realtime requirement.

Morgaine.

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.

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.

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.