[Evgeny_CD 0]

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

 

Что касается среды - http://www.eclipse.org/ ок.

 

С Армами все понятно. Там GCC рулит. Сами проверяли, инфы есть много на эту тему.

 

Но вот для AVR (иногда надо делать "контроллеры светодиодов" за 1.5$) никогда не пробовал subj. Каково мнение народа?

 

http://winavr.sourceforge.net/

[pulsar-17 0]

Мнение хорошее.

Компилятор делает хороший код, но иногда надо ему "помогать", писать исходник разбиваая сложные расчеты на несколько простых, явно перобразовывать типы (особенно char), учитывать, что AVR восьмиразрядный и лишние операции ненужны(по умолчанию int 16 бит). Причуды тоже есть, например иногда два ret в конце функции ставит... Но это компенсируется большим количеством всевозможных чисто GNUшных фич, морем всевозможных утилит, библиотек и хорошей документацией на все это.

[ReAl 0]

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

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

Слегка прошёлся - и выглядеть стали "читабельнее", и объём загрузочного файла сократился с 6 до 5.5К. Это при том, что там ещё куча строк для выдачи на отладочный терминал.

 

Но вот для AVR (иногда надо делать "контроллеры светодиодов" за 1.5$) никогда не пробовал subj. Каково мнение народа?

 

http://winavr.sourceforge.net/

<{POST_SNAPBACK}>

Несколько лет только им и пользуюсь. Проигрывает ИАР-у по объёму кода где-то на 5--20% в зависимости от задачи, стиля, ... (хотя последняя пара, которую сравнивал - что-то типа gcc 3.0.2 и иар 2.27).

[Гость impatt]

avr-gcc штука классная, причём не надо тырить у IAR ничего, и никаких лекарств от запоров - тоже не надо. Что мне не понравилось - в коде обработчика прерывания GCC разрешает эти самые прерывания. Ну, ладно бы отключаемая функция была... А то код получается не совсем совместимый с проектами под, например, IAR. Пример: обработчик прерывания по достижению некоего числа таймером №1. Один чел написал код на IAR для реализации ШИМ, и сперва разрешил прерывания, а потом взялся настраивать таймер. Когда в обработчике прерывания не разрешены (IAR), то ничего страшного не происходит, а вот под GCC.. Контроллер уходил в обработчик немедленно после старта, потом входил повторно и так до упора, пока не переполнится стек, а потом вис нахрен. Ессно, расхваливаемый многими симулятор на AVRStudio работает криво (как мне показалось) и пришлось голову поломать, чтобы оживить ранее работоспособный проектик..

[sensor_ua 0]

Вот пробую под eclipse AVR-GCC4.0.2 сборки klen.org. Об эффективности пока сказать не могу, но уже приятно, что как-то работает;)

[misyachniy 0]

impatt

В GCC есть SIGNAL () и INTERRUPT().

Разница между ними в наличии команды sei() в INTERRUPT().

[Гость impatt]

impatt

В GCC есть SIGNAL () и INTERRUPT().

Разница между ними в наличии команды sei() в INTERRUPT().

 

Спасибо, не знал. Теперь узнал и вздохнул с облегчением (я не шучу). Пользуюсь.

Уверен, что всё это описано в доке, но там всё на чисто англицком языке. Ессно, когда читаешь одно слово через три, пропустить немудрено.

Ещё раз благодарю.

[m16 0]

Мнение хорошее.

 

но иногда надо ему "помогать"

 

если вы не хотите помогать компилятору, а наоборот ожидаете от него помощи то возьмите на [banned] - великолепный компилятор - программатор CodeVisionAVR (2Мб всего !) и дополните его бесплатным симулятором VMLAB (4Мб)

 

и просто насладитесь работой! вот примеры http://electronix.ru/redirect.php?http://[banned]/avrpic06.htm

Уважаемый, все Ваши полсотни постов как близнецы-братья содержимое которых сводится к одному - раскрутке собственного сайта но никак по сути поставленного вопроса , имхо

[beer_warrior 0]

Пользуюсь с 2003 года.Жалоб нет.

Надо немножко приноровиться (например как с SIGNAL/INTERRUPT),

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

По оптимизации - местами проигрывает IAR, местами выигрывает.

[haker_fox 60]

Мнение хорошее.

 

но иногда надо ему "помогать"

 

если вы не хотите помогать компилятору, а наоборот ожидаете от него помощи то возьмите на [banned] - великолепный компилятор - программатор CodeVisionAVR (2Мб всего !) и дополните его бесплатным симулятором VMLAB (4Мб)

 

и просто насладитесь работой! вот примеры http://electronix.ru/redirect.php?http://[banned]/avrpic06.htm

 

:bb-offtopic: Я использовал CodeVision. Да, неплохой компилятор. Как и все остальные. Но ничего особо замечательного я в нем не ощутил. Помощи он мне тоже ни какой не дал, что же можно от него ожидать, это ведь просто программа. Многим нравиться этот инструмент тем, что он поставляется с библиотеками для работы с ds18b20, hd44780 и другими приборами. Но мне, например, кажется что ничего особенного в этом нет. Еще не известно как написаны эти библиотеки. Да и лучше такие вещи, даже на начальных порах писать самому, потому что это повышает Level-up.

Симуляторы, такие, как VMLab & Proteus можно конечно использовать, но не стоит им полностью доверять. Все таки симулятор он и есть симулятор.

[halfdoom 0]

И понял, что альтернативы GNU / GCC нет - ибо, например, покупку IAR, считаю бессмысленной.Но вот для AVR (иногда надо делать "контроллеры светодиодов" за 1.5$) никогда не пробовал subj. Каково мнение народа?

