Кейл против GCC для ARM7?

должно быть возможно структурировать код для использования обоих компиляторов. Атрибуты, такие как" упакованные", могут быть макросами, поэтому код счастлив под обоими. Нажмите аппаратные детали вниз на более низкие уровни и настройте аппаратные карты во время выполнения вместо времени компиляции. Если у вас должны быть отдельные версии кода Kiel и GCC, поместите их в отдельные файлы и настройте, что используется с файлом проекта gcc make или Kiel.

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

преимущество работы с GCC заключается в том, что вы можете ориентироваться на платформы без ARM-идеально подходит для моделирования вашего приложения на платформе с гораздо лучшими инструментами разработки (т. е. valgrind под x86 linux). На самом деле, это подход каждый ARM-целевое приложение должно занять. Разработать на x86-первых, то порт РУКА.

есть также стоимость пребывания в курсе с Килем. Однажды место, которое я знаю, застряло на RVDK 2.1 (2002?) потому что стоимость обновления до последней для трех разработчиков непомерно высока.

Я бы также добавил, что gcc & pedantic вытряхнет предупреждения и ошибки в вашем коде намного лучше, чем наша (по общему признанию, древняя) версия Киля.

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

Если я правильно помню, Киль теперь принадлежит ARM. Компиляторы ARM днем и ночью лучше, чем gcc для создания хорошего кода. Кажется, я помню Кейла, включая сокращенную или бесплатную или любую другую версию rvct. Так что мой вопрос имеет гораздо быстрее, чище, лучше код стоит использовать коммерческое решение, когда gcc там и хорошо используется? Я бы пошел с gcc, если вы не находитесь в ситуации хруста производительности и готовы мысленно переводить между всей информацией, основанной на gcc свободно доступный в сети для ваших коммерческих инструментов и обратно. В общем, идти с gcc, вероятно, лучший путь, при условии, что, вероятно, есть много информации за полем поиска google для Киля, но объем знаний и информации для решений на основе gcc тени, что.

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

основным преимуществом коммерческого решения является поддержка меня, если вы столкнулись с проблемами с компилятором или библиотеками.
С открытым исходным кодом хорошо, когда вы используете оборудование основного потока (в случае gcc = x86). Большинство проблем компилятора или библиотек обычно будут исправлены очень скоро сообществом.
Если вы развиваетесь на (возможно, экзотической) встроенной платформе, вы скоро почувствуете себя довольно одиноко, если у вас возникнут проблемы с цепочкой инструментов.

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

FYI, если ваш проект будет использовать Keil RTOS, и у вас есть какие-либо вопросы об этом, исходный код доступен для покупки.