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

не заметил прокрутку.

Мяу! Подскажите плз, правильно ли я понимаю - конструкция


инвертирует первый разряд порта D ? Для меня не совсем ясно вот это _BV(PD1). Код из "мини таймер, меньше просто не бывает на тини 2313"
http://arv.radioliga.com/content/view/213/44/

_BV(PD1) - это 1<<PD1, т.е. 2
PORTD &= ~C4_D; - сбрасывает бит PD1 в ноль

спасибо за оперативность

Помогите мне пожалуйста !!! Начал изучать Си для AVR И появились у меня вопросы. Получается что включаются полностью порти B и D.
А Как написать чтобы был задействован Порт B0 для Светодиода и D0 для кнопки ???
Для B1 и D1 будет по нажатию кнопки ON или OFF светодиод.
#include <avr/io.h>
int main(void)
{
DDRD = 0x00; //порт D - вход
PORTD = 0xFF; //подключаем нагрузочный резистор
DDRB = 0xFF; //порт B - выход
PORTB = 0x00; //устанавливаем 0 на выходе
while(1)
{
PORTB = PIND; //Включаем LED
}
}

Попробуйте PORTB.0 = PIND.0

Gudd-Head ,а вы, случайно, тему не перепутали?
Это не CVAVR.
BGert перед началом использования си для Мк почитайте основы.
Раздел битовые операции
установка бита
PORTB|=0b00000001;
очистка бита
PORTB&=0b11111110;
инверсия бита
PORTB^=0b00000001;

вообще если вам нужно один бит смотреть и менять нужно так:
if(PIND&0b00000001){PORTB|=0b00000001 ;}
else PORTB&=0b11111110;

Не, не перепутал. Я просто не знаю чем различаются СИшные компиляторы

vitalik_1984 Большое спасибо за ответ !!!
Еще можете подсказать литературу для AVR studio, а то мне попадаться литература под WinAVR.

Строго говоря ни WinAVR ни cvavr не являются компиляторами Си в чистом виде, и там и там добавлены костыли под особенности МК, например обращение к ПЗУ (pgm_read_byte()). AVRStudio - среда разработки, к которой теоретически можно прикрутить любой компилятор (на практике плохо представляю зачем это надо) как в качестве ассемблера (по умолчанию идет аж с двумя встроенными) так и в качестве Си (по умолчанию ничего не идет зато автоматически интегрируется с WinAVR, который совместим, если не одинаков, с avr-gcc). Еще раз, свой ассемблер у AVRStudio есть, своего Си нет. Ну и по литературе, встроенная подсказка весьма неплоха по командам как ассемблера так и avr-gcc, точнее libc.

Для тех кто в танке ещё кто не в курсе.

GNU AVR toolchain, или AVR GCC toolchain — наименование набора распространяемых по лицензии GPL, LGPL пакетов программ, необходимых для компиляции из исходных текстов выполняемого кода программ для процессоров AVR. Основу составляют пакеты программ avr-binutils, avr-gcc, avr-libc, в дополнение к ним применяются утилиты внутрисхемного программирования (uisp, Avrdude), а также симуляции и отладки (avr-gdb, SimulAVR, AVaRICE).

Эти программы в скомпилированном для Windows виде входят в распространяемый фирмой Atmel стандартный набор программ разработки для процессоров AVR (AVR Studio), а также популярный набор программ разработки WinAVR.

Под Linux сборки есть почти под все дистрибутивы. Если нет - можно из исходников собрать.

Если не учитывать незначительные различия, то по большому счёту GNU AVR toolchain, AVR GCC toolchain и WinAVR это одно и то же. Основа одна, выпускаются разными группами разработчиков.

Ну, так почти все компиляторы для AVR нельзя назвать компиляторами "чистых" языков (ни Си, ни Паскаль, ни Бейсик, ...), т.к. изначально они были "заточены" под фон Неймановскую архитектуру, а не под Гарвардскую. Вот и вставляют костыли, чтобы на Гарвардской архитектуре работать.

