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

[defunct]

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

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

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

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

[Guest_Serg79_*]

О чем разговор!!!
Для сборки прошивки лучше чем WinAvr(gcc) вы не найдете.
Для написания кода и отладки, связка AVR-Studio + gcc-plugins да плюс JTAG это все что нужно.
А кто знает что такое Linux, так ему и объяснять не надо что такое 'gcc' и как он может код оптемизировать хоть по размеру, хоть по быстродействию.

CodeVision просто отстой, то что он делает с указателями не поддается описанию, один ужас. Он даже не знает, что такая каманда у AVR есть как ( ICALL ). А как он код раздувает, просто ужас, и быстродействие его просто ужасное.

IAR-EWAVR на счет того что он быстрее и компактнее тоже заблуждение.

У 'gcc' один минус, он тяжелый для новичков, особенно когда надо вставку на 'asm' сделать, их это вводит просто в ступор :-). Но что либо гибче чем gcc просто не сушествует.

Кто мне не верит, пускай посмотрит как каждый компилятор пишет на 'asm' тогда убедиться, что лучше 'gcc' ему ни чего не найти.

[dxp]

IAR-EWAVR на счет того что он быстрее и компактнее тоже заблуждение.

IAR EWAVR дает более компактный и быстрый код! Спорить не надо, это проверено неоднократно. Для компактности кода AVR-GCC должен для начала научиться почаще пользоваться косвенной адресацией, а не лепить везде lds/sts, а для скорости - ввести все же раздельные стеки для данных и адресов возвратов, чтобы не геморроиться с подготовкой стекового кадра в каждой функции. Этот же момент напрямую влияет и на размер кода. Если и еще вопросы, но эти два - основные.

[Guest_Serg79_*]

IAR-EWAVR на счет того что он быстрее и компактнее тоже заблуждение.

IAR EWAVR дает более компактный и быстрый код! Спорить не надо, это проверено неоднократно. Для компактности кода AVR-GCC должен для начала научиться почаще пользоваться косвенной адресацией, а не лепить везде lds/sts, а для скорости - ввести все же раздельные стеки для данных и адресов возвратов, чтобы не геморроиться с подготовкой стекового кадра в каждой функции. Этот же момент напрямую влияет и на размер кода. Если и еще вопросы, но эти два - основные.

О чем Ты говоришь:
// используем 'lds'
lds r18,$01FF ( 2-такта, 4-байта )

// используем косвенное чтение
ldi r26,$FF ( 1-такт, 2-байта )
ldi r27,$01 ( 1-такт, 2-байта ) // подготавливаем Х
ld r18,X ( 2-такта, 2-байта )
//Вот и смотри что быстрее и компактнее.

На счет использования стека:
параметры в функцию передаются через регистры r25-r8, если не хватает передается через стек (исключение: функции с переменным количеством аргументов (printf()) всегда через стек).
Возврашает значение: 8-бит в r24 (не r25!), 16-бит в r25:r24, 32-бита в r22-r25, 64-бита в r18-r25.
Регистры которые можно свободно использовать (r18-r27, r30-r31), которые следует сохранять (r2-r17, r28-r29) если их используешь.

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

А что ты называешь стековым кадром, наверное только тебе известно.
На счет отдельного стека для данных это полный маразм. Выделять отдельный указательный регистр (X, Y или Z) для ведения стека данных (в CodeVision используется для этих целей Y) это полное расточительство и дополнительный код и время на его обслуживание.

Если есть что возразить, Я слущаю.

[dxp]

О чем Ты говоришь:
// используем 'lds'
lds r18,$01FF ( 2-такта, 4-байта )

// используем косвенное чтение
ldi r26,$FF ( 1-такт, 2-байта )
ldi r27,$01 ( 1-такт, 2-байта ) // подготавливаем Х
ld r18,X ( 2-такта, 2-байта )
//Вот и смотри что быстрее и компактнее.

Ок, теперь напишем аналогичный код обращения к памяти для int, long, float, int* и т.д. и т.п. - для типов, у которых sizeof(type) >= 2. И посмотрим, к каким объектам в реальной программе идет обращение. К 8-битным или более? Вы с IAR'ом-то работали реально? Возьмите какую-нить программку и скомпилите в том и другом. Результат сравните. Я в свое время сравнивал, AVR-GCC был 2.95 и какой-то из 3.хх, поведение в них одинаково. У IAR с версий 2.хх появилась весьма неплохая оптимизация Clustering variables, когда компилятор складывает переменные, к которым идет смежное обращение, рядом, что позволяет только ОДИН раз загрузить БАЗОВЫЙ (для всех них) адрес и обращаться к ним со смещением ldd/std. Экономия выходит весьма ничего себе!

В общем, я в свое время сравнение проводил, причины исследовал, имею основания так считать. Другие люди тоже сравнивали - пришли к такому же выводу. Даже в этом форуме приводили примеры по размеру кода - IAR всегда выигрывал с заметным отрывом.

На счет использования стека:
...
А что ты называешь стековым кадром, наверное только тебе известно.
На счет отдельного стека для данных это полный маразм. Выделять отдельный указательный регистр (X, Y или Z) для ведения стека данных (в CodeVision используется для этих целей Y) это полное расточительство и дополнительный код и время на его обслуживание.

Если есть что возразить, Я слущаю.

Если Вы не знаете, что такое стековый кадр у avr-gcc, то я Вам сочувствую. Хорошо, объясню: у AVR совершенно убогий указатель стека (SP), он не позволяет эффективно работать с данными в стеке, он не умеет адресоваться со смещением, он не поддерживает эффективных операций адресной арифметики. Поэтому эффективным решением проблемы было выделение под указатель стека данных одного из аппаратных указателей - например, Y. Что и сделала IAR. Конечно, укзателя жаль, тем более, что нормальных их там всего два. В этом состоит еще один кривой момент AVR. Наличие нормального указателя стека позволяет эффективно работать с данными в стеке - локальными объектами и аргументами, которые не влезли в регистр и переданы через стек. В AVR-GCC пошли по традиционному пути и получают весь геморрой от этого - при входе в функцию, если надо эффективно поработать с данными в стеке, значение указателя стека копируется в тот же самый Y-pointer и работа происходит уже с ним. При копировании SP в Y еще и надо прерывания запрещать (а после копирования восстаноавливать значение бита глобального разрешения прерываний, т.е. помещать этот код в критическую секцию), чтобы эта неатомарная операция не была прервана каким-нибудь прерыванием и не нарушилась целостность работы программы. Это дополнительные накладные расходы и по коду, и по быстродействию... Как же Вы работаете с AVR-GCC, если всего этого не знаете? Я вот не работаю, а только исследовал причины проигрыша AVR-GCC IAR'у, и то об этом знаю! Будете дальше спорить?