Pi vs BeagleBone-Black

Systems that require hard real time behavour usually also require high reliability. If I instruct my robotarm to move to coordinate x, y, I appreciate it if he actually stops at that position all the time. One way to obtain high reliability is to keep things as simple as possible which is exactly what a separate controller approach is standing for. The more complex a design, the bigger the possibillities that it contains bugs.

I know there are other cases. Nobody is saying embedded linux and posix isn't having a place on the market, but it simply isn't a swiss knife for evey real time embedded design.

If we would be discussing this on a meeting, I would say "it's about time to move to the next point on the agenda. We are diverting way to far from the original topic"

Maybe our real time response is simply 2 slow.

Systems that require hard real time behavour usually also require high reliability. If I instruct my robotarm to move to coordinate x, y, I appreciate it if he actually stops at that position all the time. One way to obtain high reliability is to keep things as simple as possible which is exactly what a separate controller approach is standing for. The more complex a design, the bigger the possibillities that it contains bugs.

I know there are other cases. Nobody is saying embedded linux and posix isn't having a place on the market, but it simply isn't a swiss knife for evey real time embedded design.

If we would be discussing this on a meeting, I would say "it's about time to move to the next point on the agenda. We are diverting way to far from the original topic"

Maybe our real time response is simply 2 slow.

Incidently, (just to have some concrete references for anyone curious to explore that path, although I agree it's a slight digression now, not really discussing the beagleboard specifically), there are some RTOSs that have so-called 'low' latency, even the extremely common uC/OS (I think the code is free - otherwise is available with the author's book) manages tens of usec with (say) a 16MHz clock. Probably nothing stopping people from porting it to this processor, although I'm personally not interested. Another commercial example is EOS (a very old operating system developed by Etnoteam, Italy. It is multitasking and can support real time applications. Versions were available for the Intel 8086 and old Motorola devices. The basic version occupies approximately 4kbytes of ROM, but this rises to tens of kb for the complete system.It was modular and was intended for a variety of applications). I found this report of its performance on an ancient ARMv3 running at 25MHz (scheduling/context switch time is fairly low). But, even tens of usec is useless for many tasks like the robot arm example.

There were other RTOSs with this ballpark of latency. Another example is Hitachi's HI8 which achieved good results on another ancient processor (H8/500 series, this is from late 1980s, so very old (one can assume the CPU speed was below 16MHz):

Also, agree POSIX compliance is not always required, and is not relevant to small processors like the one on the beagleboard, where you want to write some tight code anyway. For example, Japan had it's own standards for smaller processors. It is generally accepted that some form of process synchronization is needed, scheduling methods, memory management and so on, but all the systems mentioned above implemented these features. POSIX is not always necessary because one may never want to port to another device, or, more commonly, people don't directly use the APIs anyway because often, some higher-level framework is created to abstract away from the raw API, to protect oneself, or to have object-oriented framework possibly, and write better code too.

It's a digression, but useful to know about the choices for the small processors.

Having said all that, if I wanted to interface to any hardware (most hardware) that requires reasonable timing, I too wouldn't be interested in running Linux nor any OS for high/average-speed tasks (coding with interrupts is perfect for many use-cases), nor real-time Linux; I would use Linux for tasks that I don't mind to have more latency (e.g. UI update) or where it's too hard to re-write vast libraries of code that already exists on Linux.

So, for me, I'm looking forward to trying the board, because I don't like bringing out ISE and having to prototype a board just to have some (averagely)high-speed processing going on with external hardware.