Перенос проекта с AVR на ARM7. Информация к размышлению., Результаты тестов для интересующихся. Опции

[SasaVitebsk]

*** Побудительные мотивы написания.
Часто возникает вопрос выбора камня. Мы видим кучу таких постов. Некоторых это раздражает. Но на самом деле, для меня, причины этого очевидны. Давайте порассуждаем. Провести сравнительные исследования пары камней для текущего проекта - невозможно. Во-первых потому, что для этого надо сделать этот проект на двух платформах полностью, а потом провести исследования. Это, как мы понимаем увеличит затраты времени и денег почти в 2 раза. Кто на это пойдёт? Ориентироваться на сторонние оценки (статьи) - тоже сложно. Поскольку исследования стоят дорого, то бесплатно их никто не делает. Соответственно они проплачены. Как правило одним из производителей. Соответственно они достаточно тенденциозны. То есть, как правило,
идёт выпячивание достоинств и замалчивание недостатков у "нужных" камней, ну а у конкурентов - наоборот. Поэтому живое общение с кучей мнений, намного интересней. Особенно если приведены сравнительные данные.
Мне как раз пришлось переносить один проект с ATMega640 на LPC2106. Плюс особенность проекта такова, что есть возможность дать чёткую оценку производительности на данном проекте. С точки зрения аппаратной части - это почти сопоставимые проекты. То есть платка контроллера на 640 работает в том же железе что и 2106 и, при тестировании выполняют ту же задачу. Есть некоторое различие в выводе. Так, на 640 я использую 2 аппаратных канала SPI, а на 2106 один формирую програмно. На 640 я использую 8 ног камня напрямую, а в 2106 ч/з сдвиговый регистр и тоже программно. С одной стороны это несколько ухудшает точность сравнения, а с другой стороны более полно отражает свойства камня. Нет второго SPI - всё равно придётся пользовать
совтовый, не хватает мощности на выходе - приходится применять аппаратные средства с соответствующей программной обработкой. Короче точное сопоставление, но для этого проекта.
Я буду описывать два этапа. На первом этапе я перенёс проект "как есть". При том, что он был "вылизан" под 8-ми битовую архитектуру, обработка, во многих местах выполнялась таблично, для ускорения. Много работы с указателями, оптимизированной под 8-ми битную архитектуру. Некоторые важные части "оптимизированы" под AVR. В тоже время всё было написано на IAR C. На втором этапе, я переоптимизирую на работу с 32-ух битной архитектурой.


*** Производительность. Тестовое сравнение.
1-ый этап. Сопоставление по объёму флэш памяти. Некоторые примечания. От проекта требуется только производительность. Соответственно выбиралась настройка максимальной оптимизации по скорости. Проект и там и там влазит с запасом. Необходимо учесть, что порядка 1.5к на ARM "потерялось" в таблицах при выравнивании (это учтено в данных ч/з "/"). Надо понимать, что если бы ставилась задача оптимизации по размеру, то эту потерю я мог бы легко устранить. Но, поскольку,флэши у меня вагон, то я просто не буду этого делать. Соответственно, сравнение по флэши - чисто оценочное, для реального проекта, для любознательных. Кроме того, проект я пишу в режиме ARM, по вышеперечисленным причинам. В таблице приведены результаты компиляции
проекта так же в режиме THUMB, но это чисто для информации. Полного тестирования проекта в этом режиме не осуществлялось. Ну и кроме того, надо учесть, что в данном проекте около половины занимают таблицы.

Код

-----------------------------------------------------------------
Камень                  ! Mega640 ! LPC2106 THUMB ! LPC2106 ARM !
-----------------------------------------------------------------
CODE  memory (в байтах) !   52428 !   64728/62944 ! 69899/68115 !
-----------------------------------------------------------------
CODE  memory (в %)      !     100 !       123/120 !     133/130 !
-----------------------------------------------------------------

Загрузка до оптимизации

Код

-------------------------------------------------
Камень                  ! Mega640 ! LPC2106 ARM !
-------------------------------------------------
Средняя (мкс)           !   4809  !      721    !
-------------------------------------------------
Средняя (%)                !   28,9  !      4,3    !
-------------------------------------------------
Максимальная (мкс)      !   8008  !     1142    !
-------------------------------------------------
Максимальная (%)        !   48,0  !      6,9    !
-------------------------------------------------

Таким образом рост производительности при переходе на ARM на данной задаче составил от 6.7 до 7 раз. Только за счёт увеличения тактовой и архитектуры процессора. Без оптимизации вычислений под 32 среду.

Проверил оптимизационные способности компилятора IAR.
Загрузка при уровне оптимизации "NONE" компилятора IAR.

Код

----------------------------------------------------
Камень                  ! макс. опт. !    "NONE"   !
----------------------------------------------------
Средняя (мкс)           !    721     !     1591    !
----------------------------------------------------
Средняя (%)                !    4,3     !      9,5    !
----------------------------------------------------
Максимальная (мкс)      !    1142    !     2631    !
----------------------------------------------------
Максимальная (%)        !     6,9    !     15,8    !
----------------------------------------------------

