Заметим, что Philips один из центровых акционеров ARM (долю точно не знаю). Возможно, этим "финт ушами" с LPC2101 и объясняется.
AVR уже давно не по 0.35 делаются. Последние - 0.18 точно.
Спор AVR <-> ARM идет из покон веков. Нету тут победителя. Это разные процы.
ARM как архитектура не идеален - это все знают. В AVR32 предпринята попытка выправить кривизну. Опять же, если атмел не будет дурковать - все у него получится.
Что касается нас с Вами - писать надо на C, почаще справочники хорошие по языку читать. Писать переносимо, не затачиваясь на Keil, RVDS и пр. Чтобы в ядре plain C был, ну а всякие __flash макросами (можно не обломиться и свой препроцессор на Python или Tcl написать - не так уж и сложно).
Разбивать код на модули. Не то, чтобы под ОС сразу писать - но оно должно быть готово для "нанизывания" на каркас ОС. ASM вставки - только в крайних случаях, отдельными модулями, чтобы опять же легче портировать было.
Аккуратно с типами данных. В ядре - никаких стандартных типов, все через #define. Указатели аккуратно преобразовывать, чтобы на ошибку выравнивания не налететь.
Изначально писать по стандартам Doxygen. Чтобы потом легче в коде разбираться было. Программеров лишать ЗП за непонятный и недокументированный код.
Почаще смотреть в диаграммы связей, которые Doxygen генерит. Можно еще Understand C++ юзать - тоже клевая вещь.
Идею парного программирования использовать. Один код кодит, второй смотрит на все "сверху" и пытается понять, что за х. получается, и заработает она когда-нибудть или сразу "фтопку". Потом меняются местами.
CVS или SVN юзать. Один раз разобраться - и кайф на всю жизнь.
И вооще осознать, что ЛЮБОЙ проект, даже контроллер светодиода, начинается с продумывания идеологии. И вместо дурацких споров AVR<->ARM<->PIC<->куча всего другого или, что еще глупее, KEIL<->RVDS<->IAR<->GCC просто берется и пишется plain C код, состоящий из одних заглушек. Затем анализируются связи, залушки заполняются целевым кодом. Все этого гоняется на симуляторе, написанном на том же С, или, что приятнее, Python. Отдебугеренный код надстраивается "железными" модулями - и он готов к впихиванию в любой процессор подходящей производительности, который нашелся в ящике стола. Железные модули дебугерятся отдельно от основного кода в целевом железе.
Весь процесс отладки целевого софта можно проводить в любой среде, главное, чтобы ANSI C поддерживался. Какая есть под рукой, какую программер знает - ту и юзать. При наличии такой возможности осваивать программизм под Linux. Там такая отладка идет куда проще и приятнее.
Что касется JTAG - не надо микроскопом гвозди заколачивать. Это:
* неудобно
* дорого
Да, есть ситуации, когда без JTAG - никуда. Но вот когда plain C цифровой фильтр или декодер DTMF через JTAG отлаживают в целевом железе - за это надо ЗП лишать.
С вообще удивительная вещь. Только это не сразу понятно. Нужно долго и нудно "вкуривать" книжки разные, да слушать мнение толковых людей. Конфа - идеальное место для этого.
Вроде все просто

Но мне только на то, чтобы осознать эту идеологию, год потребовался. Я ее сформулировал, теперь вот потихоньку осваиваю. Книжками обложился.
Собственно, я написал это по одной простой причне - не о том спорим. При правильном подходе процессор безразличен. И правы те, кто говорит - недели для осовение новой архитектуры хватит, если не стоит задача выжать 101% производительности. Просто нужно чуть расширить границы мышления - и мир вокруг заиграет новыми красками! Но увы, это в учебниказ не написано.