ARM vs AVR8: yes, thats a stuff for another thread.
but let me say a few words to ARM-Boards: these ARM MCUs are a hell faster than the ATMega2560. but are they better suited for our application on the multidisplay pcb?
We want data acquisition at a constant frequency (for example 12Hz) and need also some advanced hardware features like input capture interrupts.
btw: Data acqusition at defined time intervals is a sort of real-time computing (RTC).
Its much easier to implement this on a dedicated mcu where I'm responsible (and in control) of the complete running firmware.
An ARM board (raspi, cubietruck etc) has a lot more computing power but it runs a full bloat operation system and is therefore not as predictable as the ATMega which is 100% under my control.
Imagine what happens under high system load on an operating system: maybe the linux kernel is busy with memory swapping and therefore the multidisplay process wouldnt get processor time even though it its needed at this point because we want to acquire our data at a constant rate.
Yes, there are some possibilities like RT-Linux to handle such realtime tasks. But it would be a hell more complex than running dedicated firmware on a simple MCU which is controlled 100% by our firmware.
In my opinion, the low-level data acquisition should always be done on a dedicated ATMega.
An ARM board could be an extension to the ATMega instead of a replacement.
btw: ARM extension is already in use: the android smartphone. it handles the visualization and data storage (mUI app).
If we're talking about an in-car graphical OLED / TFT display (i.e. dashboard) with expensive animations the mUI app could be moved from the smartphone to an in-car raspberry pi or similiar ARM board.