Рост производительности программы при полной оптимизации составляет около 2 раз. То есть даже неоптимизированная компилятором и человеком прога на ARM уделает AVR приблизительно в 3 раза (на моей задаче).

Далее начал оптимизацию проги под 32 бита. Оптимизации подверглось 1 прерывание (FIQ) + 6 подпрограмм. Остальное косметически. В целом это составляет приблизительно 10% от объёма проекта. Корректировать остальное нецелесообразно, да и не хочется, для совместного сопровождения задач. Даю таблицу результирующих измерений.

Загрузка после перевода на 32 бита (ряд групповых вычислений)

Код

-------------------------------------------------
Камень                  ! Mega640 ! LPC2106 ARM !
-------------------------------------------------
Средняя (мкс)           !   4809  !      515    !
-------------------------------------------------
Средняя (%)                !   28,9  !      3,1    !
-------------------------------------------------
Максимальная (мкс)      !   8008  !      857    !
-------------------------------------------------
Максимальная (%)        !   48,0  !      5,1    !
-------------------------------------------------

Как видим коэффициент 9.3. Думаю результат в комментариях не нуждается.
Для объективности отмечу, что проект ещё подразбух. Конечный объём стал 70051 байт.

*** IAR, портирование, ошибки.
Компилятор IAR я выбирал по основному критерию - возможность портирования проекта на другие камни. Надо сказать - я очень доволен результатом. Фактически претензий к компилятору нет ни одной. Я при создании проекта сразу выбираю максимальную оптимизацию по нужному мне ресурсу и больше к этому не возвращаюсь.

При переносе этого проекта было несколько хомутов в кусочках, связанных с работой оборудования. Пару изменений связанные с выравниванием я сделал без ошибок. И были ошибки в кусочке, связанном с коррекцией проекта, в связи с отсутствием внутренней EEPROM памяти у LPC.

Некоторые выводы и рекомендации.
1) Что было правильно сделано и ускорило перенос.
Библиотеки были написаны в 2 уровнях. Ну например - I2C. Одна библиотека формирует start/stop/wb/rb. Написаны варианты для совтовой реализации и для аппаратной (TWI). А "над ней" библиотеки работы с 24c и т.п. Библиотеки нижнего уровня написаны таким образом, что взаимо заменяемы. Таким образом библиотеки верхнего уровня получились аппаратно-независимы и их менять не пришлось. Пришлось просто переписать библиотеки нижнего уровня под LPC.
2) Что было неверно сделано. Работа с внутренним EEPROM под AVR.
Как бы я всё равно остаюсь сторонником реализации IARом __eeprom, но надо было также разделить уровни работы. Точнее для AVR необходимо было ввести уровень работы с конфигурацией. В таком случае, для LPC, мне только бы пришлось написать нижний уровень, который "встроен" в компилятор AVR. На самом деле я и так не работаю с EEPROM. У меня есть "дубль" в ОЗУ и я только присваивание делаю. То есть с этой точки зрения всё Ok, но работа раскинута по всему проекту, нет защиты и т.д.
Выводы я сделал для себя, и не буду рекомендовать их для посторонних разработчиков. Но а для себя, звучит так: в связи с увеличением разнообразия камней, ростом их производительности, увеличением скорости разработки - использовать более системный подход к написанию ПО. То есть переносить опыт написания ПО для больших систем, на embedded платформы. Это ведёт к потере производительности, но увеличивает надёжность функционирования, упрощает перенос, ускоряет разработку.

*** Общие впечатления от камня LPC2106 и архитектуры ARM.
Я бы не назвал камень "чем то уникальным". Камень как камень, переферия как переферия. Где-то понравились особенности, где-то огорчили. Так, к примеру, наличие буфера фифо в USART, для моего проекта позволяет использовать любую скорость соединения. На AVR я могу получить максимальную скорость 57600. Зато переключение RS485 интерфейса получается просто "раком". Как они недодумали такую вещь - ума не приложу. Очень порадовал контроллер прерываний. Наличие FIQ прерывания, для меня, просто находка. Совершенно убила необходимость использования ноги SS в SPI при работе мастером. Просто потерянная нога. Ну и так далее. С одной стороны в каждом переферийном блоке были какие-то костыли. С каждым я бился, матерился и топал ногами. С другой стороны, всё это делается один раз, запоминается и далее идёт по накатанной.
Отладка проекта, в целом, оставила скорее положительные эмоции. Под MT-Link всё работало вполне устойчиво. Заливка производилась даже быстрее чем в AVR, что ускоряет процесс. Правда чуть медленнее компиляция производится и при включенной оптимизации много кода выпадает, но мне это ни грамма не мешало. Короче, с учётом того, что переферии у меня не много было задействовано, то переход потребовал не много времени. В целом я остался очень доволен. Есть ещё нюансы, например придётся написать новый бутлоадер, увязать всё, умощнить проект, распределить память и так далее, но всё это рабочие моменты. В целом я готовился к худшему. Отдельное спасибо разработчикам компилятора IAR. )))

