Search in topic

Вопрос к знатокам AVR Studio. Прошу помощи.

В том-то все и дело, что на начальном этапе не хочется сразу себя губить простотой, а хочется подойти глубинно к изучению вопроса. Я уже с этим столкнулся когда стал ковыряться с ардуиной.
В авр студио стоит компилятор GCC, в принципе тот же WinAVR. Понимает обычный язык С. В том-то и дело, что сейчас разрабатываю проект под ATmega32, система команд есть, но на ассемблере, на сях в принципе не встречал, тем более под авр студио. Пока что усилинно курю исходники со всяких сайтов, с каждыс днем вопросов все больше😵
Спасибо всем кто откликнулся!

компилятор GCC, в принципе тот же WinAVR. Понимает обычный язык С

Нету в природе “обычного С”.
Если считать “обычным” ANSI C,
то он похож на CVAVR С (что лучше знаю, с тем и сравниваю), наверное, как шведский язык на немецкий.

Отличия именно в том, что все AVR’овские языки заточены под архитектуру процессора. Это сверх того, что все “микропроцессорные” языки заточены под MCU.

ATMega32 - она и в Африке ATMega32; выбирайте себе среду разработки (если хочется глубин глубинских, то присоединяюсь к совету МиГ17 про IAR), курите евонные мануалы, портируйте на него ваш проект - за одно и проект изучите до тонкостей.

Библиотеки, инклайды - это все относится к компилятору; среда-компилятор-библиотеки связаны и порознь их штудировать, или смотреть на инклайды от IAR чтобы вставить их в CVAVR - дело неблагодарное.

Хорошая справка по ассемблеру для АВР есть вот здесь:
dfe3300.karelia.ru/koi/posob/…/avrasm-rus.htm

Книжка вот, на первый взгляд полезная (для средне-начинающего, КМК). Там и язык, и увязка с архитектурой, и некоторые конкретные приложения:
www.programmer-lib.ru/assembler.php

Начинать надо с мигания лампочками, дальше всё в принципе просто. Ща я тут всё всем расскажу и получу много пряников 😃

AVR Studio использует WinAVR, адаптацию GCC под атмеловские процы.
Синтаксис Си соблюден, так что можно спокойно писать на C, как на обычном большом компуке.

Все специфические названия регистров и прочие неизвестные буквы типа ADCSRA, PORTB и прочее - названия портов проца, с которым работаете.

Вот такой вот, например, код на Си:

DDRB = (1<<DDB0) | (1<<DDB1) | (1<<DDB2);

говорит процу, что ноги 0,1,2 порта B будут использоваться как выходы, т.е. к ним можно будет повесить лампочки, например.

А вот такой вот код

PORTB = 0b00000101;
PORTB = 0b00000000;

выведет на ноги 0 и 2 порта B логические единицы, а через 2 клока проца опустит обратно в 0.
Каждый порт (PORTA, PORTB и т.д.) отображен на общее пространство памяти как восьмибитное число. Записав в порт один байт, Вы можете сразу поменять состояние всех восьми ног порта.

Названия всех портов и регистров корректно и правильно определяются в include файлах из сомплекта WinAVR, и всё, что Вам нужно сделать в начале - создать проект и указать тип проца в свойствах проекта.
Дальше берите доку по процу и смотрите, какие там порты каким физическим ногам на корпусе проца соответствуют, какие регистры как называются, и т.д. В Си коде в большинстве случаем можете спокойно обращаться к этим регистрам прямо по именам, указанным в доке.

То есть, пишут там в программе из интернета что-то в регистр ADCSRA - лезете в доку, ищете ADCSRA, видите, что это регистр, контролирующий работу встроенного АЦП, и смотрите, какой бит регистра за что отвечает, и делаете выводы, зачем авторам программы это было нужно.

Вот такой вот код будет бесконечно часто-часто мигать лампочкой на пине 0 порта А:

unsigned int i;
void main(void)
{
DDRA|=0x01;
while(true)
{
for(i=0;i<50000;i++) // пауза
{
asm(“nop”); // ничего не делаем
}
PORTA|=0x01; // зажигаем лампочку
for(i=0;i<50000;i++) // пауза
{
asm(“nop”); // ничего не делаем
}
PORTA&=~(0x01); // гасим лампочку
}
}

Ну а, в принципе, если планируется делать проекты небольшие и незлые, то Си хватит за глаза. Если нужен жесткий контроль над ресурсами проца и 100-процентное их использование, то без ассемблера никуда.
А, вообще, если хочется что-то более-менее серьезное в будущем на проциках делать, то лучше не тратить время на AVR, а сразу начинать с АРМов. Вначале дороже, труднее и дольше, чем AVR, но потом жизнь сииильно легче 😃
Будете возиться с AVR - спрашивайте, помогу 😃

Smalltim, жаль кнопочку “спасибо” только 1 раз нажать можно:)
Спасибо огромное!!! Я все-таки раздобыл себе IAR на всяк случай, пусть будет, но АВР студио мне как-то больше по душе… Книжеца по азму у меня уже давно лежит, чуйствуется что в ближайшем времени придется ее очень штудирен😁 Я еще со школльных лет как-то исторически сложилось кодил на С++ и С, т.к. асму нас не учили отродясь.
До армов вряд ли дорасту, мне обычных риск камней за глаза будет. Пока что помучаю 32ю мегу))

Не для обращения в свою веру, а чисто для общего представления.
Вот так кусок для моргания диодом на на пине 0 порта А создается в CVAVR:

