В основном 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'у, и то об этом знаю! Будете дальше спорить?

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

Абсолютно согласнен со сказанным. Еще неизвестно что полезней. Более строгий стиль написания или чрезмерно умный компилятор? А эффективность сгенерированного кода может с успехом быть выше на gcc, тому есть подтверждение даже на этом форуме - пару месяцев назад пробегавшая здесь ветка о USB драйвере для AVR.


На мой взгляд, единственное неоспоримое преимущество IAR состоит во встроенной поддержке 64-битной арифметики с плавающей запятой.

Добавлю, автоматическая генерация lpm, при модификаторе _flash,
в gcc надо с этим шаманить.

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

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


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


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

Спорю. Не всегда.
Мне очень часто приходиться переносить код с других компиляторов под gcc, и работу и либы, так вот - после всего этого CV и ImageCraft я за серьезные продукты не считаю. С IARом же бабушка надвое сказала - может быть выигрыш и в ту и в другую сторону - зависит от конкретного кода. defunct уже привел пример с USB драйвером. Я к сожалению примера привести не могу, но как только напорюсь на подобный случай обязательно задокументирую и приведу. Вместе разберем на глазах у общественности.
Дело в том, что gcc в 90% случаев просто не даст собрать кривой код.
По умолчанию он чрезвычайно педантичен. Когда я пару лет назад перескакивал на него с IAR, волком выл - нихрена не работало. Все время в листинг приходилось лазить. Зато через год почувствовал насколько я стал лучше писать. В общем это как ручное переключение передач и коробка-автомат - можно спорить до хрипоты, но налицо просто два разных подхода, дело вкуса.

Если попереносить код с gcc на другие компиляторы, там тоже такого понавылазит, что мало не покажется - там одних gcc'шных расширений до и больше. И будут говорить (и говорят - почитайте архивы su.c-cpp), что gcc дерьмо, писанный в нем код нихрена нигде без доработки напильником не работает. А на деле все упирается в элементарную портабельность. Портабельный код работает везде.


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


Улыбаете. Да куда ж он денется. Приведите пример кривого кода, который компиляется, например, в IAR'е и не компиляется в GCC?


Заблуждение. Я когда начинал писать на том же IAR'е, тоже постоянно в листинг смотрел (благо, листинг у него человеческий, а не как у gcc), и частенько находил там причину не того поведения, которого ожидал. А главная причина этого была в том, что в те времена сам еще тот же С толком не знал. Когда поработал годок-другой, когда скилл подрос, так и писать сразу хорошо стало получаться. Потом то, что пробовал на gcc, все сразу получалось без вопросов. Основные вопросы при знакомстве с gcc были - это дурацкая документация (по сравнению с коммерческими продуктами), дурацкий, запутанный, загроможденный формат файла листинга (после IAR'а так вообще ломало, благо ситуацию можно было несколько исправить применением sed'ового скрипта для удаления лишнего и форматирования оставшегося), оригинальный подход при задании сегментов линкеру - когда там все разные адресные пространства отмаплены на одно, и другие более мелкие вопросы. Но с кодогенерацией и работоспособностью кода никаких проблем уже не было.

Т.ч. не надо тут сравнений про коробки передач, мимо кассы они. Горбатый код на IAR'е точно так же не работает. Посмотрите, сколько вопросов про IAR тут задают, вечно у кого-то что-то не работает (у новичков, по большей части, которые просто еще не научились, и пишут тот самый кривой код). Про gcc вопросов на порядок меньше - косвенно это указывает совсем на обратное, утверждаемому Вами. Конечно, это объясняется в первую очередь, что пользователей gcc гораздо меньше, а новички по больше части западают на более дружественный и простой в основении IAR. Но при прочих равных компиляторы эти по требовательности к качеству исходного кода примерно равны и определяется это следованием Стандарту - любой компилятор, выполняющий требования Стандарта, будет примерно одинаково реагировать на кривой код - либо ругаться на ошибки, либо генерировать код с неопределенным поведением.

