....РРРРР.... Ваша реклама слала СЛИШКОМ надоедливой. Навязчивость ресурса уже напоминает спам центра американского английского.

по теме: использую CV, жаль он не поддерживает C++. Отлаживаю только в железе.

Опрос показывает, что наиболее популярными являются среды IAR и СodeVision.
Интересно а какой процент народу пользуют лицензированные, легальные, а не крякнутые
данные среды разработки. И как относится заказчики к ПО для AVRов написанном в
ломанных IARах и CodeVisionах. Наши очень отвратительно, поэтому мы пользуем GCC.
Пусть похуже IAR, но не ломанное.

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

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

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

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

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

От себя хочу добавить, что CodeVision действительно самый простой в использовании и всю черновую работу (такую как: доступ к flash, доступ к eeprom и т.д.) делает за за кадром. Чем очень помогает начинающим разработчикам.

Сообщение отредактировал Serg79 - May 24 2006, 09:12

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

В основном CrossWorks+Jtag, симуляторам предпочитаю железо. Если проект на асме, то AVRStudio.

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


Да, в доке на оболочку, в разделе про С-Спай. Куда уж более сжато?


Пардон, это совсем не то! Речь идет про моделирование, а то, что Вы упоминаете - это мониторинг. Т.е. это ближе к эмуляции, но только более бедно по возможностям и требовательно по ресурсам.


Опять мимо кассы. Это все равно, что моделировать систему с помощью тестбенча в Active-HDL или Modelsim по сравнению с Quartus Simulator. В первом случае все работает САМО, можно просто прогнать на автомате и посмотреть результат (по ходу дела можно лог генерировать, чтобы после прогона отследить выполненные действия), а во втором случае надо ручками останавливаться на определенном такте, анализировать ситуацию и формировать воздействия руками же. Учитывая, что моделирование производится не один раз, а до тех пор, пока все вопросы с отладкой не сняты, этот ручной способ выходит крайне трудоемким и чреватым ошибками. Т.е. совсем не подходит.

Для получения возможности проведения описанного способа моделирования симулятор должен иметь специальный движок. В С-SPY он есть. В названных Вами его нет. А предлагаемые варианты - не более, чем костыли.

О чем Ты говоришь:
// используем '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) это полное расточительство и дополнительный код и время на его обслуживание.

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

Только попробуйте пару переменных почитать/пописать в иаре - он (ИАР) их обычно старается рядом положить и работать через Z+смещение, загрузив Z _ОДИН_ раз. Далее все быстро и качественно.Гнусю, к сожалению, такое слабо.



Отдельный регистр - это к сожалению хрень. Однако, создавать каждый раз в стеке фрейм, как это делает GCC, очень плохо. Т.е. палка о двух концах - хотя при малом объеме локальных переменных освобождается один индекс (в GCC), как только локальные вары перестают лезть в регистры - начинается волшебство да такое страшное . Вообщем, это больше проблемы архитектуры AVR, а каждый компилятор решает ее по своему...

В среднем, на больших проектах, IAR лучше GCC. Хотя, можно извратиться так, что GCC окажется на первом месте

Тут как говориться дело вкуса и привычки. я например пишу на чистом С нечто С++ подобное, т.е. свободных переменных нет - они все собраны в структуры. И все тип-топ. Просто, когда хорошо представляешь, что пишешь, компилятор и обрабатывает соответсвенно. Видел случаи, когда перенос на gcc давал до 30% экономии.
За счет оптимизатора? Нет. За счет стиля написания.

Ну да. Стиль имеет гораздо большее значение, чем можно было бы думать.
О пользе косметики

ld r18,Z+
или
ld r18,Z+k

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

Это если по шагам идти. А можно и сразу прогнать весь фрамент, а потом лог смотреть, что происходило.

К тому же, Вы не про то говорите - Вы говорите о том, что взвести флаг глобального прерывания. А я про возникновение прерываний во время выполнения интересующего. Т.е. флаг глобального разрешения прерываний устаравливается программно на входе в ISR - разрешаются вложенные прерывания. А теперь надо промоделировать возникновение другого прерывания во время выполнения текущего (прерывания разрешены уже в этот момент). Понятно, что и тут можно руками, в этом-то разница и состоит - один инструмент позволяет автоматизацию, другой нет. Если для Вас эта разница несущественна, то и говорить не о чем. Для меня существенна.

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

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



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