Мужики. Подскажите плз куда можно почитать по ARM новичку. Я AVR худо-бедно освоил. А вот что такое ARM слабо представляю. Проги писал на асме. Сишник не знаю.

Заранее благодарен.

Посмотри на gaw там раньше вступительные статьи были, для поимения представления.

В ARM'е всё по проще. Там нет ни каких разделений между памятью, регистрах, ROM - всё размещенно в 0..FFFFFFFF адресах. Канечно, никто в ASM зесь не програмирует Только на С.
Рекомендую просто берить PDF кокого то ARM'a, и всё.

Без C прохо

Сдрассте! Еще как программируют. Еще напишите, что на ARM только под Linux'ом или WinCE можно работать.

Ну, батенька, прям за живое задели. Кипит мой разум возмущенный.

И что, для этого есть необходимость, действительно реальная и суровая ?

Хочу написать проект на SAM7S64. До этого работал только с AVR. Какую среду разработки посоветуете? Какие программаторы/отладочные средства (JTAG)? Можно ли сделать программатор/JTAG самому? Отладочный компдект AT91SAM7S64-IAR для меня слишком дорог.

с учетом предыдущей работы на АВР лучше всего, думаю, брать ту среду, в коророй работал раньше (насколько я ничего не понимаю, все уважающие себя компилеры имеют варианты под АРМ). из JTAG мы остановились на MT-Link, компромисс между ценой и качеством, щас вот ждем, пока нам его поставят

Компилятор качается с iar.com
Отладчи можна сделать самому.
Схема Wiggler (отладчика) есть на сахаре в проектах. Делается из двух микросхем.
Отладочный комплект может быть например таким
http://www.olimex.com/dev/sam7-p64.html
В россии есть их диллер.

Представьте себе, бывает. Например, при работе с графикой/звуком или тяжелой периферией (типа fast ethernet). Я не призываю все писать на ASM, но без знания оного даже писание на Ц получается неполноценным.

Да прямо сам Atmel продает отладочную систему под SAM. Он снабжен JTAG'ом и IAR компилятором полностью рабочим, но генерирующим код не более 32 kB. Все стоит около 300 евро. Почитай на сайте Atmel'a.

Ключевой момент идеологии -- все данные надо сначала загрузить в регистры, проделать с ними манипуляции, а потом обратно выгрузить в память. Нет такого, чтобы, например, сразу увеличить на 1 содержимое по такому-то адресу.

Это немного напрягает.

Вот по делу разговор пошол

Может есть какая-нибудь ссылка где для таких как я почитать все это?
Ну чтобы на пальцах и все доступно?

Присоединяюсь! Если бы не знающие ассемблера могли только представить себе, чтО может закошмарить компилятор даже в простеньком цикле, они были бы поосторожнее в оценках.
Сдается, что освоение ARM ассемблера после AVR не будет представлять большой сложности.

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.

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

Еще одна ложка - скорее всего для исходной постановке задачи (8К и const) компилятор сам сооптимизирует код (те же LDM/STM).

Дык все верно, только эффективность нельзя оценивать по небольшому фрагменту, следует взять достаточно большой проект (не менее 3000-4000 Ц строк), написать его на Ц и АСМ, и сравнить. Вот только заниматься этим никто не будет...
З.Ы. Прикола ради попробовал табличный CRC16 - получился выйгрыш на 10% по скорости и 30% по объему

Где Вы увидели const? И покажите мне такой компилятор, который вместо понятного ему вызова тормозного memcpy станет извращатся с LDM/STM.

1) длина массива=const

2) Это не только от компилятора зависит, от программиста тож. Чувствовать надо (или знать), где он может сооптимизировать и при каких условиях.

Так речь не об особенностях оптимизации компилятора, а о том, что конструкцию с LDM/STM на Ц вообще реализовать не получится.

Не понимает...
Если, последовательно (не мешая в кучу). Функция memcpy (кстати чем она Вам не понравилась? Вы уверены, что там не через LDM/STM?) добавляет (как всякая функция) некие накладные расходы по передаче параметров. Мало-мальские приличные компиляторы для оптимизации при типичных ситуациях (например, длина массива - константа, массивы - глобальные переменные) заменяют вызов функции inline кодом, обходясь тем самым без вызова функции memcpy

Не понимаю!
1. Уверен, что не использует. Оперирует максимум только словами.
2. Еще раз прошу: покажите мне компилятор, который ведет себя хотя бы близко так, как Вы описываете.

Тогда еще раз условия задачи: процессор - ?, размер элемента массива - байт? и т.п.

IAR оптимизирует словами.



А нужно? Это весьма частный случай.

Да нет, если честно, нафиг не нужно. Просто мне упорно пытаются объяснить, что де хороший компилятор все это прекрасно оптимизирует. Ничего подобного!

