Доброго времени суток, решил зающать ARM7 (контроллер Philips LPC2478) с ним идет сопроводительная документация, в ней рекомендую для отладки программ использовать uVision (скачал uVision3) ну видимо обрезанная версия ни чего нет подскажите какой нибудь хороший отладочный софт на подобе AVR Studio что бы можно было так же отлаживать тыкать на регистры и всякое такое.

Rowley Crosstudio: www.rowley.co.uk/arm/

Это GNU компилятор + графическая оболочка.
Есть в местных закромах.

Подтверждаю, пользуюсь, и обязательно приобретите JTAG типа Wiggler или J-link, через них программируется в 10 раз быстрее,
чем через Flash Magic.
Не бойтесь загубить процессор, он много перезаписей выдерживает.
Не верьте рекламе Кейла, что короткий код и быстрее работает, если есть, то почти незаметно.
Если захотите Кейловскими примерами воспользоваться, то надо переписать названия ячеек
и применить макросы входа-выхода из прерываний(Кейл их вставляет по умолчанию).

Вам что ли верить Попытайтесь доказать.

Или хотя бы опровергнуть вот эти результаты:
http://www.alylab.eu/Subjects/Tests/LPC/LPC.htm

GCC и все что на нем компилирует значительно хуже и очень заметно.

GCC всех уделывает, что неудивительно - над ним работают не только представители ARM а огромное сообщество, хотя скорей всего другие таскают оттуда код поэтому немного подтянулись на сегодняшний день и скорей всего сегодня особой разницы нет какой компилятор использовать, разве что LLVM может ощутимо выбиться в лидеры в обозримом будущем.
http://www.mcu-raisonance.com/tzr/scripts/...C-Benchmark.pdf

Ох уж эти обзоры . Никому верить нельзя, только себе. Одно можно сказать, что "The ARM Company" давно уже не является безусловным лидером в компиляторописании. Говорить разве только можно о тройке лидеров.

Очень древний тест, да и вообще смахивает на липу.

А есть что нибудь свежее, для кортексов, к примеру?
Было бы интересно посмотреть.

Хотя от знакомства с GCC у меня остались смешанные впечатления - где то хорош, а где то так себе.

Где-то когда-то у кого-то уделывал может быть, проверить невозможно.

Вот здесь данные посвежее: http://www.soel.ru/cms/f/?/374464.pdf

Как видно неотесанный GCC продувает в разы. Если его дооснастить либами как в CrossWorks то кое-как еще терпеть можно.
Но все равно продувает более чем в два раза.

У вас по тестам получается IAR в 3 раза медленнее мертвого CARM.
Хотя, с помощью настроек можно добиться любого расположения компиляторов в таблице.
Но интересны варианты когда настроено на максимальную оптимизацию по скорости или по размеру.
Посмотрел там IAR проект - оптимизация вырублена.

Я тоже проводил сравнения, например -
http://electronix.ru/forum/index.php?showtopic=68880

Сейчас IAR и RVCT компилят примерно одинаково, у каждого есть свои + и -.
GCC чуть хуже.

А вот отладчик у IAR лично мне больше нравится.

Чем же он хорош?
В ИАРе вообще нельзя при отладке смотреть состояние модулей периферии (как в кейле, например), или мне это просто показалось в первый раз?

Там и была хитрость, что CARM тогда очень ловко с float единичной точности обходился.
RealView и сейчас с упрощенной либой для float быстрее всех будет.
Отладчик в Keil-е да, уже не так интересен с тех пор как они практически перестали поддерживать периферию крупных чипов.

Я проверял на моей программе. Все вычисления в 32бит фиксированной точкой. Тригонометрию сам написал.
Размер программы был не интересен. Скорость хотелось бы увеличить. Для такого типа программы Кейл имел преимущество около 2%.
Может рекламный выигрыш связан с float и double?

