Probably UART, the same way the FTDI chip in new UNOs talks to the AVR. In any case, the reason having an ARM cpu w/ an AVR is beneficial is because you get the linux environment but real-time hardware GPIO access. This is far better than the software scheduling that bogs down RPis and makes it very difficult to do timing intensive tasks.

Except that the SoC they're using already has two PRU coprocessors designed for realtime IO support, and they have the advantage of being able to DMA to and from main memory rather than being limited to a slow serial link to the main CPU.

Arduino's appeal is that doing simple tasks is simple. The PRU is not easy. TI introduced a C compiler for the PRU last year, but until then it has been an assembly only affair. (I haven't tried the compiler, I just discovered it while fact checking the first draft of this comment.)

One wonders why they didn't combine the due and the beagle bone - it would have only simplified things.

Could it be that there are incompatibility issues between it and the older arduino ?

Probably because the BBB can't really handle realtime applications - in its default form it's running Debian Linux these days.

The microcontroller can take care of the realtime interaction, while letting the ARM processor running Linux handle the higher level logic.

Of course, it's easy to debate how much your average Microcontroller project really requires a dedicated realtime processor, but that's neither here nor there.

Running a strand of WS2812 LEDs is a pretty common starter project and requires real-time. The BBB does support this through the PRU, but it's a lot more complicated than just using an Arduino with the library.

Actually the SAM3X8E does not have an FPU.

Ouch. You're right.