Именно так дело и обстоит - могу свидетельствовать после многолетней работы на разных платформах под разными компиляторами.
Ну а сравнивать реакцию на 'кривой' код можно только при всех активизированых warnigs и remarks.
Практически весь сыр-бор разгорается из-за какого-то проекта с задваленными warnings и нюансами
трактовки warning/error конкретным компилятором.

Это было бы замечательно!

Там откровенный гон приведен. IAR мне выдал 118 байт при оптимизации по скорости и 110 - по размеру.

IAR
Командная строка (по скорости):
%IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --cpu=m16 -ms -s9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib --diag_suppress=Pe951

Вывод компилятора:
IAR Atmel AVR C/C++ Compiler V4.12A/W32, Evaluation Version
Copyright 1996-2005 IAR Systems. All rights reserved.

118 bytes of CODE memory
0 bytes of DATA memory (+ 3 bytes shared)

Errors: none
Warnings: none


Командная строка (по размеру):
%IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --cpu=m16 -ms -z9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib --diag_suppress=Pe951

Вывод компилятора:
IAR Atmel AVR C/C++ Compiler V4.12A/W32, Evaluation Version
Copyright 1996-2005 IAR Systems. All rights reserved.

110 bytes of CODE memory
0 bytes of DATA memory (+ 3 bytes shared)

Errors: none
Warnings: none


WinAVR 20060421
Командная строка:
avr-c++.exe -c -mmcu=atmega16 -g -O3 -Wa,-adhlms=slon.lst slon.cpp

Поскольку компилятор не утруждается выводом статистики по размерам использованных данных и кода ни при выводе, ни в листинге, то приходится использовать утилитку:

avr-size.exe slon.o

Ее вывод:

Насколько я знаком с gcc, секция text - это и есть код. Т.е. 258 байт. Что-то много. Оптимизация максимальная.

Снижаем оптимизацию до O2 получаем:



Намного лучше. Другие виды оптимизации дают тот же результат. Без оптимизации:


Совсем плохо. Вывод - работать, видимо, надо с O2. Но такой дикий разброс - в два раза выглядит очень странно! Зато логично выглядит замечание коллеги beer_warrior'а, что с gcc надо держать ухо востро - на IAR'е я выставил максимальную оптимизацию и забыл про проблемы - получаю всегда самый лучший код. А за этим надо следить - как бы он чего не напакостил. Вряд ли это обстоятельство можно отнести к достоинствам компилятора.

118/130 - 10%
110/130 - 15%

Где-то так оно и есть. Хотя по такому мелкому тесту судить, конечно, нельзя.


Прошу прощения за некоторую резкость, но выглядело это именно так.


Это похоже на "моя машина плохо берет подъемы, поэтому в подъемы я стараюсь не ездить".

Пользую GCC в связке с AVRStudio

quote]Совсем плохо. Вывод - работать, видимо, надо с O2. Но такой дикий разброс - в два раза выглядит очень странно![/quote]

# Optimization level, can be [0, 1, 2, 3, s].
# 0 = turn off optimization. s = optimize for size.
# (Note: 3 is not always the best optimization level. See avr-libc FAQ.)[

So generally, it seems -Os -mcall-prologues is the most universal "best" optimization level. Only applications that need to get the last few percent of speed benefit from using -O3.

Большинство проектов выполнял на ASM, из плюсов - максимальное быстродействие, полный контроль над МК, отсутствие проблем с постоянным поиском новых версий компиляторов. Из минусов - бОльший объём исходных текстов. Отладка проводится в основном на живом железе, иногда, в сложных случаях, использую Studio. Для работы с текстом пользуюсь FAR, с расцвечиванием для AVR. Встроенный редактор Studio кривоват (IMHO).

182*2 = 364 байта.
что более чем втрое больше кода, сгенерированного IAR'ом и
почти втрое больше кода сгенерированного gcc (-02 не лучшая оптимизация).

Для теста скомпилировал один из своих проектов с большим числом мат. расчетов в IAR без оптимизации (BEST DEBUG) с поддержкой 64 бит double объем HEX файла - 11 555 байт
ICC с оптимизацией (естественно с 32 бит double) - 21 702 байт