Специально возможно и нет. Но возьмите типичную структуру кода. Циклы, управляющие структуры, функции (подпрограммы). Посмотрите, как эти структуры реализует компилятор, и насколько оптимальнее это можно сделать на асм. В завистимотси от процессора/компилятора проигрыш Ц будет от 0 до 50% в более или менее общих случаях. Все частные случаи накладывают сильные ограничения, и поэтому эти частные случаи трудносопровождаемы, шаг вправо, шаг влево - расстрел. Тот же LDM/STM потребует дополнительных телодвижений при отсутствия выравнивания на 4 и любого количества байт в блоке. И вся оптимальность тут уже начинает идти лесом на мелких блоках. То есть удел асма - вставки там, где действительно нужно выжать максимум быстродейтсвия, таких мест не очень много.



То есть как я и говорил, 1.3 раза по коду.

Хорошо. Условия задачи:
1. Процессор: ARM7
2. Размер элемента массива: 4 байта (слово)
3. Количество элементов: 2048
4. Источник и приемник выравнены по границе слова (ложка дёгтя здесь
отсутствует, но можно добавить - 4 байта из 8192 картину не испортят)
5. Оптимизация на скорость

Попробуйте решить это на Ц и сравните с АСМ

Опять слишком "жесткое" утверждение. Поймите и Вы, я тоже не цепляюсь именно к этому примеру. Но Ваши категоричные утверждения
Вы хоть знаете где Ваш компилятор (именно тот с которым Вы работаете) делает оптимизацию (и какие приемы лучше при этом использовать). Ну хотя бы такую классику ++j или j++. Или сравниваете C-программы и Asm-прог только по конечному результату?

Извините, если Вам показалось какое-то упорство с моей стороны (навеянное впрочем личным опытом, пусть и несколько уставревшим, и знания некоторых основ компилирования). Но ведь весь разговор в течении последнего часа - и поэтому выбранный тон - для лучшего взаимопонимания

От своей реплики с условиями задачи не отказываюсь

Хм, издержки реального времени (почти одновременные ответы).

Условия принимаю.

Поверьте, я прекрасно знаю, где и как работает оптимизация у моего компилятора. Когда-то угробил прилично времени на действия типа: модифицируем код->компилируем->дизассемблируем->смотрим, где накосячено.

А приведенная мной задача не решается на Ц оптимально.

Прерываюсь на какое-то время. Пора домой

Ничего себе -- " ARM начинающим"!

Я вот какой аспект хочу поднять:
ну вот отладили вы программу на С, добились (может быть с трудом) того, что она успевает реагировать на какие-то внешние воздействия.

Поменяли компилятор (апгрейд версии, заказчик вдруг решил перейти на другой, либо проект открытый) -- девайс не работает, нужно искать то "критическое место" , которое портит все из-за изменившегося времени выполнения.

Если заранее найти такие места и написать их на асме, то код станет гораздо "сопровождаемее".

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

Судя по всему вы не писали достаточно большие проекты на ASM.
У меня, конечно, довольно редко воникает проект продублированный на С и ASM. Однако, например для кодека G.723.1 переписывание только базовых функций на ASM привело к уменьшению времени обработки одного фрейма с 200мс до 25, что соответствует примерно 10 кратному ускорению времени выполнения. Для обработчика обмена по USB выигрышь по скорости обработки выросло в 4 раза.

И как раз чем бльше проект, тем заметнее разница.
Если на отдельных простых функциях разница составляет 30% то на сложных функциях, а уж тем более больших проектах разница достигает 3-4 каратного превосходства.

И чтобы не быть совсем голословным:

Вы предлагали сравнить на реальном проекте.

У меня недавно был проект часть которого также была выполненый на С и ASM.

Это real FFT.
На котором также легко демонстрируется трехкратное превосходство ASM над С.
Итак:
Есть входной масив данных int16 Data[2048];
Так же есть входной оконный масив int16 WIN[2048];
Наебходимо выполнить следующее:
Первоначально поэлементно умножить елемент данных на елемент окна

Data[i]=Data[i]*WIN[i]/65536;

Далее выполнить реальное преобразование фурье по 2048 точкам.
И получить квадкат абсолютного значения по получившимся комплексным отсчетам.
ABS= RE*RE+Im*Im;

Выходной массив это int32 Abs[1024] расположен на месте входного массива данных Data[2048].

пример на ASM прилагаю:

Он занимает 4К памяти данных, и во Flash 4К под окно, 4К под служебные таблицы и совсем чуть-чуть под программы.
Один цикл вычислений занимает примерно 500 000 цикло для 7TDMI.
На С аналогичная программ требовала примерно в 3 раза больше.

Если вы полагаете, что сможете получить аналогичные ( в приделах 30% ) результаты на С, покажите это.

В принципе дело достаточное простое для С.

Умножение на окно и авсолютное значение - функции достаточно простые.
А real FFT предлагается в довольно большом количестве библиотек если лень писать самому.