Is there a reason that the BeagleBoards run Linux? Is there a certain advantage to doing so?
If Linux is used to host the Beagleboard units, what analog does the Arduino use?
I am working on a project for a competition in which I will implement a communication system as well as attitude calculation and data processing in the form of images and various sensors. Similar projects have used the Beagleboards. I have been trying to figure out why they may have done so versus a standard AVR or PIC micro controller, for example.
Best Answer
The BeagleBone and BeagleBone Black ARM processors, which are classified as System-on-a-Chip, have a much higher clock rate and much greater processing power than any microcontroller, including 3D graphics accelerators as well as support for the NEON SIMD instruction set. So they are capable of much more complex image processing tasks in real-time.
The BeagleBoard goes far beyond even that, because its OMAP is heterogenous multiprocessing with a C64xx DSP core on the chip along with the ARM core.
The price you pay for that processing power, as well as communication peripherals including Ethernet and USB, is a lot of additional complexity. Using a full-featured OS like Linux gets you configuration of all that capability for free. However, it's configured the way somebody else thought it should be done. Your code then shares the processor with the OS, with the result that you don't have easy mechanisms for direct hardware access or deterministic timing.
PICs and AVRs typically don't use an OS that boots first, configures the peripherals, and then load your code. Instead, they ship with libraries to make it easier for you to configure the peripherals. This inverts control between the vendor software and yours -- With linux, your software runs when the kernel asks it to. With PIC / AVR / etc, the vendor libraries run when your software asks them to.
You can get scheduler libraries for PIC/AVR/etc which allow you to run multiple tasks and switch between them like Linux processes, but although these libraries are sometimes called OSes, IMO they don't deserve that name. And with no memory management unit, you can't get process separation at all.
There's quite a different level of abstraction too. In summary, in bare metal programming (with or without an abstraction layer), you're manipulating hardware -- interrupts and registers. With an OS like Linux, you're manipulating data buffers, and the drivers will get those buffers to and from the hardware sometime, usually sooner, but almost never with any exact timing. Of course the peripheral will probably use very strict timing as it processes that buffer. But if you want to synchronize actions of different peripherals, the OS is going to really get in your way.