Можно, все регистры видны.
В IAR удобные макросы. (по событиям, загрузка, прошивка, рестарт и ...)
Log Breakpoint - точка останова по которой печатается в лог сообщение (можно переменные распечатать...)
Доступ к файлам на компе через fopen....
Т.е. в нем больше "консольных" возможностей, а не свистелок перделок

Полностью аналогичная личная оценка.

GCC может скомпилировать ядро линукса, а остальные - нет.

Все претензии к ядру. Можно написать программу из 5 строк, которую будет компилировать любой из перечисленных компиляторов, а остальные - нет. И при чем здесь компилятор?

Пользователи Linux всегда в выигрышном положении - можно не беспокоиться, GCC достаточно хорош и нет ни одной причины по которой нужно рыскать по файлопомойкам в поисках пиратского компилятора или выкладывать деньги. Оптимальными должны быть в первую очередь алгоритмы - с этим в Linux все в порядке. Ни один тест не отражает реальное положение дел, можно посмотреть архивы keil - там gcc в разы проигрывает по всем тестам, что просто смешно - достаточно посмотреть адекватные тесты которые я приводил.

"Никому верить нельзя - мне можно"©

Я же не призываю кинуть все и переходить на GCC - если вас устраивает ваш компилятор, нет причин переходить - "лучшее - враг хорошего" ;-)

Можно и кинуть и отпортироваться, буде на то будут веские причины. Проблем-то, если не идти на поводу у компиляторостроителей добавляющих непереносимые вещи для подсаживания пользователей, в переносе минимум. Многие гнутые инструменты безусловно стандарт де-факто, тот-же ARM IAR практически упал на binutils. Только вот компилятор GCC штука слишком для меня размытая . "Кто шил костюм"? временами имеет решающее значение - всякие сборки типа от Klen - я тут напылесосил их интернету всяких патчей и собрал - пробуйте, меня точно не устраивают. Сам я тоже этим заниматься не буду - мне работать надо. Всевозможные "фирменные" сборки GCC в конце концов закостеневают, ибо им надо и деньги "на бесплатном" стричь, а не GCC толкать вперед. Нужно будет - портану, ибо для некотрых платформ, в число которых входит и ARM, GCC крепкий член лидирующей группы.

Но GCC не может скомпилировать ядро Windows CE и даже либу к ентому Windows.

А вот ARM RealView может и для тех и других либы делать.
Так что с практической точки зрения имеет смысл все писать под RealView. (Он же Keil)

Тем более что линуксы под встраиваемые платформы терпят полный провал.
А Window CE бъет рекорды популярности. И надо держаться поближе к лидерам.

Вам нужно обязательно попробовать себя на сцене в передаче "Аншлаг". windows ce настолько выбился в лидеры что его разработчики пишут в своих блогах http://blogs.msdn.com/b/obloch/archive/201...s-not-dead.aspx


Этот "лидер" на сегодня поддерживает только 1 процессор и может работать с RAM не превышающую 512МB.

ARM/MIPS/SHx/x86


Надо больше? Ставьте Windows Embedded Standart.

Споры бессмысленны. Для каждой задачи конкретная ОС.
Пример: работаю с OMAP3530 под Linux, WinCE 6.0 R3 и попробовал Windows Embedded Compact 7.
В Linux оптимизированный стек TCP/IP - скорость передачи по сети сильно (10,3 МБ/сек в Linux против 4,5МБ/сек) отличается от скорости под WinCE 6.0 R3 (правда не успел протестировать под Windows Embedded Compact 7).
По работе с графикой - удобно с WinCE. Хотя наличие OpenGLES уравнивает возможности.
Отладка приложений и ядра под WinCE на раз-два, в Linux на раз-два-три (Platform Builder против DDD, GDB, KGDB).
Открытый код Linux против платного полуоткрытого WinCE.
И к слову, собранная Windows Embedded Compact 7 компилятором с поддержкой ARMv7 (Cortex-A8) работает значительно быстрее чем WinCE 6.0 R3 (c Linux пока не сравнивал).

