Raspberry Pi or Beagle Board!!??

@ Baba,

You have provided your own peronal definition of hard real time - can you back it up with any references ?

To back up my own comments:

Hard real-time systems are ones in which correctness depends on execution

occurring within a fi xed period of time [GR04]. Surprisingly, most previous re-

search in runtime monitoring focuses either on non real-time programs or soft

real-time systems, in which occasionally missing deadlines is tolerated.

(from a paper presented at International Conference on Runtime Verification 2010)

Hard or softness of real time is not a measure of the importance of systme failure.

Michael Kellett

In my experience, the term "real time" is relative.

If your requirements have a specific time response number, then that becomes your real time event to design to.

If you cannot measure the response, then it is not real time.

After you establish your real time event, you have to do a criticality/risk assessment as to the effect of missing the defined response time.  In either case, you have to have a strategy for dealing with the lost event, should it occur.

In systems engineering, we had to go through every system event until we could show that the system reached a specific level of survivability for a specific cost.  It was only after that analysis  that the system functions were allocated between hardware and software.  When software was not fast enough, you go to a hardware solution.  It may not be the most versatile, but it can usually meet any realtime constraint.

The same goes for selecting the computer processor.  You have to pick one that when combined with the software has enough capability to meet the requirements allocated to it.  In advanced applications, you often are limited in your candidates to select from, so you need to understand your choice in very great detail.

Now back to the topic, the selection between PI and BeagleBone depends upon your requirements.

If both satisfy your requirements, then you look at the expense of the development environment.  Sometimes the cheaper processor carries the highest cost to develop.  The worst thing you can do is try to pit one against the other without a defined set of requirements.

Thats the truth for all processor selections.  It is more than just selecting the board.  You have to look at the bigger picture of your intended application and understand that whichever one you choose, it will be obsolete before it gets delivered.

I hope I have added enough confusion to the original question, but I have worked on many state of the art realtime systems.  If you do not fully understand your requirements, you will fail. 

I successfully implemented a lot of systems in applications where people said that you could not do the job in software.  The requirements are the key.  Understand them and you will be successful.  Ignore them and you will fail.

As stated by the gospel of DAB.

Just my opinion.

DAB

There's going to be an Open Source Hardware Panel Discussion at the upcoming DesignWest show in San Jose, California starring Jason Kridner (BeagleBoards) and Gert Van Loo (Raspberry Pi / Gertboard).  I sure hope it devolves into a Pi fight about whether RasPi is Open Source Hardware (oh yeah?  Let's see the Gerbers!  Tell me where I can get a BCM2835 in small quantities -- with a full tech ref!) and whether Open Source Hardware is a Good Idea (oh yeah? If OSH is so great, how come RasPi has sold 1M in one year and BBs have only sold 100K in 4.5?  huh?  huh?)

Actually, I doubt it'll be that much fun, but should be informative.  12 Noon PDT, 23 April 2013.  Expo Theatre shows are included in the free (as in beer) expo pass.

darn it, now I need to figure out how to get out to California because that looks very interesting!

Note that the BeagleBone has 2 200MHz 32-bit RISC microcontrollers (programmable real-time units or PRUs) that can be programmed with an open source assembler to perform real-time tasks.  The typical approach on Raspberry Pi to handle low latency is to add an Arduino.  That's also been the popular approach on BeagleBone until somewhat recently with a lot more activity with 3D printers using the PRUs.  http://github.com/beagleboard/am335x_pru_package.

I am also looking to make a choise. With Arduino you have everything under control and probably the best real time response as there is no OS involved. With both the PI and the Beaglebone the OS stays alive and as far as I can see the overhead of the OS is not verry deterministic. On the otherhand quit often you need to stay in touch with the world and both the PI and the Beagle Bone can help you in that area. I like the idea of the coporcessors on the Beagle Bone but I am not looking forward of programming them in assembler. (I hate it and I did some assembler and even witing micro code in my younger years.). I can live with for instance an Arduino as coprocessors. Did someone write communication software for this purpose either for the PI or for the Beagle Bone?

I believe this is an example of writing C code for the BeagleBone's PRU (embedded microcontroller):

http://elinux.org/ECE497_BeagleBone_PRU

For communicating with an Arduino, OpenROV is an example of Arduino + BeagleBone:

https://github.com/OpenROV/openrov-software

For Raspberry Pi and Arduino, check out simon.monk

http://www.raspberrypi.org/archives/1171

Drew,

    It's not clear to me what they are doing regarding programming the BeagleBone's PRU in C,

because the docs clearly state "PRU's are programmed in assembly."

http://elinux.org/Ti_AM33XX_PRUSSv2

So I guess the eLinux ECE497 doc describes using memory mapping to accecss the PRU:

http://elinux.org/ECE497_BeagleBone_PRU#How_the_C_Code_Works

But it does seem like the actual instructions run on the PRU are assembly.

I found the github repo for the blinker demo: https://github.com/millerap/AM335x_PRU_BeagleBone/tree/master/GPIO_PWM_PRU

Drew Fustini wrote:

 

So I guess the eLinux ECE497 doc describes using memory mapping to accecss the PRU:

 

http://elinux.org/ECE497_BeagleBone_PRU#How_the_C_Code_Works

 

But it does seem like the actual instructions run on the PRU are assembly.

 

I found the github repo for the blinker demo: https://github.com/millerap/AM335x_PRU_BeagleBone/tree/master/GPIO_PWM_PRU

Yeah, today's PRU code is written in assembly. There have been experiements with writing a C compiler for it and we'll have to see if those see the light of day.

I find following the Replicape project (https://bitbucket.org/intelligentagent/replicape) to be informative on PRU development.  He's done a loader in Python that helps communication to the PRUs: https://bitbucket.org/intelligentagent/pypruss.  In one of his examples, he shows toggling a GPIO with at 15ns duty cycle, though I think that 3rd cycle could be trimmed.