В даташшите на МК Atmega48 написано что у него есть 6 ШИМ.
Написал программу для плавного зажигания светодиодов.

вот основной кусок



Соответственно получаем 4 ШИМ на выходах PB1, PB2, PD6 и PD5.
Просьба знающих людей ответить на следующие вопросы:

1. Как получить еще 2 ШИМ? Пробовал через TCCR2A и TCCR2B как написано в даташите не получатся, и на каких вообще выходах должны быть эти 2 ШИМа?

2. Почему на выходах PB1 и PB2 напряжение плавно нарастает с 0 до 5 В и остается на 5 В, а на выходах PD6 и PD5 плавно нарастает с 0 до 5 В затем скачком сбрасывается до 0 и снова плавно нарастает. Разве они не должны одинаково работать?


Спасибо огромное за помощь.

Из этого куска не видно, где и что вы пишете в регистры OCR.
Согласно документации - на выводах PB3 и PD3.
Кода не видно, вероятно вы наращиваете переменную типа int и не учитываете, что OCR1A, OCR1B - 16-битные регистры, а OCR0A, OCR0B, OCR2A, OCR2B - 8-битные, и в них попадает лишь младший байт. Пишите в OCR1AL, OCR1BL - получите одинаковое поведение.

P.S. ваша функция pause() перестанет работать как только вы включите оптимизацию. Либо добавьте к параметру a квалификатор volatile, либо используйте функции _delay_ms(), _delay_us() из <util/delay.h> если ваш компилятор - avr-gcc, либо __delay_cycles() из <intrinsics.h>, если ваш компилятор - ИАР.

Спасибо огромнейшее, с обоими вопросами разобрался.
А теперь насчет:

компилятор avr-gcc, насчет использования функций _delay_ms(), _delay_us() ясно, а вот насчет добавления volatile можно по подробнее, я просто совсем новичок в Си и в программировании, если не сложно киньте пример кода или напишите что в указанном выше исправить. Заранее спасибо.

Вообще volatile "заставляет" компилятор не делать никаких предположений о значении переменных. Т.е. переменная всегда берётся из её места в памяти, даже если она осталась где-то в регистрах.

Хотя, если честно, то я вот этого

не понимаю. С какой стати?
Про _delay_ms(), _delay_us() тоже вставлю свои 5 копеек. У меня они НИКОГДА нормально не работали в WinAVR. Всегда хрен знает что с ними творится. Может тоже "отрыжки" оптимизации влияют - не знаю, не исследовал их. Собственно поэтому я и не люблю этот компилятор. Может я и не прав.
Хотите надёжно - делайте на таймерах. В avrLib есть по-моему готовая реализация.

PS. В CvAVR delay_ms всегда работает как часы. Не сочтите за рекламу.

Не только «берется», но и «кладётся», если уж на то пошло.
Вообще-то компилятор может выбросить вообще весь код, если от этого не меняется observable behavior программы, извините мне моё обычное занудство с терминологией из стандартов С/С++, а не из надписей на заборах. Холостой цикл его не меняет, так как просто задержка не «замечается» компилятром. Есть еще задержки памяти разного рода, кешей и винчестера — откуда ему об этом всём знать?
Может, если переменная ляжет в регион внешнего ОЗУ меги64, к которому несколько тактов ожидания — цикл в разы удлиннится по сравнению с переменной во внутренней памяти, а тот в разы относительно переменной в регистре. Если ему обращать на это внимание, он вообще оптимизировать не сможет.
Если компилятор может выкинуть весь код кроме последнего оператора тут:
То почему ему нельзя выбросить пустой цикл — ничего не делающий реального?
Ещё тут почитайте. Он не только выбросить ничего не делающий с его точки зрения код имеет право, но и переставлять местами делающий что-то полезное даже с его точки зрения.

Так вот volatile говорит компилятору, что он не может строить предположений о «видимости» работы с данной переменной снаружи независимо от её размещения в памяти, регистрах, ...
Даже если он работает с ней только в памяти (например, pic16 просто не сильно-то и может держать переменные в регистрах и имеет команду декремента с пропуском прямо на памяти).

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

