> Ale coś się tak uczepił asemblera.

Bo dla mnie ważna jest szybkość procka.
W ASMie sam mogę dobrać sobie każdą instrukcję, najbardziej
optymalną, nie ma zbędnych "dodatków" jakie generuje kompilator.
Żaden kompilator języka wysokiego poziomu nie da tak
wydajnego kodu jak pisanie samemu w ASMie.

> Istnieje przecież na świecie
> kompilator gcc - czyli bez dodatkowych wydatków można pisać programy w
> C. To nie PIC w końcu. No a program napisany w C/C++ zawsze w
> przyszłości będziesz mógł łatwo przenieść np. na bardziej wydajną
> platformę.

Osiągi jakie ma AVR32 idealnie mi pasują. Do tej pory robiłem na
ARMach Atmela, Philipsa, Analoga i brakowało mi wielu rzeczy jakie
ma AVR32 (np. sprzętowego szybkiego dzielenia).
Spośród procków mających kilkadziesiąt MIPSów i będących w cenie
AVR32, to te wypadają najlepiej.

> Po co zawracać sobie głowę asemblerem właściwie (tzn. znać
> warto aby rozumieć, co wyprodukował kompilator - ale nie warto pisać
> samemu w asm).

Przy dużych projektach robię tak, że procedurki pisze w ASMie
(przede wszystkim przerwania) a potem łącze to w logiczną całość
w C. Wtedy mam idealne jak dla mnie rozwiązanie - w miarę szybkie
(dzięki ASM) a jednocześnie logicznie przejrzyste działanie programu
jakie daje język wysokiego poziomu.

Fajne były ARMy Atmela SAM7S ale okazało się że mają problemy
ze startem przy zbyt wolnym narastaniu napięcia zasilającego.
Po prostu nie startował. Zależało mi na procku który ma
zewnętrzny reset, abym mógł mocno filtrowac napięcie zasilania
(układ pracuje w mocno zakłóconym środowisku), i puścić go
kiedy będzie już można do tego sprzętowe dzielenie. SAM7S tego
nie miały.

SM