Пытался кратко. Если что не понятно или какие вопросы - спрашивайте.

[viael]

А че LPC2106, давно в моде LPC23/24xx?

[bodja74]

А че LPC2106, давно в моде LPC23/24xx?

Неее... Точнее AVR vs ARM №2 ... или №22
Щаа народ сбежится ,будет друг друга

[_Pasha]

Работа с внутренним EEPROM под AVR.

Большое спасибо за реальные цифры!
Также присоединяюсь к тому, что не надо привыкать к "рюшечкам" компиляторов для работы с EEPROM и FLASH - создавать если не с файлы произвольного доступа, то хотя бы какой-то минимально независимый уровень. Все равно ведь все данные можно описАть в виде typedef struct, а потом обращаться по смещению через offsetof().

[zltigo]

*** Общие впечатления от камня LPC2106

Прежде всего надо помнить, что это просто САМЫЙ ПЕРВЫЙ чип в ARM линейке Philips/NXP все остальные уже были потом. Из уникальностей этого чипа 64K RAM при миимуме пинов. Абсолютно по всем другим параметам (включая цену) проигрывает по полной.

[Rst7]

У меня немого другие данные на кодере JPEG (считайте, чистая математика, никакой периферии). Грубо говоря, ARM быстрее AVR в 2 раза, не более. С оптимизацией там все в порядке в обеих инкарнациях.

[zltigo]

ARM быстрее AVR в 2 раза, не более.

Что очень странно - при примерно, в четверо большей тактовой!!!
На моих "математиках" обычно "пару-тройку раз" только за счет 32bit и плюс дополнительно мегагерцы. Что-то подобное и у Aвтора. По размерам Flash "типовая" цифирь +15% к AVR.

[Rst7]

Что очень странно - при примерно, в четверо большей тактовой!!!

Мой результат без мегагерц. Исключительно по тактам.

[xelax]

Странно, во всех проектах которые приходилось запускать и на arm и на avr причём как на iar так и на gcc у меня наблюдалась обратная картина по флэш. Проекты собранные для арма на 10-15% меньше чем для avr. Использую thumb и макс. оптимизацию по размеру.
А у автора наоборот получилось.

вот только что собрал один и тот же код (gcc -Os):
arm(thumb)

''
text data bss dec hex filename
67154 92 788 68034 109c2 (TOTALS)
''

avr

''
text data bss dec hex filename
79587 75 479 80141 1390d (TOTALS)
''

[zltigo]

Проекты собранные для арма на 10-15% меньше чем для avr. Использую thumb и макс. оптимизацию по размеру.

Только ARM Mode, и только скорость. Остальное не интересует в подавляющем большинстве случаев совсем.

[xelax]

Только ARM Mode, и только скорость. Остальное не интересует в подавляющем большинстве случаев совсем.

Очень хорошо, что задачи у всех разные Меня очень интересует минимальный размер кода и совсем не критична скорость.

Но у автора и в thumb всё равно получилось больше чем для avr.
Вообще такие сравнения можно считать корректными при относительной одинаковсти настроек компилятора.

[sensor_ua]

Использую thumb

Thumb у многих LPC2xxx в разряде неотлечиваемых багов. Хотя мне, например, ещё ни разу не понадобилось ужиматься

[zltigo]

Thumb у многих LPC2xxx в разряде неотлечиваемых багов.

Зачем распространять небылицы

[777777]

Пытался кратко. Если что не понятно или какие вопросы - спрашивайте.

А какие частоты у процев?

[VslavX]

У меня немого другие данные на кодере JPEG (считайте, чистая математика, никакой периферии). Грубо говоря, ARM быстрее AVR в 2 раза, не более. С оптимизацией там все в порядке в обеих инкарнациях.

Математика бывает разной - у меня на 512-битной ЭЦП (Эль-Гамаль и эллиптика) LPC23xx@72MHz быстрее Mega@16MHz более чем в 30 раз.
Это как раз тот случай когда повышение разрядности 8->32 используется на 101%.

[xelax]

Thumb у многих LPC2xxx в разряде неотлечиваемых багов. Хотя мне, например, ещё ни разу не понадобилось ужиматься

Приходилось как-то давно иметь дело с LPC2106 и 2214 (тогда ещё Philips) никаких проблем с thumb ом не обнаружил.

[Rst7]

Математика бывает разной

А я спорю что-ли? Тем более, в качестве фаллоса выступает криптография с открытым ключем

[=GM=]

Пытался кратко. Если что не понятно или какие вопросы - спрашивайте

Это что, мода такая, сравнивать 8-битный процессор то с 16-битным мсп430, то с 32-битным лпс2106?

Ну наберитесь смелости и сравните лпс с 32-разрядным TMS320F2808. Последний уделает ЛЮБОЙ лпс как бог черепаху. Периферии вагон и на любой вкус. Вот только несколько фактиков из жизни галактики.