Сначала камень конфигурируется во встроенном туле CodeWizardAVR (тип, частота кварца и ножка “0” порта А на выход:

Дальше Wizard генерирует код инициализации в соответствии со сделанными настройками (всего в данном примере получилось 129 строк, которые я удалил), и заготовку под программный блок main. Бесконечный цикл создается внутри Main автоматически.

Мне остается добавить в этот код 5 строк (мои строки выделены жирным шрифтом; весь тонкий шрифт сделан Визардом):

========================================================

#include <delay.h>

while (1)
{
// Place your code here
PORTA.0=1;
delay_ms(250);
PORTA.0=0;
delay_ms(250);
}
}

========================================================

Получаю меандр с частотой 2Гц.

Я же говорю - развращает… 😇

Я же говорю - развращает…

Наверное именно поэтому у меня стоит авр студио и CVAVR, но все-таки пока склоняюсь к студио, ну там посмотрим куда дальше бежать. Так или иаче - первым делом покурить даташит на камень, потом step-by-step реализация.

PORTA.0=1; delay_ms(250); PORTA.0=0; delay_ms(250);

За что я люблю С, так это за то, что не надо писать цифры. 😃

PORTA.0=~PORTA.0;
delay_ms(250)

Вот не удержусь и вставлю свои коменты.

1. Какая вам разница, каким средством отладки Вы пользуетесь?
   Средство отладки оно и есть средство отладки. У всех у них есть стандартный набор функционала который необходим разработчику.
   Отмечу основные: загрузка и запуск программы и пошаговая отладка с отображением ресурсов процессора (регистров, памяти и т.д.). Все.
   Все остальное уже навороты. На пример некоторые средства отладки, самые отстойные, позволяют отлаживать только ассемблер. Эти средства отладки мы за средства отладки считаь не будем. Если у вашей avr studio нет встроенного С компилятора и возможности отладки С кода, то нафига такое средство? Для чего?
   Нормальные средства отладки должны подерживать пошаговую отладку С.

2. Хорошо когда в компиляторе есть встроенная поддержка специфических особенностей процессора, на пример определение функции прерывания или доступ к регистрам. Но, нормальный компилятор должен ВСЕГДА понимать ansi C. Без этого такой компилятор просто не нужен. Вы же не будете переписывать все стандартные С библиотеки заново?
   Да, еще, с компилятором должны идти и стандартные библиотеки. Без низ это то-же не компилятор. 😃

3. Никогда целенаправленно не изучайте ассемблер!
   Не в смысле что никогда не надо использовать ассемблер, а в смысле что не надо его изучать. Ассемблер это очень специфическая штука и использование ассемблерных кусков кода дляннее чем несколько строк не имеет смысла для разработчика шикорокого профиля. На ассемблере пишут библиотеки и пишут их специальные люди. Да и знание всего ассемблера для их написания не нужно. 😃
   Вам оно надо?
   При необходимости использовать ассемблер Вы просто можете открыть мануал, найти нужные Вам инструкции, вставить их в код, отладить и потом забыть как они называются. 😃 Вот я писал куски кода на … минимум на 10 разных ассемблерах. Даже библиотеки обработки сигналов писал, но я ни одного не помню. 😃 Потому что написание библиотеки, даже самой сложной занимает максимум пару месяцев. А написание всего приложение занимает в среднем год. 😃

4. Не надо выбирать проект под процессор. Выбирайте процессор под проект.
   Этих контроллеров сейчас просто море. Берите контроллер с запасом и по быстродействию и по памяти. И пишите все на С. Используйте стандартные библиотеки и т.д.
   100 % использование ресурсов нужно только тогда, когда Вы планируете выпускать изделее партией не менее 100.000 штук. Вот тогда да, имеет смысл заморачиваться с ассемблером и ресурсами, и то, большой вопрос 😃. В противном случае время, которое Вы затратите на оптимизацию будет стоить дороже чем процессор с избыточными ресурсами.

5. Начиайте работу с процессором с подбора и запуска на нем RTOS, пусть и самой простой (на пиках это ОСА на других другое). Звучит конечно смело, но поверьте, этот шаг сильно экономит время. Наличие ОС вы можете и не замечать, но когда будет нужно, она очень пригодится. 😃

6. Самое главное.
   Разделяйте процессоро зависимые куски кода и универсальные. Т.е. используйте уровень драйверов с универсальным интерфейсом. Это позволит Вам во первых гараздо быстрее все реализовывать, а во вторых повторно использовать уже написанные куски.

Ну а по поводу AVR Studio, то если она поддерживает С и его тладку, и самое главное, она Вам нравится, то используйте ее. Если не нравится или в ней чего-то нет, то найдите то что будет нравится. 😃

Хайдельбергу привет! Как там Schloss? Восстанавливают потихоньку?😇

1. Еще раз спасибо за ясное объяснение. Значит будет авр студио и баста, там есть полноценный С компилятор + возможность вставок на асме.
2. Т.к. я не знаю реально сколько памяти и процессорного времени съест прога, то пока взял (всеравно ведь на “вырост”, пока дорасту…) 32ю мегу. Мало будет - возьму тогда 128ю, благо есть где по нормальным ценам.
3. до RTOS еще дорасти надо, я пока пионЭр в МК…да и язык, которому давно уже уделял тонну времени подзабылся, сейчас литературку покуриваю параллельно.

Вот все-таки, мир не без добрых дюдей:)