Имеется ввиду что wince не поддерживает многопроцессорные системы - SMP.

Win CE 6 да, но Windows Embedded Compact 7 поддерживает SMP (ARMv7).

Цитата(zltigo @ Aug 27 2010, 12:27) *
"Никому верить нельзя - мне можно"©

Выскажу свое мнение, может неправильное, но есть.
1. Процессор LPC2478 слишком слаб, чтобы кроме основной задачи еще тянуть Linux или Windows.
С сетями и с многозадачностью не работаю, всё остальное из них вполне можно написать или взять готовым.
2. Человек не может выдавать новые гениальные идеи по расписанию, интеллектуальную собственность надо защищать.
Я не сторонник полностью открытых программ.
3. Не считаю нужным снабжать заказчика ломаным кейлом или требовать его покупки.

Поступаю следующим образом. Для конкретного типа процессора пишу библиотеку сильно оптимизированных
примитивов. (около 120 строк в ассемблере). При этом 90% времени процессор выполняет именно эти функции.
Оптимизация остальных 10% и выбор оптимального компилятора уже не интересны.
(размером программы не интересуюсь - без Линукса на все хватит, а флешку мне не заполнить)
Для LPC2478 Я выбрал Rowley CrossWorks, просто друг показал и мне понравилось. А у других и шрифт раздражает и
цвет не нравится. А сотни часов смотреть на это надо.
Заказчику передаю в виде небольшой программы для GCC и почти оптимальной библиотеки нужных ему функций.
А перейти на другой процессор запросто - переписать эти 120 строк и разобраться с периферией.

ещё 5 копеек в пользу Rowley CrossWorks - это поддержка FTDI FT2232. Под рукой была плата с FT2232, вытянув JTAG линии и настроив TRST, nRST на нужные GPIO, получил почти даром, отладчик и программатор.

ИМХО, не следует мешать в одну кучу свойства собственно компилятора и среды разработки - "мухи отдельно, котлеты отдельно". Выбираете текстовый редактор (если интересно - на форуме есть соответствующие темы - в чем народ только не работает) или среду себе "по вкусу" - и без напряга смотрите на нее "сотни часов". А компилятор, программатор, отладчик (я, правда, жесткий сторонник консольной отладки) уже цепляете как внешние инструменты - через командную строку. И переход на новую архитектуру приводит только к переписыванию make-файла, без нарушения душевного комфорта и насилия над собственной личностью в новой среде.

Золотые слова! Но не всегда это возможно к сожалению...
Например разработка java приложений и сборка их через make не очень кошерно. Всё таки есть устоявшиеся средства и способы...

Ну Вы бы еще Flash приложения помянули . Но к счастью в том, что называлось и все еще называется программированием инструментарий строится модульно и совсем не обязательно пользоваться набором "101 в одном", а можно собрать все самое приемлимое и подогнуть, дописать под себя.

Поэтому открытые проекты всегда будут развиваться быстрее и качественней - над ними работают тысячи людей по всему миру.



Следуя этому правилу придем к первобытному строю, когда знания были доступны избранным - колдунам, жрецам, шаманам.



На форте не пробовали писать ? чем изобретать лисапеды.

<<Поэтому открытые проекты всегда будут развиваться быстрее и качественней - над ними работают тысячи людей по всему миру.>>
Начнем с Microsoft - надо повысить качество. Вы их попросите пусть откроют. Да здравствует Linux самый быстрый и качественный!

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

<<На форте не пробовали писать ? чем изобретать лисапеды.>>
Ну я не знал, что все так делают, думал некоторые еще идеальные компиляторы ищут.

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

Вы себе льстите, хотя как в поговорке "сам себя не похвалишь - никто не похвалит"..



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