1) Умножение 32*32 с получением 64-битного результата - 2МЦ или 20 нс мах. А ДВА умножения 16*16 =32 делается за ОДИН МЦ или 10 нс мах. И вся остальная математика тоже на высоте.

2) Дёрнуть ногу можно за 1 МЦ. То есть и ногодрыганье на высоте.

[Rst7]

Это что, мода такая, сравнивать 8-битный процессор то с 16-битным мсп430, то с 32-битным лпс2106?

Конечно

[Zlumd]

А какие есть ARMы с аппаратным DES-шифрованием на борту, кроме AT91SAM7XC (они недоставабельны)? А то я последнее время на ХМегу гляжу.

Сообщение отредактировал Zlumd - Jun 26 2009, 10:20

[dimka76]

Ну наберитесь смелости и сравните лпс с 32-разрядным TMS320F2808.

А сколько ваш TMS320F2808 ?

цены ARM7 сравнимы с ценами на восьмибитникакми.

А ваш TMS320F2808 в разы превосходит по цене и арм и авр.

[=GM=]

Ну, голословно не надо утверждать неочевидное. Для примера, младший член семейства TMS320F28023 стоит $2.85 за 100 штук, 40 мипс, 38/48 ног, рам 20 КБ, флеш 128 КБ, есть 12-битный АЦП на борту и много чего ещё. Поборет любой лпс на любой задаче.

Кстати, их официально называют "цифровые сигнальные контроллеры". Фактически это быстродействующие микроконтроллеры с развитой системой команд и продвинутой периферией. На них и операционку легко можно крутить.

[defunct]

младший член семейства TMS320F28023 стоит $2.85 за 100 штук, 40 мипс, 38/48 ног, рам 20 КБ, флеш 128 КБ, есть 12-битный АЦП на борту и много чего ещё. Поборет любой лпс на любой задаче.

Боюсь Вы преувеличиваете насчет любого LPC. Есть же и 31xx/32xx серии с 200+ MIPS и FP сопроцессором.

[=GM=]

Боюсь Вы преувеличиваете насчет любого LPC. Есть же и 31xx/32xx серии с 200+ MIPS и FP сопроцессором

Сравнивать надо по-честному. Поставьте для 31хх тактовую 40 МГц, и вы увидите, как легко лпс проиграет, вернее сольёт вчистую.

Другая ветвь С2000 семейства имеет 300 МИПС и 150 МФЛОПС и флеши там 512 Кбайт, так что придётся ставить пяток 31хх на подмену.

[dxp]

А ваш TMS320F2808 в разы превосходит по цене и арм и авр.

А уж по энергопотреблению...

[HeOHuKC]

Скоро аврки, сравнивать с блекфинами начнут, мол глядите какой прирост производительности. У всего есть свой круг задач, или вы предлагаете использовать вместо 8ми ногой тиньки , арм с 48ю ногами ? Большие АВР и многоногие имеет смысл менять на АРМ. Но и сравнивать их явно нестоит.

[defunct]

Сравнивать надо по-честному. Поставьте для 31хх тактовую 40 МГц, и вы увидите, как легко лпс проиграет, вернее сольёт вчистую.

По-честному - это на штатных максимальных частотах. Ведь по какой-то причине приведенный Вами TMS нельзя запустить на 200Mhz.

Другая ветвь С2000 семейства имеет 300 МИПС и 150 МФЛОПС и флеши там 512 Кбайт, так что придётся ставить пяток 31хх на подмену.

31xx на 270Mhz - 300+ MIPS и думаю примерно столько же MFLOPS. Так что и одного хватит.

[IgorKossak]

А уж по энергопотреблению...

А уж по среде разработки... и инструментам отладки...

[SasaVitebsk]

А какие частоты у процев?

Для AVR 14745600, для ARM то же умноженное на 4. То есть 58982400.

Это что, мода такая, сравнивать 8-битный процессор то ....

Я в преамбуле чётко описал зачем это сделал. Иногда требуется что-то помощнее AVR, а вы не знаете что ожидать от камня. К Вам это не относится. У Вас большой опыт работы с разными камнями и Вы способны "прикинуть" и сделать верный выбор. Для тех кто работал только с восьмибитниками, это сделать сложнее. Например для меня данные результаты очень неожиданы. Рост за счёт 32-ух битности после оптимизации был ожидаем, а вот рост за счёт архитектуры и частоты - несколько удивил. Я не ожидал получить более 2-ух раз.

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

За информацию о TI большое спасибо. Тоже инфа, и возможно кому-нибудь пригодится. Хотелось бы увидеть ещё цифири у тех, кто переносил проект с камня на камень.

У меня немого другие данные на кодере JPEG (считайте, чистая математика, никакой периферии). Грубо говоря, ARM быстрее AVR в 2 раза, не более. С оптимизацией там все в порядке в обеих инкарнациях.

