Какую среду разработки Вы используете? Опции

[defunct]

Давно мечтал услушать все "за" и "против", о популярных средах программирования для AVR uC.
Всех сред разработки я знать не могу
поэтому если в списке Вы не нашли того с чем работаете, указывайте ее в сообщениях

Сам я использую в основном AVR-Studio в комбинации с gcc, из-за наиболее, на мой взляд, удобного отладчика, который отображает значения переменных/регистров в всплывающих подсказках прямо в тексте отлаживаемых модулей, а также из-за эмулятора, предоставляемого разработчиком uC, доверее к которому много выше чем к эмуляторам сторонних разработчиков.

В IAR-е помоему отсутствует такая возможность, сколько не ковырялся в настройках так и не нашел где можно включить отображение значений переменных в режиме отладки, или я не прав?
Хотя код сгенерированный IAR'ом и получается меньшего объема, но удобная отладка как для меня важнее..

Сообщение отредактировал defunct - Feb 1 2006, 21:56

[beer_warrior]

2 DXP
Все верно, однако...
Не вижу я большой в этом беды.
Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?
Ну да в *printf(), ну так сколько об этом говорено.
С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?
Все это небольшое преимущество (?) убьеться на корню просто наличием каких-то левых переменных, лишними вызвами функций итп.
Чем мне нравиться gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок. Но это, как я уже говорил, дело вкуса.

[dxp]

2 DXP
Все верно, однако...
Не вижу я большой в этом беды.

А я не утверждаю, что в этом какая-то большая беда. Я лишь спорил с утверждением, что AVR-GCC генерит более компактный и быстрый код нежели IAR. Это совсем неверно, за IAR'ом приоритет. Надеюсь, Вы не спорите с этим тезисом?

В свое время оценивал качество кодогенерации IAR, AVR-GCC и ImageCraft. На первом месте IAR, на втором AVR-GCC, на последнем оказался ImageCraft. Еще народ сравнивал с CodeVision, утверждают, что этот соответствет ImageCraft'у. Таким образом, из распространенных компиляторов для AVR по качеству кодогенерации AVR-GCC прочно удерживает второе место. Почетное второе место - некоммерческому проекту тут с IAR'ом тягаться сложно.

Например, если передавать в функцию больше 3 параметров... может стоит в в консерватории, что-то подправить?
Ну да в *printf(), ну так сколько об этом говорено.
С другой стороны ldd/std займет указатель - выигрыш во времени, проигрыш в регистрах. Вы уверены, что вам этот регистр в функции не понадобится?

Речь идет не только и не столько о передаче аргументов через стек, сколько об использовании локальных объектов внутри функции. Вот, например, объявлен внутри функции пяток переменных - пара интов, один флоат, мелкая структурка-враппер, которую возвращает одна из вызываемых функций и/или юнион. Регистров на это не хватит - они и так для работы нужны, поэтому разместится это в стеке. И тут нужна эффективная работа со стеком. В IAR'е все прозрачно - Y-pointer непосредственно все это адресует. В случае же avr-gcc компилятор будет производить ту самую подготовку стекового кадра (stack frame) - копирование в критической секции значения SP в Y, модификация SP, чтобы он указывал за пределы выделенного стекового кадра (чтобы было куда адреса возвратов складывать и оно не перемешалось с данными выделенного стекового кадра). Похожую операцию делает, например, комплитор для Blackfin'а, но у этого проца есть специальная инструкция подготовки стекового кадра - link N (где N - размер кадра), для нее есть парная инструкция unlink. А AVR-GCC эти вещи делает сам. Оверхед налицо. И порой не мелкий.

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

Хороший и высококачественный инструмент - совсем не повод писать безобразный и горбатый код. Код всегда надо писать идеологически правильный, чтобы не было сюрпризов. И еще надо знать "повадки" компилятора, чтобы добиваться устойчивого по предсказуемости результата. Т.ч. тезис "gcc - не прощает небрежности, держит в тонусе, IAR же из-за своего ума позволяет расслабляться, что может стать источником трудноуловимых ошибок" мне не понятен. Если писать криво, с хаками, использовать код, приводящий к неопределенному поведению и т.д., то при любом компиляторе будет плохо. Если писать грамотно, с пониманием требований языка и особенностей реализации, то при любом компиляторе будет хорошо. Только с IAR'ом будет лучше, чем с AVR-GCC. Насколько лучше и кому это надо - это другой вопрос.