И "1с" и AIR.
Пути программирования неисповедимы:-)
И чем больше технологий хороших и разных тем быстрее движется прогресс.
И тем больше потребностей покрывается. ИМХО.
Но никто не отменял присказки "При всём богатстве выбора..."
Главное всё же, во всём этом, что есть возможность выбора.
Хочу халву ем, хочу - пряники

Это Вы обижаете автора ветки. Выбор компилятора это как-раз тема ветки. Я выбрал совсем не идеальный и объяснил почему.
Если Rom20 согласится с моим выбором - могу помочь в освоении.

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


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

Вы спорите с изначально абсурдным утверждением. Тысячи разрабатывать один софтовый пакет не могут и никто так на самом деле не делает.
Это просто плод воспаленного воображения падких на дешевый пиар разработчиков.
Т.е такого подхода нет и быть не может.

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

С GCC для ARM как раз все ясно, там 50% участия самой фирмы ARM по заявлению самой ARM и никаких там особых альтернативных разработчиков нет.
И этот компилер всегда будет уступать RealView по производительности в каждый отдельно взятый момент времени.

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



Это как понимать, 50% кода принадлежит arm - а остальные 50% типа не в счет ? А как же code sourcery? RH ? а остальные компании участвующие как минимумум в оптимизации - nokia например ? В общем Вы не в теме.

Да яркий - как "сто тысяч Леммингов" чего-то с упоением "причастных" выдают на гора мутного латанного кода, но зато много. Есть ведь и друге опенсорсные ядра. Например, FreeBSD. И делаются они достаточно небольшим коллективом без шума и пыли, имеют вменяемые исходники, которые действительно можно с удовольствием читать и портировать.

А сами разрабатывать не пытались это ядро? Идите попытайтесь там че нить разработать. Вас пошлют подальше в легком случае.
Не повторяйте мифы вообщем. Самый консервативный проект придумать сложно. Win CE развивается гораздо быстрее.



Здесь таже логика что и с ядром. Они эти нокии может бирюльки навешивают там где-то возле компилятора. А так они даже симбиан свой открыть не могут до конца.

Это вменяемое ядро еще вчера висло напрочь если достать неотмонтированную usb-флешку, над бздунами до сих весь мир потешается этим фактом.



Хе-хе - вот это очень правильный ответ на "выдают на гора мутного латанного кода" - никто там не примет в основную ветку говнокод.

При том количестве говнокода в котором плавает даже якобы тщательно охраняемое "ядро" Линукса изобразить "а я на арене весь в белом" уже давно не удается.

Давно прошли времена, когда в ядро включали все подряд, сегодня достаточно профессиональных программистов участвует в проекте, сейчас наоборот началась тотальная чистка кода, в частности радует что есть проекты по выкидыванию всякого бинарного хлама проприетарщиков.

Тема с банальной просьбой плавно перерастает в религиозную войну.
Может закрыть?

Не надо. Думаю, что все уже закончилось. Осталась пища для размышлений.

Посмеяться хотите?
Потратил пару часов - скачал расхваливаемый в данной ветке Keil 4.12, и провел сравнение с IAR 5.41 и гонимым GCC 4.4.3, компилируя Dhrystone 2.1 для платы на LPC1768 (Cortex-M3).
Результаты такие:

Максимальная оптимизация по размеру:
Keil: -O3 -Ospace, 1816 байт, 95066 dps
IAR: -Ohz, 1886 байт, 95434 dps
GCC: -Os, 1966 байт, 108931 dps

В прошивку входит много чего HAL, операционка, и прочее, это все я компилировал IAR, менял только один объектник собственно с dhrystone, размер приведен именно для тестовой функции+ее константные данные. Итого: разницы в размере и скорости почти нет - в пределах зависимости от выравнивания кода во флеш.

Максимальная оптимизация по скорости:
Keil: -O3 -Otime, 2132 байт, 122243 dps
IAR: -Ohs, 1974 байт, 123734 dps
GCC: -O3, 2506 байт, 128803 dps
Итого: тожe практически паритет