У меня в проекте немного математики и она несложная. Камень выбирал исходя из объёма памяти. Мне её нужно много. В тоже время не хотелось ставить внешнюю.
В проекте много работы с памятью и сложными структурами в памяти. По сути свой менеджер работы с кучей, только специализированный. Большой объём адресной математики.

[proba]

начал перевод проекта с авр на тмс320ф23027, резон в специфике периферии тмс-а а именно ацп 12бит 4,6 Mспс и хи-резо шим с разрешением 150 пс - периферия которого в арм не наити. я не вижу что арм и тмс конкуренты, спицифика слишком разное и техас сумел это отлично слить в периферию.

у ренесас очень многие мк имеют одинакую цоколевку 100 или 144 пин, от M16/30 > M16/62 > M32 > R32 > RX600; от 16мгц 16 битного до 100мгц 32b флоат ядра. но не поиму что помешало атмелу выпускать совместимыи ряд мк авр/арм/авр32 .

и последнее, перевод должен быть обоснован, это не только что арм на 1$ дешвле авр а надо видеть и др. расходы а их много и софт может не самыи дорогои среди их быть : новые пп, стенсилы, профили смд машин, се сертификат ( итд) и скоро поимете что экономии ? будет...

Сообщение отредактировал proba - Jun 27 2009, 13:52

[Hmm]

начал перевод проекта с авр на тмс320ф23027,

И что? Только для вашего проекта "контора" берет CCS и прочие "накладные"?

[ArtemKAD]

но не поиму что помешало атмелу выпускать совместимыи ряд мк авр/арм/авр32

Где нет совместимого ряда?! У AVR совместимые линейки AtMega48/88/168/328 (32 ногий) AtMega8535/164/324/644/.... (44 ногий)AtMega165/325/645/128/2561/.... (64 ногий) AtMega3250/6450/1280/2560/.... (100 ногий).

ЗЫ. Тут недавно пипиcьками мерялись сравнивали старшие камни AVR с младшими ARM. Вот только те кто сравнивали благополучно забыли, что старшие камни это пин-то-пин расширение младших моделей. И их основная задача не с ARM соревноваться, а позволить развить уже существующие работающие проекты.

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

Сообщение отредактировал ArtemKAD - Jun 27 2009, 19:42

[aaarrr]

их основная задача не с ARM соревноваться, а позволить развить уже существующие работающие проекты.

Точнее, не позволить перевести проект на классово чуждую базу

не поиму что помешало атмелу выпускать совместимыи ряд мк авр/арм/авр32 .

Кстати, да. Мне вот интересно было бы попробовать заменить в одном проекте AT91SAM7X256 на AT32UC3A1256 для сравнения, не ведь не совместимы. А плату делать только ради проверки не хочется.

[proba]

Только для вашего проекта "контора" берет CCS и прочие "накладные"?

xds100 стоит копеики, софт можно закончить за эволушн таим 120 днеи. как запаснои вариант могу арендовать комп с лиценсионным ccs, знаю контору где 24/7 программа не пользуется и такои диил не противоречит лицензию.

Где нет совместимого ряда?! У AVR совместимые линейки AtMega48/88/168/328 (32 ногий) AtMega8535/164/324/644/.... (44 ногий)AtMega165/325/645/128/2561/.... (64 ногий) AtMega3250/6450/1280/2560/.... (100 ногий).

или я плохо выразился или Вы не то поняли, гуд было бы если вместо атмега можно было припаять арм/ авр32 .

Сообщение отредактировал proba - Jun 27 2009, 20:07

[Dx!]

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

Ойойой - а не слабо продемонстрировать такое решение? Особенно учитывая что оба корпуса одинаковы в размере, но отличаются шагом лап?

[ArtemKAD]

Ойойой - а не слабо продемонстрировать такое решение? Особенно учитывая что оба корпуса одинаковы в размере, но отличаются шагом лап?

MLF64 (9х9) на TQFP100 (14х14) ?

гуд было бы если вместо атмега можно было припаять арм/ авр32

Сильно разные камни. В частности у АРМ/АВР32 слишком много разных Vdd.

Точнее, не позволить перевести проект на классово чуждую базу

Если проект хоть как-то сложней ногодрыгания его перевод на "классово чуждую базу" это большой кусок работы как программиста так и схемотехника. Там очень много возникает хорошо замаскированных граблей. Если такой переход необходим (к примеру катастрофически перестало хватать производительности), то перейдут полюбому. Если же просто надо добавить "несколько дополнительны рюшечек", за старую хорошо проверенную платформу сами будут цепляться до последнего. Тут и экономика и надежность.

[zltigo]

за старую хорошо проверенную платформу сами будут цепляться до последнего. Тут и экономика и надежность.

Moderator:
Вы похоже перепутали тему, здесь об опыте перехода на другую платформу, а не об опыте "цепляния до последнено" c рассказами от "'экономике" и "надежности" и гипотетических "граблях".

[ArtemKAD]

и гипотетических "граблях".

