ATtiny48 - проблемы с тактированием Опции

[Паша_З]

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

[V_N]

Код в студию

[Паша_З]

Код

#define F_CPU 8000000
#include <avr/io.h>
#include <util/delay.h>
int main() {
  DDRD = 0x0F;
  PORTD = 0x0F;
  while(1) {
    _delay_ms(20);
    PORTD = 0x0;
    _delay_ms(20);
    PORTD = 0x0F;
  }
}

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

Сообщение отредактировал Паша_З - Mar 24 2011, 17:48

[V_N]

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

[DpInRock]

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

[Паша_З]

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

[nk@]

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

Сообщение отредактировал nk@ - Mar 24 2011, 19:16

[hd44780]

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

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

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

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

Сообщение отредактировал hd44780 - Mar 25 2011, 08:45

[nk@]

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

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

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

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

[_Pasha]

Все остальное делаю на CvAvr. Глючки тоже встречаются, но они все вместе взятые не такие мерзопакостные, как _delay в WinAVR.

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

[Stepan_L]

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



PSSSSSSSSSSSSSSSSSSSSSSSSSSSSS



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

[Сергей Борщ]

И с _delay* нет никаких глюков

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

[nk@]

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

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

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

[demiurg_spb]

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

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

[SysRq]

...небольшие трудно понимаемые косячки с задержками

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

По моему опыту всё решается использованием delay_cycles из bultin'ов.

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

[nk@]

Ради истины в любой версии WinAVR (за последние лет 5) были небольшие трудно понимаемые косячки с задержками.

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

[Паша_З]

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

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

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

Код

avrdude -p t48 -c stk200 -e -U flash:w:test.hex

Чтение фьюзов:

Код

avrdude -p t48 -c stk200 -U hfuse:r:"./ high.txt":h -U lfuse:r:"./ low.txt":h

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

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

Код

avrdude -p t48 -c stk200 -U lfuse:w:0xee:m

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

Что не так!??

Прилагаю картинку с осциллографа (сигнал действительно такой - проверено на LED'ах с увеличенной задержкой):  osc.bmp ( 146.3 килобайт ) Кол-во скачиваний: 24

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

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

Прилагаю HEX:  test.rar ( 232 байт ) Кол-во скачиваний: 77


Сообщение отредактировал Паша_З - Mar 30 2011, 14:21

[Паша_З]

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

[smk]

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

[nk@]

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

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

[demiurg_spb]

Не могли бы Вы код предоставить в студию

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

[1100.1010.1011.1...]

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

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

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

[777777]

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

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