The Insider's Guide (~6MB):
http://www.hitex.co.uk/arm/lpc2000book/index.html
(либо сразу по http://www.hitex.co.uk/arm/lpc2000book/lpc-ARM-book_srn.pdf)

Я на эту книжку наткнулся уже после того, как изучил даташиты
Кстати, где-то тут выкладывали ее принтабельный вариант.

Если кому надо - зашлю - 4.4 мега в зипе. Но это по филипсовским ARM-ам, правда многие вещи безотносительно филипса. В принципе есть еще arm7tdmi.pdf (1.15 мега в зипе) - описание ядра от фирмы ARM с описанием режимов, ассемблера и растактовки, что называется must have - могу прислать, можно также легко найти в Инете.

С уважением, Андрей Слабнов.

Так это уже 2 большие разницы. Сравните - писание проекта на асме целиком vs писание на асме только критических мест. Хотя даже второе лучше писать на С (если оно успевает), хотя бы с точки зрения сопровождаемости кода.

Интересно, а на LPC2101 тоже на C будем писать? Вообще-то изначально человек высказался в том смысле, что на АСМ'е здесь вообще никто и ничего не пишет, что не есть правда. А "сопровождаемость" кода вовсе не зависит от того, на каком языке он написан, скорее, это зависит от качества документации и сопровождающего.

Если уж на всякие x51, AVR и младшие пики код прекрасно пишется на Ц, не вижу сколько-нибудь значимых причин, не дающих писать для 2101 на том же Ц.



При прочих равных код на ЯВУ сопровождается лучше, код на ЯВУ под ОС, еще лучше.

Может быть и прекрасно, да только уж на мелких восьмибитниках ASM сам доктор прописал использовать (я не беру в расчет уродцев с 128к флеш). Ладно, надо завязывать, а то дискуссия планомерно скатывается в оффтоп и религиозную войну...

Какая разница, сколько там флэш.
Эмпирическая оценка разбухания кода Си по сравнениею с асм 1,3-1,5 раз.
Быстродействия примерно столько же. Кочечно, есть и частные случаи.


Ну вот, так всегда, только найдешь тему где можно эмоций да постов понабрать :-)))

Интересно, а про ARM-ы книжки на русском в природе встречаются?

Так жизнь состоит сплошь из частных случаев А Ваша оценка в 1,3-1,5 кажется мне несколько заниженной даже для самых общих случаев (раза в 2).

Давайте сделаем тест. Вы предлагаете какой-либо общий случай, например реализация кольцевого буфера FIFO для передатчика UART (вполне себе общая типовая задача для embedded), приводите реализацию на асм для ARM. Я делаю то же самое на Ц. Результаты cравниваем, вычисляем оверхед Ц. Если он больше 1.5 раз, я ставлю ящик пива или перевожу вам деньги для его приобретения. Ы?

Будете смеяться, но FIFO буферы я тоже пишу на Ц Но если взять другой общий случай, например копирование/заполнение массива, то оверхед будет просто немеренный.

Внесу и я свое замечание на 5 копеек.
Вообще-то как я замечал оценка разбухания кода и соответственно быстродействие оличается в 3-4 раза.
Только сравнивать надо не отдельные функции, а модуль целиком, содержащий большое количество функций.

Огласите цифры. Давайте пример на асм и описание алгоритма, который нужно реализовать.

Это, мягко говоря, неправда.


При увеличении количества функций все лишь нивелируется, стремясь к среднему значению. Если можно еще найти отдельные локальные места, где на асм можно выиграть 3-4 раза объема или быстродействия по сравнению с Ц, то в большом проекте эти места утонут в море среднестатистических показателей.

Да пожалуйста: скопируем массив объемом 8K из пункта А в пункт Б. На АСМе получается огромный выйгрыш за счет использования LDM/STM.