Грабли не такие уж и гипотетические. Если почитать ветку по АРМ-ам, то там можно неоднократно найти их описания. В той ветке ведь пишут далеко не начинающие любители и тем не менее шишки набивают...

[aaarrr]

В той ветке ведь пишут далеко не начинающие любители и тем не менее шишки набивают...

Ой, не надо! 90% наступающих на грабли не удосуживаются даже почитать мануал. Еще 9% читают, но не дают себе труд понять прочитанное.
И так во всех ветках.

[zltigo]

Грабли не такие уж и гипотетические.

Грабли встречаются везде, только это НЕ ЯВЛЯЕТСЯ причиной сидеть и теоретизировать о проблемах "чуждых" платформ и оправдывать свою собственую неповоротливость "граблями", "надежностью", "экономикой", офигенными "наработками".....

[ArtemKAD]

Не понял , может я не так объяснил. Если существует РАБОТАЮЩИЙ проект (на AVR) в который надо добавить некоторые дополнительные функции, то экономически оправданней и надежнее (в первую очередь надежнее (предсказуемей) КОД, а во вторую - полностью оттестированная готовая плата) взять более крупный камень того-же семейства чем переходить на другое малознакомое. Или тут может быть иное мнение?! Или будешь утверждать, что портирование всего проекта с AVR на ARM это так-же просто и безглючно как добавление процентов 20-40 кода под ту-же платформу (то-же изделие)?!

Сообщение отредактировал ArtemKAD - Jun 28 2009, 21:32

[zltigo]

Или будешь утверждать, что портирование всего проекта с AVR на ARM это так-же просто и безглючно как добавление процентов 20-40 кода под ту-же платформу (то-же изделие)?!

40% кода НОВОГО кода, если это не 40 байт , а десятки-сотня килобайт уже точно как минимум на грани безразличности к ранее используемой платформе. А в случае, когда основная сложная перриферия внешняя это безразличие наступает много раньше. Приходилось с радостью портировать даже с 8bit ASM на АРМ 'С' за считаные дни,только дабы не заниматься сопровождением и дописыванием, пусть даже 40 байт а не то, что 40 процентов кода.

[SasaVitebsk]

Совсем рядом находится пост "AVR --> ARM". Там можно порассуждать на общие вопросы. Все они имеют место быть.
Здесь я привёл результаты готового переноса для интересующихся. Специфика была такой, что проект перенесён один в один. Я потратил на это некоторое личное время. В дальнейшем, в таком виде, это использовано скорее всего не будет. Я видоизменю его - добавлю ряд функций, из-за чего это всё и затевалось. Такие возможности (перенос один в один) встречаются нечасто. Именно по этому, я и привёл результаты.

Было бы интересно узнать результаты других подобных переносов. Например того же Rst7. На сколько я понял, у него тоже было что-то подобное, но он "зажал" результаты.

Былобы супер интересно посмотреть на перенос aaarrr "AT91SAM7X256 на AT32UC3A1256".

Всё это не для того, чтобы чем-то там меряться. И даже не для чистого любопытства. Мы же все работаем в конкретной области, где килограмм весит 1000 грамм, и хочется иметь цифровые выражения, на реальных, а не тестовых проектах. Кроме того, можно поделится общими ощущениями перехода. Комфортом работы и прочим. Информация на Сахаре интересна, но очень обезличена.

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

Или будешь утверждать, что портирование всего проекта с AVR на ARM это так-же просто и безглючно как добавление процентов 20-40 кода под ту-же платформу (то-же изделие)?!

Именно это я и подчёркиваю.
Для проекта объём которого Вы видете, полный перенос занял менее 2-ух месяцев.
Это при том:
a) что я был не знаком с новым камнем
б) что я не делал перенос ранее
в) что пришлось выполнить полное тестирование (достаточно большой объём)

Думаю, что добавление 20-30% кода под ту же платформу добавило бы значительно больше проблем.

[bodja74]

Кроме того, можно поделится общими ощущениями перехода

Это как с жигулей пересаживаешся на феррари
Лично по мне ,порадовало большее соотношение РАМ,
а вот периферия не очень сбалансирована,такое ощущение ,как будто с 8 битников перетащили
С VIC контроллером тоже слишком лихо закручен сюжет ,думаю избыточно крут для малых моделей LPC.
А насчет производительности и всего такого ,мне достаточно было глянуть на АСМ команды АРМ ядра ,и я
задал себе один вопрос - почему я раньше не читал таких умных книжек
Короче вывод - ARM рвет AVR ,как тузик грелку

[ArtemKAD]

Именно это я и подчёркиваю.
Для проекта объём которого Вы видете, полный перенос занял менее 2-ух месяцев.
Это при том:
a) что я был не знаком с новым камнем
б) что я не делал перенос ранее
в) что пришлось выполнить полное тестирование (достаточно большой объём)

Думаю, что добавление 20-30% кода под ту же платформу добавило бы значительно больше проблем.

