1. среда разработки (компилятор/транслятор)

[Petka 0]

ну есть проклятые пираты которые вложили PROTEUS 6.9.03 с лекарством

 

я нашел в google.com и опубликовал линки

 

в самом низу страницы - http://electronix.ru/redirect.php?http://[banned]

 

вот как он стыкуется с компиояторами

 

http://www.labcenter.co.uk/products/compilers.htm

 

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

 

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

[EugeNNe 0]

Опрос показывает, что наиболее популярными являются среды IAR и СodeVision.

Интересно а какой процент народу пользуют лицензированные, легальные, а не крякнутые

данные среды разработки. И как относится заказчики к ПО для AVRов написанном в

ломанных IARах и CodeVisionах. Наши очень отвратительно, поэтому мы пользуем GCC.

Пусть похуже IAR, но не ломанное.

[Гость Serg79]

О чем разговор!!!

Для сборки прошивки лучше чем WinAvr(gcc) вы не найдете.

Для написания кода и отладки, связка AVR-Studio + gcc-plugins да плюс JTAG это все что нужно.

А кто знает что такое Linux, так ему и объяснять не надо что такое 'gcc' и как он может код оптемизировать хоть по размеру, хоть по быстродействию.

 

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

 

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

 

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

 

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

[Гость Serg79]

BigBolt временно не имеет доступ к форому, он меня попросил ответить:

и что же у вас за заказчики такие - они есть а 150 баксов на CVAVR у вас нет ?

CodeVision использовали достаточно долго, но особо он не нравился и по это платить за него даже 1руб не хочется, начав использовать WinAVR пришли к выводу, что IAR за 1500$ покупать не стоит. GCC это оптимальное соотношение цены( 0$ ) и качества.

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

Изменено 24 мая, 2006 пользователем Serg79

[dxp 56]

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

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

[VladimirZ 0]

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

[dxp 56]

народ в массе не знаком с возможностями

моделятора IAR C-SPY и нередко плюется от него.

 

А зря.

 

Огромное спасибо за материал ! вот если б кто-то сдела туториал по C-SPY на русском то народ бы к нему потянулся.

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

 

Вы можете назвать документы из инсталяции IAR где это описано ? Только юзергайд ? более сжатого нет ?

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

 

Все что вы рассказали могут делать VMLAB и PROTEUS.

 

PROTEUS может подключать модель МК к реальному COM-порту ПК 1.5 ГГц и работать с внешним устройством или прогой на дуплексе 38400.

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

 

Например, я знаю, что программа находится в прерывании от UART'а на 12530-м такте и выходит из него на 12555-м такте.

 

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

 

Попробуйте это сделать на симуляторе, который честно симулирует периферию.

 

в обоих названых выше симуляторах это делается просто и кошерно.

 

на 12540-м такте останавливаетесь и устанавливаете мышкой флаг прерывания таймера и бит SREG.7 - вот и все.

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

 

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

[Гость 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) это полное расточительство и дополнительный код и время на его обслуживание.

 

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

[Rst7 5]

О чем Ты говоришь:

// используем 'lds'

lds r18,$01FF ( 2-такта, 4-байта )

 

// используем косвенное чтение

ldi r26,$FF ( 1-такт, 2-байта )

ldi r27,$01 ( 1-такт, 2-байта ) // подготавливаем Х

ld r18,X ( 2-такта, 2-байта )

//Вот и смотри что быстрее и компактнее.

 

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

 

На счет использования стека:

параметры в функцию передаются через регистры 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) это полное расточительство и дополнительный код и время на его обслуживание.

 

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

 

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

 

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

[beer_warrior 0]

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

За счет оптимизатора? Нет. За счет стиля написания.

[Bill 0]

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

За счет оптимизатора? Нет. За счет стиля написания.

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

О пользе косметики

[bodja74 0]

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

 

ld r18,Z+

или

ld r18,Z+k

[Bill 0]

А что ты называешь стековым кадром, наверное только тебе известно.

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

 

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

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

[dxp 56]

во втором случае надо ручками останавливаться на определенном такте, анализировать ситуацию и формировать воздействия руками же.

дак выж пишите "сидишь СПОКОЙНЕНЬКО и смотришь что там куда сохраняется"

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

 

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

[dxp 56]

О чем Ты говоришь:

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