Zbych wrote:

> Możesz mi wyjaśnić jak rdzeń ARM cię uratuje przed błędami w
> peryferiach, dokumentacji (np. ADC)?

Żaden, bo nie w tym rzecz. Przechodząc z ARMa do ARMa
wystarczy przeczytać opis peryferiów i erratę, a nie mozolnie
poznawać nowe światy. Znajomość architektury mi zostaje, kompilator
mi zostaje, być może nawet całe środowisko programistyczne
i narzędzia sprzętowe mi zostają. A teraz sobie to porównaj
z kosztem wejścia np. w SHARCa, bo tego typu krok rozważa
sundayman. Jak ma rzeczywiste powody, to czemu nie, ale
powątpiewam, bo by nie pytał...

> Przy takim podejściu tym bardziej nie rozumiem polecania dużych ARMów
> (np. Cortexów-A) tam gdzie ich moc obliczeniowa nie jest potrzebna.

Wrong. Ja nie polecam dużych ARMów (ani jakichkolwiek ARMów),
by pławić się w ich nadmiarowej i zbędnej w danym zastosowaniu
mocy obliczeniowej, tylko dlatego, że:

a) albo ten ARM już tam jest, bo krzem wybierasz z innych
przyczyn, więc wyboru nie masz (Zynq ze swoimi rdzeniami
klasy A albo PSOC5LP z rdzeniami M3);

b) albo zdajesz sobie sprawę, że przylutowanie STM32 w obudowie
TQFP64 jest dokładnie tak samo trudne, jak przylutowanie Atmela
w obudowie TQFP64, cena niewiele niższa, a konieczność "bohaterskiego
rozwiązywania problemów nieznanych w innych ustrojach" magicznie znika.
I wreszcie sobie możesz stosunkowo prosto zrobić porządny detektor zera
oparty na PLL, a nie "sprytnie" doczyszczać na AVRku wyjście jakiegoś
transoptora, uzyskując jakość i stabilność rozwiązania tam po prostu
niedostępną.

> Zaraz się zacznie ból głowy z Linuksem

Jakim Linuksem? Programuję wyłącznie "golasy".

> jak zrobić hard real-time

No na pewno nie na procesorze, co pokazują lata doświadczeń ludzkości.
Dokładnie od tego masz FPGA i dlatego wybrałem PSOC/Zynq. Nie walcz
z chochołem.

Pozdrawiam, Piotr