По поводу компилятора. Попробовал переписать на ASM хороший кусок линейного кода IAR C (без использования сложной арифметики). Результат кропотливой оптимизации не превысил 35%. Некоторые куски компилируются в более оптимальный код!!!! Этого я не ожидал.

По поводу AVR123. Я считаю что Вы делаете нужное дело. Не страшно что есть ошибки! Не ошибается тот, кто ничего не делает! А вот рекламы надо поменьше. Все уже от неё устали и поэтому злятся. Переключитесь на время на Точку Опоры. Там новичков побольше. Переговорите с webmasterom Точки Опоры может они Ваш курс включат в свои ссылки. И пожалуйста, не принимайте мои слова за критику, но моё мнение что навигации в Вашем курсе всётаки не хватает. Мало чайников найдётся чтобы запоем читать. А вот отдельные моменты, - это пожалуйста.

На окончательное мнение не претендую.

asm("nop")?

asm volatile("nop")

Итак наш ответ Чемб... простите DXP
IAR и WinAVR у меня другой версии, так что результаты получились несколько другие:
IAR :
last flash byte address = 0x00BF
last flash word address = 0x005F
GCC:
; last flash byte address = 0x00D3
; last flash word address = 0x0069
0xD3 - 0xBF = 0x14 = 20
Итак мне стало интересно на чем набежала разница.
Из-за отличия в листингах я собрал все в два hex и подсунул в оба ReAVR.
Результат прилагаеться:
Не буду утомлять листингом он прокомментирован. Мы имеем функцию main() и вызываемые из нее LEDon() и Delay(), кроме того имеем начальную инициализацию(Cstartup) и таблицу векторов прерываний.
Итак функция main() сделанная gcc в лоб - 41 команда. IAR который вынес пролог и два фрагмента в подпрограммы - 42 команды. Delay() решение одинаковое 5 команд. LEDon() - gcc 12 команд одним куском, IAR 7 + 5 подпрограмма. Инициализация стека - оба по 12 хотя IAR без RCALL не может. Ну с векторами вопросов нет - одинаково.
Итак в чем же разница - а вот в чем - GCC включает код для инициализации глобальных переменных.
В простом тесте их нет и соответственно IAR идет на обгон, там где они появляются и IAR включает подобный код. В принципе это дело можно в gcc и поскипать, о какая в том надобность.
Если отбросить стартап - на исполняемой части gcс выигрывает одну команду без бесконечных прыжков по коду. Ассемблерный код красивый ясный и быстрый.
Правда надо отдать должное IARу - красивая замена rcall на rjmp хорошо экономит стек, так же вызов пролога сделан намного лучше чем в gcc

Листинги

А вот что у меня получилосьОднако gcc не идеален, потому сделаем тактогда - нет двойной установки стекаВывод ИМХО: iar и gcc - достойные компиляторы, в отличии от CodeVisionAVR.

С этими ключами результат ровно тот же.

Если в IAR'е main квалифицировать словом __task, которое именно для этой функции в первую очередь и предназначено, то результат будет 114 и 106 байт соответственно.

В avr-gcc 4.0.3 - 118 байт, выше был 3.4.6

Будьте так любезны vesago(собачка)rambler.ru

С AVR знаком с пару месяцев - пришлось использовать как сопроцессор. Сначала попробовал IAR. После Кейла крайне не понравился. Дискомфортно. Поставил CVAVR. Игрушка какая-то. Вобщем вернулся в IAR. Сейчас уже пообвыкся, даже стал получать удовольствие. Чувствуется - вещь! Отлаживать пробовал в симуляторе студии. Но какая-то убогая она. Если надо алгоритм, то отлично и в яре можно. В студии, допустим, мне не представляется возможным отладить протокол усарта полноценно. TWI не прошел. Из яра когда инициализирую регистры сфр, фигню какую-то грузит, хотя работает првильно. В общем надо поскорее жтаг собирать. Протеус странная прога. Устройство на меге 128 в железе работает. В Протеусе вообще не дышит. Вроде и питание завел и прошивку подкрузил - не работает хоть тресни. А вообще из сред Кейл вне конкуренции имхо.