Микроконтроллеры

Автор сумасшедший??? Микропотребление, реалтайм и др. страшные слова -- это ещё алгоритмы со сложностью мало совместимой с ассемблером. При нормальном программировани C vs ассемблер разницы особой нет. Человек в среднем (а не на узко-специфическом участке), на современном CPU (а не 8-битном CISC 80-х годов) у компилятора выиграет в 2 раза по скорости/объёму если -- уже достижение. Причём больше для CISC. Для RISC уже трудно. Для VLIW в явной и не явной форме (читай современный x86) -- скорей нереально. Это про программную память и скорость. А с оперативной памятью человек в разы проиграет. Ибо без хранения в стеке -- всё static. Памяти нужно в разы и десятки раз больше, т.к. она расходуется всегда, вне зависимсти от фактического (не)использования. В стеке вручную хранить уже тяжко, но можно. Но код неэффективный, сильно хуже компилятора. Потому, что компилятор умеет в регистры раскладывать нужные переменные в нужные моменты времени. Вручную это весьма трудоёмко, это ж каждую функцию на ватмане перед кодированием планировать, где что хранится. Если переменных больше чем регистров у процессора, что наверняка (ARM в THUMB всего 8 шт., это вам не AVR). Кроме того, на современных RISC (ARM, MIPS и т.п.) в отличии от 8-битников весьма трудно с непосредственной и прямой/косвенной адресацией (ввиду слишком большой разрядности адреса), и что даёт опять же не эффективный код, компилятор больше индексную и/или базовую адресацию использует. Что трудно опять же вручную. Вообще задача распределения памяти -- это основная задача которую решает компилятор, даже не перевод из "C" в ассемблер. А библиотеки? Сознательно отказаться от всего стороннего, даже libc, и вручную писать элементарные вещи? Мой диагноз -- таки сумасшедший. Я б таких гнал бы подальше. Асм хорош для ATTINY, PIC10/12/16 и иногда полезен переписать узкое место, где действительно x10 выигрыш получить можно. Про "сэконимить копейки" тоже редкостный бред. На сахаре людей связанных с такими объёмами производства, где это осмысленно, единицы и ассемблером они особо не утруждаются. В мелких объёмах незначительное увеличение стоимости CPU удваивает ресурсы (память, скорость). А сроки и стоимость разработки весьма существенны. И таки да, такие проекты ещё кому-то поддерживать. Где в ассемблере через 3 года и автор не разберётся. Невозможно просто нормальному человеку столько держать в голове. А входить в курс дела ньансов данного проекта каждый раз слишком долго. Для "C" таких проблем нет. Если автор хочет "среду разработки" -- мы имеем дело не с профессиональным программистом. Потому, что последний обычно пользуется чем-то примерно одним для всего уже много лет и нет смысла перескакивать. Код для IAR вполне можно писать в MSVC. Не люблю ни то, ни другое, но понимаю, например, что в последнем есть какие-то возможности для работы с C кодом, а первый -- редактор уровня notepad с расскраской. Или кто-то пишет в Vim плюс какие-то свои плагины и т.п. Kто-то в eclipse. "Среда" нужна только для отладки и от ней чего-то волшебного требовать вовсе не надо, лишь бы основные функции не глючили (луч ненависти в сторону MPLAB). А то и вовсе не нужна, если есть отдельный отладчик (все ARM'ы через JTAG).