Больше 2-х месяцев?!
Кроме того, не стоит забывать, что "менее 2-ух месяцев" это только перенос. А 20-40% кода все равно придется писать. И через 2 месяца вы все еще в начале пути.
Кроме того, нужна новая плата (новая схема, новые комплектующие, новая разводка). И кто это все делает?

Приходилось с радостью портировать даже с 8bit ASM на АРМ 'С' за считаные дни

Что-то меня терзают смутные сомнения в практической реализации подобного, если длина кода "не 40 байт", "считанные дни" не измеряются неделями или результат "авось будет работать". Разве-что речь о простых или типовых проектах...

[blackfin]

Приходилось с радостью портировать даже с 8bit ASM на АРМ 'С' за считаные дни

Что-то меня терзают смутные сомнения в практической реализации подобного, если длина кода "не 40 байт", "считанные дни" не измеряются неделями или результат "авось будет работать". Разве-что речь о простых или типовых проектах...

А если код на ASM'е с самого начала сопровождался подробными комментариями в стиле Си?
Тогда нужно всего лишь закомментировать ASM и убрать лишние комменты в коде на Си..

[zltigo]

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

Сишные вещи размером в десяток-другой К бинарника протируются действительно за пару дней (если не за день). То, что я поминал не портировалось а писалось заново на 'C' ровно неделю. Потом, внимание! было отпортировано за одну субботу обратно на восьмибитник, причем по размеру стало почти вдвое меньше, по производительности никаких напрягов и при полном отладочном логе. Глюки оригинала проявляющиеся в реальных условиях ушли. Секрет очень прост - первоначальное писалось человеком на ASM и много лет вот так вот по "40 байт" дописывалось-дописывалось.. латалось-латалось. Дописались и долатались в конце концов

Разве-что речь о простых или типовых проектах...

Не контроллер светодиода , сразу скажу. Чисто конкретно - LAPV5.

[SergeiCh]

Библиотеки были написаны в 2 уровнях.

В AT91Lib почти всё так сделано. Тот же At45 на Spid. По-моему, как минимум для ознакомления полезная библиотека.

Зато переключение RS485 интерфейса получается просто "раком".

У AT91SAM RS485 аппаратно поддерживается. Это всего лишь информация, LPC мне тоже по-своему нравятся.

[SasaVitebsk]

Больше 2-х месяцев?!

1) Как известно сроки определяются поставленной задачей. Параллельно выполнялось куча другой работы по сопровождению других проектов.
2) 2 месяца, это не много для нас. С другой стороны это время, потраченное, в основном, на изучение переферии. Если бы я работал с этим камнем, то это время было бы значительно короче. Сколько - не знаю. Не хочу гадать. Я привёл реальные данные.

Кроме того, не стоит забывать, что "менее 2-ух месяцев" это только перенос. А 20-40% кода все равно придется писать. И через 2 месяца вы все еще в начале пути.
Кроме того, нужна новая плата (новая схема, новые комплектующие, новая разводка). И кто это все делает?

Несколько не понимаю о чём вы?
Это вынужденная мера. Не потому, что я решил просто от нечего делать поменять рабочий камень. Я вынужден был перейти на новый камень, в связи с тем, что старый не справлялся с некоторыми задачами. Причина - недостаток свободной памяти. Чистый остаток 5800. После перехода, я оценив производительность решил расширить возможности новой платформы. При совместимости снизу вверх. Новая платформа будет обладать рядом функций недоступных в старой.
Так причём здесь на каком отрезке пути я нахожусь??? Я Вам так скажу, - я всегда нахожусь в сааамом начале пути. Всегда! Всегда хочется сделать лучше чем было раньше. А у Вас не так?

За помощь в моей работе хотелось бы поблагодарить ... того, того, и того-то

За помощь в работе хотелось бы поблагодарить в первую очередь Vesago.
Я его задолбал вопросами по телефону и нету. Надо признаться он стойко всё выдержал.

Ну и всех тех, кто отвечал на мои вопросы прямо и косвенно. Короче весь форум.
Ваши разъяснения на мои вопросы я аккуратненько скопировал в файлик и сохранил. Хотя в данном проекте не воспользовался. Я всё сделал FIQ/IRQ. Вложенность не понадобилась. Ваша помощь по устранению хомутов в IRQ тоже была очень важна.

[singlskv]

Я всё сделал FIQ/IRQ. Вложенность не понадобилась.

Интересно, а обработчики в итоге были реализованны в стартапе
или просто воспользовались возможностями VIC ?
Просто интересно как у Вас реализованы обработчики IRQ/FIQ при
полной ненужности обработчиков вложенных прерываний.

[zltigo]

Интересно, а обработчики в итоге были реализованны в стартапе
или просто воспользовались возможностями VIC ?

Странный вопрос. Сводится к тому, было прерывание IRQ единстаенным или нет, и испльзовался-ли jump на обработчик FIQ или этот обработчик сразу с 1E адреса и писался. Это имеет какое-то принципиальное значение?

Просто интересно как у Вас реализованы обработчики IRQ/FIQ при
полной ненужности обработчиков вложенных прерываний.