А вот с GCC все было весело - для Кортекса я им не пользуюсь - последний у меня 4.1.1 для ARM. Cначала скачал готовую сборку от Macraigor 4.4.3 - я всегда оттуда беру. Установил - компилятор молча не работает. После получаса разборок выяснилось что ему не хватает некоторых библиотек - Цигвин у меня староват оказался для него, скачал, поковырялся, нашел нехватающее (почти гиг скачать пришлось), поставил, заработало, с матюками. И общий итог печальный - файл хоть компилируется и линкуется, но работать на плате оно не хочет - выходит с произвольным результатом. По итогам разбирательств - похоже проблема в сборке, она не поддерживает генерацию нового EABI от ARM-а, во всяком случае ключик -meabi=4 не жрется, а при компиляции без него IAR-овский линкер выдает варнинг - после потерянных двух часов мне уже дальше разбираться, искать другие сборки (не факт что совместимые) итд итп, стало лень. Для сравнения - на Кейл никогда не виданный в глаза было потрачено 15 минут. На GCC которым я пользуюсь лет 8 - более 2 часов и результата все еще нет, зато фана - полные штаны.

Утренний upd: частично разобрался с проблемой - почему-то линкер считал что последняя глобальная переменная объявленная в объектнике GCC свободна и лепил туда первую подходящую из IAR-овских объектников. Крупно не повезло что это была переменная обновляемая раз в 128 мс в прерывании значением прошедших тиков (профайлер) - быстро такое не обнаружить . Кто там виноват в совмещении переменных уже на разбирался - добавил еще одну липовую переменную в файле теста и все заработало. А вот результаты уже интересные - GCC проигрывает по размеру кода и немного выигрывает по скорости. Так что - не так уж оно мрачно все, после некоторых усилий GCC вполне юзабелен.

Да все совершенно ожидаемы. Когда-то (последний раз вскоре по появлению IAR V5) гонял эту-же троицу для ARM7 (и на Whetstone тоже). Результаты сходны. Собирал под заказчика и реальный проект под GCC после IAR V4. По размеру (компилировалось под производительность) отличия минимальны, производительность, правда, не оценивал - там было по любому с большим запасом.

например, IAR - который супер пупер и за деньги очень хреново работает с FPU в ARM9 - то есть у него поддержка (либы эксепшены кривая) и с кодогенератором надо как-то хитрить, то есть программисты обплевались
с GCC, когда раньше брал в руки шашки самостоятельно, никаких проблем с поддержкой плавучки не испытывал

также вопрос к пользователям кортексов - а NEON хоть как-то поддерживается в коммерческих компилерах? прежде всего IAR, ну и RVDS интересны???

ну то есть я знаю, что GCC и RVDS поддерживают, но вопрос как? вроде как GCC сам умеет "векторизовать"
ну а IAR и Keil вроде как и не собираются поддерживать

btw: сейчас прет arm-gcc-llvm (вроде им Джобс пользуется) кто-нибудь пробовал???

Готовый GCC лучше брать от CodeSourcery - там люди над ним за деньги работают, и поддержка новых фич появляется раньше майнлайна. Кстати я слыхал IAR вроде тоже на GCC перешёл.

Keil сейчас юзает фирменный армовский компилятор, но т.к. сама среда заточена под младшие модели, поддержки Cortex-A и соответственно неона нету.
RVCT неон поддерживает давно, и авто-векторизацию тоже умеет.

Да, спасибо, глянул - мне понравилось, вроде даже Cygwin не нужен (у меня вечно с ним всякие траблы), скачаю - попробую. А в Lite-версии у них компилятор никак не урезанный? Командной строки мне полностью достаточно.

По меньшей мере заюзали binutils-ы. Но как-то криво - я линкер-ом 5.x до сих на грабли наступаю при пересборке старых проектов. Причем я четко понимал преимущества и особенности IAR-овского UBROF и старался ими не злоупотреблять - именно для лучшей переносимости.