Захотел получить на выходе квадратный импульсный сигнал. Сделал бесконечный цикл с двумя одинаковыми паузами и выводом 1 и 0 после каждой из них. Но вместо ровного импульса на выходе получается огромное преобладание по времени либо 0, либо 1 - в зависимости от задержки.
Задержки делал с помощью _delay_ms() и _delay_us().
Не могу разобраться, в чём проблема.

Код в студию

Хотя в свойствах частота тоже проставлена. И тип контроллера, конечно, тоже.

да вроде все верно а как обстоят дела с Watchdog не вклечен ли?

Выключите вочдог при прошивке. Если он программируется фузами.

Watchdog не включён. Проверял.

Судя по коду у Вас GCC ?
Оптимизацию в опциях компилятора поставьте -Os

Используйте CvAVR.
Насколько я сталкивался с WinAVR, прекрасный компилятор, но функции _delay_xxxx у него чрезвычайно глюкавые ...

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

Я это так и не поборол .
Мне даже приходилось использовать для организации этих задержек таймер. На таймере все чисто работает.

Поэтому WinAvr стараюсь не применять. По факту, я использую его только для ObDev USB - деваться некуда.
Все остальное делаю на CvAvr. Глючки тоже встречаются, но они все вместе взятые не такие мерзопакостные, как _delay в WinAVR.

Это самый правильный и точный метод, КМК, если имеется незадействованный таймер.



Я использую GCC (WinAVR) уже достаточно давно, имею опыт. И с _delay* нет никаких глюков, скорее проблема в некорректном использовании ;-)
Лично я не встретил еще идеального компилятора

мир сошел с ума мир сошел с ума

_delay_ms(20);
PORTD = 0x0;
_delay_ms(20);
PORTD = 0x0F;



PSSSSSSSSSSSSSSSSSSSSSSSSSSSSS



while(666)
{
_delay_ms(20);
PORTD ^= 0x0f;
}

Ради истины: есть (был). В версии, которую допиливает и распространяет Атмел был глюк - задержки там формируются в 4 раза короче. Вроде бы в libc он уже устранен, внес ли эти исправления к себе Атмел - не знаю. До сих пор сижу на WinAVR 20100110.

Возможно... Я никогда не пользовал Atmel-овский toolchain, всегда брал WinAVR, как говорится, нативный. Может в какойто версии и был баг, но я его, похоже, перешагнул

Теперь по теме. Так как там дела, Паша_3? Не молчи, рассказывай, где грабли лежали

Ради истины в любой версии WinAVR (за последние лет 5) были небольшие трудно понимаемые косячки с задержками. Я об этом около года назад или даже больше писал в гнутой ветке. По моему опыту всё решается использованием delay_cycles из bultin'ов.
А что касается пропаганды CV - это ИМХО зря. CV - недоделок тот ещё. Тут всего два прямых пути: IAR или avr-gcc.
Я на avr-gcc множество проектов реализовал - только приятные впечатления как от процесса так и от результата.
И про компилятор из атмеловкого тулчейна - он работоспособен на все 100!

Старается же GCC по регистрам все константы распихать, а потом уже алгоритм крутить. Вроде бы, перестановки кода при оптимизации и дают такой эффект: задержка произвольно разваливается на загрузку констант и сам цикл.

Определенно да

Не могли бы Вы код предоставить в студию, который компилится с "косячком". Мне просто для себя интересно, где могут грабли лежать. Для чистоты эксперимента, укажите какой чип, версию компилятора, и приложите мэйкфайл. Я вот уже лет 5 использую для AVR GCC и, именно на такие грабли, ни разу не наступал Я не хочу сказать, что у GCC все идеально, но вот в сравнении с некоторыми другими, купленными за деньги, правда под ARM... я GCC сильно зауважал

Проверил ещё раз Watchdog: выключен (hfuse = 0xdf).

Код писал в AvrStudio при установленном WinAVR - 20100110 (c avr-gcc).
Прошиваю ATtiny48 через avrdude:

Запись программы:

Чтение фьюзов:
(В результате выполнения этой команды в файле high.txt лежит число 0xdf)

Запись фьюзов (записать в lfuse 0xee - установить в 1 фьюз SKDIV8):

Пробовал уже на 2-х Тинях - результат тот же.

Что не так!??

Прилагаю картинку с осциллографа (сигнал действительно такой - проверено на LED'ах с увеличенной задержкой): Нажмите для просмотра прикрепленного файла

А корректно ли считывать с пина PORTD (не PIND)? Ведь PORTD ^= 0x0f эквивалентно PORTD = PORTD ^ 0x0f.

Прилагаю HEX: Нажмите для просмотра прикрепленного файла

Обнаружил, что проблема заключается в периодической перезагрузке контроллера после однократного выполнения цикла.
Почему так происходит, пока не понял. Watchdog выключен фьюзами, плюс всё равно выключаю его программно - не помогает.

Дело в питании. У Вас когда устанавливается 1 на выводах порта ничего не подкорачивает эти выводы или наоборот при нуле не подкорачивают питание? Ресет подтянут через 10к к питанию? Емкости на ресете и питании есть? Аналоговые питание и земля подключены? Чудес не бывает.

Поддерживаю. Проблема аппаратная. Я посмотрел ваш .hex дизассемблером - код на 100% без ошибок. Я также покрутил его на симуляторе, все работает. Так что собака точно не в компиляторе зарыта.

Поиск рулит. Для затравки: www.avrfreaks.net

Такая же беда с таким же кодом на atttiny25,WinAVR - 20100110. моделирование в протеусе показывает задержку больше в 8 раз.тот же код на атмеге8 - нормально.


ПАрдон,разобрался - CKDIV8 Fuse. нужно отключить прескаллер

Это точно. Только не мир а Россия - только здесь любят CvAVR, пишут программы на паскале, архивируют RAR-ом и пользуются Оперой.