Лично у меня, "как обычно", при этой самой ненужности. Применяемый многими по принципу "а чего тут думать, трясти надо" bigloop рвущийся многочисленными прерываниями хорош для ограниченного числа решений. Как только научился продумывать подход к системе, так сразу вложенные и перестали быть нужными, причем у меня это не во времена ARM сие случилось, а во времена 186/386, которые аппаратрых ограничений на вложенность не имели - вкладывайся пока стек не кончится. Только нужно это в редчайших случаях. На ARM платформе эти и так редчайшие случаи покрывает еще на 90% наличие FIQ. В сухом остатке остается вообще стремящаяся к нулю необходимость.

[Dog Pawlowa]

Как только научился продумывать подход к системе, так сразу вложенные и перестали быть нужными, причем у меня это не во времена ARM сие случилось, а во времена 186/386, которые аппаратрых ограничений на вложенность не имели - вкладывайся пока стек не кончится.

Ну не знаю ... На embedded x86 использовал вложенность на все присутствующие 8 уровней.
Сейчас из текущих проектов на MSP430 вложенность используется для реализации программного интерфейса. Пожалуй, FIQ бы заткнул эту проблему.
Может вложенность от приложения зависит, а?
А какая Ваша альтернатива bigloop с прерываниями? shortloop, генерация событий и их обработка? Дык обработчики событий разноприоритетные и разные по длительности. Это нужно резерв производительности иметь, а при приоритетной вложенности система просчитывается достаточно просто.

[Сибирь]

Пытался кратко. Если что не понятно или какие вопросы - спрашивайте.

во сколько раз отличается себестоимость на арм и авр?

[SergeiCh]

... альтернатива bigloop с прерываниями?

Видимо, планировщик с оч. короткими обработчиками прерываний - взял данные, засунул в очередь или семафор выставил для процесса, который их обрабатывает. Какая еще может быть альтернатива big/super loop??

[singlskv]

Как только научился продумывать подход к системе, так сразу вложенные и перестали быть нужными, причем у меня это не во времена ARM сие случилось, а во времена 186/386, которые аппаратрых ограничений на вложенность не имели - вкладывайся пока стек не кончится. Только нужно это в редчайших случаях. На ARM платформе эти и так редчайшие случаи покрывает еще на 90% наличие FIQ. В сухом остатке остается вообще стремящаяся к нулю необходимость.

Дык, я собственно так и считаю, FIQ перекрывает практически всю необходимость в вложенных IRQ,
мне просто было интересно повелся ли автор(на новой платформе) на "стандартные" для многих компиляторов
примеры стартапов с возможностью вложенных прерываний или сделал все прерывания используя
возможности векторного VIC.

[SasaVitebsk]

во сколько раз отличается себестоимость на арм и авр?

Первоначально я не знал чего ожидать от платформы. Соответственно сделал несколько аппаратных довесков. В результате плата на LPC2106 выглядела значительно навороченней чем таже на м640. Были существенные проблемы с разводкой. В настоящий момент разводится новая плата, с внесёнными изменениями. По загруженности она будет сопоставима с платой на AVR. Плюс по совету Vesago перешёл с 24с512 на 45db021.
Результирующая цена платы будет приблизительно на 1$ меньше. Уже закупили контроллеры LPC2106/00.151 по цене 6.5$. Меги брали по 7.5$. Также выиграем на 45db приблизительно 1$. Потеряем центов 10 на 595 регистре.

Для данного изделия себестоимость комплектующих контроллера это пара % от себестоимости изделия. Так что это было не определяющим.

Дык, я собственно так и считаю, FIQ перекрывает практически всю необходимость в вложенных IRQ,
мне просто было интересно повелся ли автор(на новой платформе) на "стандартные" для многих компиляторов
примеры стартапов с возможностью вложенных прерываний или сделал все прерывания используя
возможности векторного VIC.

Честно говоря не понял вопроса.
Стартап я переписал аналогично книги Мартина. Соответственно у меня векторные прерывания IRQ на основе VIC. Одно совтовое. Очень понравилась реализация и совтового и прочих прерываний. FIQ я сделал прямым переходом, так как источник его у меня один.

На AVR у меня было сделано одно прерывание быстрое - и одно (совтовое) допускало вложенные прерывания. В связи с этим у меня теоретически работа UART на скорости выше 57600 была не возможна. На LPC у меня UART прерывание обрабатывается при заполнении буфера на 8 символов. То есть я смогу работать на любой доступной скорости. В связи с этим, я вложенность IRQ не делал. FIQ из IRQ вызывается автоматически и без проблем. Всё это легко управляется ч/з ф-ции компилятора. Короче к этому нет ни малейших претензий. Но, насколько я понял, вложенность также поддерживается компилятором и особых проблем не вызывает. Подробности этого механизма я почерпнул у GetSmart который этим широко пользуется.

У AVR не предусмотрены совтовые прерывания. И это существенный минус. Я пользовался незадействованым таймером.

[zltigo]

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

Да, так.