Тут все просто - если памяти программ в избытке, и можно поступиться быстродействием, то GCC это

хороший выбор. ИАР выигрывает у GCC по всяким мелким оптимизациям (исключение лиших загрузок

регистров, использование X и Z регистров для доступа к памяти даже без явного описания указателей

в программе) и наличием cross-call оптимизации.

 

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

обоих компиляторов и с тех пор использую оба в зависимости от требований и наличия внешних

библиотек (которые править не желательно).

 

BTW, я также отказался от использования make и перешел на jam. С использванием средств jam'a можно писать

такие вещи:

rule target_gcc161 {
    tool_gcc;

    MCU_FULL =    atmega161;
    MCU_PROGR =    Mega161;
    MCU_SHORT =    m161;

    CCOPT_TYPE    = speed;
    CCOPT_LEVEL    = 2;
....
}

rule target_iar161 {
    tool_iar;

    MCU_FULL =    AT90Mega161;
    MCU_PROGR =    Mega161;
    MCU_SHORT =    m161;

    CCOPT_TYPE    = speed;
    CCOPT_LEVEL    = 9;

    CCFLAGS += --do_cross_call  --cross_call_passes=5;
}

А затем просто указывать "jam iar161" или "jam gcc161".

[Laksus 0]

misyachniy

Jan 13 2006, 18:12

impatt

В GCC есть SIGNAL () и INTERRUPT().

Разница между ними в наличии команды sei() в INTERRUPT().

____________________________________________________________

impatt

...Уверен, что всё это описано в доке,...

____________________________________________________________

____________________________________________________________

Функции обработки прерываний SIGNAL() & INTERRUPT()

были до версии WinAVR-20050214-install.exe

прописаны в

...\WinAVR\avr\include\avr\signal.h

и описаны в

...\WinAVR\doc\avr-libcavr-libc-user-manual-1.2.3.pdf

_________

Но с версии WinAVR-20060125-install.exe

в

...\WinAVR\doc\avr-libc\avr-libc-user-manual-1.4.3.pdf

функция INTERRUPT() объявлена deprecated (осуждаемой)

и в файлах не прописана. Дескать, (стр.45...-1.4.3.pdf)

"As this macro has been used by too many unsuspecting people in the past, it has been

deprecated, and will be removed in a future version of the library. Users who want to

legitimately re-enable interrupts in their interrupt handlers as quickly as possible are

encouraged to explicitly declare their handlers as described above."

"above" - это ссылка на стр.128., где разъясняется как сделать

вложенные прерывания.

_________________

Александр

2006 05 27

[msn 0]

Пользуюсь больше 4-х лет. Особых замечаний не было. После того как добавили поддержку в студии работать стало еще приятнее, про IAR который изредка использовался для откладки кусков кода уже забыл. Есть правда пара мелких недочетов: от версии к версии иногда меняются различные часто используемые макросы, переезжают в другое место файлы заголовков, до сих пор нет нормально реализованной printf, иногда не хватает поддержки С++ и не очень удобно размещать массивы строк в Flash. Оптимизации маленьких кодов очень уступает IAR, проврете на замене местами байт в слове.

[msn 0]

Пользуюсь больше 4-х лет. Особых замечаний не было. После того как добавили поддержку в студии работать стало еще приятнее, про IAR который изредка использовался для откладки кусков кода уже забыл. Есть правда пара мелких недочетов: от версии к версии иногда меняются различные часто используемые макросы, переезжают в другое место файлы заголовков, до сих пор нет нормально реализованной printf, иногда не хватает поддержки С++ и не очень удобно размещать массивы строк в Flash. Оптимизации маленьких кодов очень уступает IAR, проврете на замене местами байт в слове.

[SapegoAL 0]

И понял, что альтернативы GNU / GCC нет - ибо, например, покупку IAR, считаю бессмысленной.Но вот для AVR (иногда надо делать "контроллеры светодиодов" за 1.5$) никогда не пробовал subj. Каково мнение народа?

Тут все просто - если памяти программ в избытке, и можно поступиться быстродействием, то GCC это

хороший выбор. ИАР выигрывает у GCC по всяким мелким оптимизациям (исключение лиших загрузок

регистров, использование X и Z регистров для доступа к памяти даже без явного описания указателей

в программе) и наличием cross-call оптимизации.

 

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

обоих компиляторов и с тех пор использую оба в зависимости от требований и наличия внешних

библиотек (которые править не желательно).

 

BTW, я также отказался от использования make и перешел на jam. С использванием средств jam'a можно писать

такие вещи:

rule target_gcc161 {
    tool_gcc;

    MCU_FULL =    atmega161;
    MCU_PROGR =    Mega161;
    MCU_SHORT =    m161;

    CCOPT_TYPE    = speed;
    CCOPT_LEVEL    = 2;
....
}

rule target_iar161 {
    tool_iar;

    MCU_FULL =    AT90Mega161;
    MCU_PROGR =    Mega161;
    MCU_SHORT =    m161;

    CCOPT_TYPE    = speed;
    CCOPT_LEVEL    = 9;

    CCFLAGS += --do_cross_call  --cross_call_passes=5;
}

А затем просто указывать "jam iar161" или "jam gcc161".

 

Вот бы поделился! :)

Я думаю масса людей было бы Вам благодарна.

Я пока не нахожу в себе сил такую работу проделать. :)

Ну и описаний не достаточно. Как-то они разбросаны и беспорядочны.