Все претензии к ядру. Можно написать программу из 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 пока не сравнивал).

Сообщение отредактировал SimpleSoft - Aug 27 2010, 14:49

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

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

Сообщение отредактировал SimpleSoft - Aug 27 2010, 19:10

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

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

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

Сообщение отредактировал SPACUM - Aug 28 2010, 12:29

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

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

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

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