Добавлю к вышесказанному, так сказать, объяснение на пальцах. Ваш код задержки с точки зрения компилятора делает только одно - он делает маленькую быструю программу большой и медленной. Но ведь мы же все хотим, чтобы программы не тормозили, влезали на одну дискетку и работали как можно быстрее? Поэтому компилятор очень старается сделать получаемый из вашего исходника код как можно более быстрым и компактным. А этот ваш кусочек кода, получается, пытается сделать хорошую программу плохой! Ваш случай, конечно, самый вырожденный, но представьте такой код: UBRRL = F_CPU / BAUDRATE / 16; Вы просите компилятор сделать деление в вашей программе. Если обе константы F_CPU и BAUDRATE известны компилятору - он может вставить в вашу программу сразу результат деления и программа не будет тратить на это деление время. Она станет быстрее и короче. И ведь вы в самом деле хотите, чтобы в этом месте в программе был результат, а не процесс деления. Компилятор не обладает телепатией и не может решить, в каких местах программы вы хотите все быстро, а в каких вы хотите ее замедлить намеренно. Поэтому он делает программу как можно более быстрой (и короткой) везде. И везде его действия совпадают с вашими желаниями, кроме случая с задержкой. И чтобы обмануть его в случае с задержкой, надо объявить переменную цикла с квалификатором volatile, который говорит компилятору "делай с этой переменной все так, как написано, даже если ты знаешь, какой результат в конце концов окажется в этой переменной".
Т.е. мы указываем ему, что мы действительно хотим чтобы он в эту переменную i записал a, а потом вычитал по единице пока не получится 0. Хотя очевидно, что в конце вычитаний i будет содержать 0. Более того, i не используется, поэтому и ноль-то в ней никому не нужен.
Эта функция pause обладает только одним недостатком - время ее работы будет зависеть от уровня оптимизации и версии компилятора. Библиотечные функции _delay_xx() написаны на инлайн-ассемблере (а в новых версиях вшиты во внутренности компилятора) и их время выполнения не зависит он настроек компилятора.

Сергей Борщ Спасибо огромнейшее. Помог разобраться со всеми проблемами, даже с теми о которых изначально не просил =))) Даже не думал что проблема с оптимизацией так легко решается.
Может посоветуешь какой нибудь учебник по программированию AVR на Си?

ЗЫ не нашел на этом форуме кнопок аля Спасибо (или +в репу) или здесь таких нету?

И я ещё маленько про то, что volatile != не_делать_предположения_о_значении_и_брать_всегда_из_памяти.
volatile это нечто большее. Имеем код:
Ну так вот если переменная i не объявлена volatile, то компилятор имеет полное право сделать, к примеру, такой код, в котором пожелание «переменная всегда берётся из её места в памяти, даже если она осталась где-то в регистрах» выполнено на 100%:
Несколько не то, чего ожидали, правда? Но это допустимый код. Допустимо будет сгенерировать и такое:
Все эти три куска с точки зрения компилятора эквивалентны по наблюдаемому поведению. Допустимым будет даже досчитать от 0xFF до 0xAD перед первой записью в PORTB, от 0xAC до 0x0F между записями в порт и от 0x0E до 0 после второй записи. И даже прогнать цикл, пишущий в i числа от 1 до 0xFF по нарастающей и только в конце 0.
Конечно, маловероятно, чтобы какой-то компилятор сгенерировал эти коды, он просто выбросит цикл вообще.
Но компилятор имеет право переставлять обращения к не-volatile переменным между собой и обращениями к volatile-переменным. А вот менять порядок обращения к volatile-переменным он не имеет права (как раз об этом в той длинной теме на sources.ru по линку в предыдущем моём сообщении). Это слово означает не только то, что значение переменной может измениться «само по себе» («не делать никаких предположений о значении переменных»), но и что само обращение как таковое может что-то поменять во «внешнем мире», в том числе как-то повлиять на значение этой или других volatile-переменых (пример — умножитель в MSP430).
Кстати, «не делать никаких предположений о значении переменных» не запрещает компилятору выбросить из нескольких идущих подряд записей в порт все, кроме последнего. Запрещают это только возможные «побочные» эффекты самого факта записи.