Вроде именно так я и написал а отсюда
можно сделать вывод: отличаем от Си, у разных компиляторов они разные: что-то добавлено именно ради контроллера (та самая разница архитектур, да и порты ввода-вывода, обычные Си не знает что такое UBRR например) что-то просто так (cvavr'ское обращение к битам)

К примеру CVAVR может разместить переменную и структуру в бортовой eeprom и не думать программисту о её адресе,а WinAVR этого не может.
CVAVR может для экономии памяти распределять битовые поля,WinAVR этого не может.

Как только программисту (да и не только) о чём-то "не надо думать" - так быть беде. Особенно, если программист не знает того, о чём ему позволяет не думать конкретная штука (компилятор, библиотека, ...).
Я уже приводил в соседней ветке мысль где-то увиденную на просторах интернета: "Народ всё больше и больше отключает свои мозги и полагается на компьютеры с работающими там программами, забывая о том, что программы пишут такие же отключающие мозги. Процесс итерационный." И остаётся всё меньше и меньше людей понимающих основы и как оно работает от начала и до конца.
Поэтому надо очень желательно знать и понимать как те самые "плюсы/блага" устроены и работают. Иначе мы, рано или поздно, опять придём к тому, что солнце вращается вокруг земли.

Что-то не по теме разговор пошёл - умолкаю.

См .последнюю строчку в подписи. И ещё, вот, может кому понравиться: http://dmitry-shem.livejournal.com/31381.html

Хотелось бы узнать Ваше мнение по системам RAD.
Представляете,человек устанавливает последнюю версию Delphi или C++ начинает плеваться на обилие компонентов.Ведь они так облегчают жизнь программиста,размягчает мозг.Сносит всё это к едрени фени,устанавливает,допустим Borland 3,удалив предварительно все компоненты и "наслаждается" процессом "настоящего" программирования.
Смешно,неправда ли?

Я не призывал отказаться от использования разного рода "няшек". Не надо так категорично.
Вы говорите о совершенно другой области - программирование приложений под винду. Там другой набор вещей, которые желательно знать. Неплохо бы хорошо знать ООП и соответствующие возможности языка, и хотя бы хорошо представлять, API винды и систему сообщений винды (windows messages), чтобы не ввергать написанное приложение в бесконечные циклы и эксепшэны из-за незнания что и как работает (речь не идёт о простых приложениях). Говорю не по наслышке - сам через это прошёл, и ошибки были такие, что вынужден был немало разбираться.
Надо один раз пройти азы/внутренности, чтобы потом знать как оно устроено и как оно работает. Если не пройти в виде учёбы, то очень вероятно, что жизнь, рано или поздно, заставит это сделать. И потратите на получение тех же знаний, вероятно, намного больше времени (т.к. будете "бороться" с ошибкой). Естественно, имеется в виду профессиональная деятельность (или увлечение).
По-хорошему эти азы (разные для разных областей) должны проходить во время учёбы. Но, к сожалению, это же только по-хорошему. В реальности далеко не всегда так. И учить, IMHO, должны, так, что да же если забыл подробности, должен знать, что "оно там есть", уметь найти (и-нет, книги, ...), вспомнить и разобраться. Кругозор должен быть профессиональный, не только вообще.

Чтоб уже не совсем оффтопик был. Простейший пример - сколько шуму, что avr-gcc не умеет использовать аппаратный умножитель. Да оно так. Но при этом практически всегда те же кто кричит об этом используют avr-libc. Но они не знают (не ознакомились с документацией - читай "не учили"), что в её составе есть оптимизированная математическая библиотека - подключай и радуйся.
В 4й студии в свойствах проекта подключается. В 5й и 6й, вроде как автоматически подключена. "Руками" тоже никто не мешает подключать.

Ну хватит "холи вары" разводить.
И так понятно, что ученье свет, а неученье тьма.
А маниакальные предпочтения конкретного индивидуума это его личное дело.

Главная "фишка" языка C - мобильность (легкая переносимость между различными платформами). Именно она позволяет держаться на плаву и самому языку, и написанным на нем продуктам уже четыре десятка лет, когда прочие их ровесники давно и прочно позабыты.

Когда разработчик некоего компилятора делает некоему Васе Пупкину "подарок", предоставляя возможность, например, более "удобно" (по его мнению) играться битами в регистрах (и тем самым отступая от стандарта), он на самом деле производит подмену понятий: с этого момента Вася, купившись на эти новшества, перестает писать на языке C и начинает писать на новом языке с C-подобным синтаксисом. Хорошо это или плохо, судить не берусь, холиварить на темы Язык1 vs Язык2 найдутся желающие и без меня; я лишь констатирую факт.

Для меня решающий профит от использования стандартного C заключается в возможности выполнения одного и того же кода (возможно, с минимальнейшими изменениями) как, скажем, на AVR после компиляции в WinAVR (или как там сегодня велено величать этот славный toolchain; трудновато в это время перемен угнаться за модой), так и на PC под Cygwin. Как только эта возможность теряется, мне становится совершенно безразлично, что использовать: этот самый C-подобный новояз, какой-нибудь из многочисленных "микропаскалей" или "минибейсиков" - все они по сути делают одно и то же, но с собственными уникальными приподвывертами.

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

Вот как-то так...

Вам уже и макроопределения и переопределения WinAVR не угодили?
Мне как-то тоже,uint8,uint16,как-то не фразеологично C.

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

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

Впрочем, к вышесказанному это вряд ли имеет отношение, равно как и заданный вопрос (ибо макроопределение отнюдь не является элементом языка и к разработке компилятора не относится).