в отладчике протеуса при пошаговом проходе значение счетчика увеличивается на 1 раз за 8 кликов...
Кстати, в АВРстудии счетчик правильно растет - один инкремент на такт.
А о клоках - дык их и у самого чипа немного... CKSEL и то не для источника тактирования применяются, а только для задержки при сбросе...
nictrace писал(а):в отладчике протеуса при пошаговом проходе значение счетчика увеличивается на 1 раз за 8 кликов...
Кстати, в АВРстудии счетчик правильно растет - один инкремент на такт.
Ну, еще нехватало, чтобы студия врала, как сивый протеус.
Сейчас глянул в свою модель тиньки-15 (6-95) так в ней все правильно считается - может попробовать заменить модель, хотябы на время? Если все встанет на свои места - она и виновата.
nictrace писал(а):А о клоках - дык их и у самого чипа немного... CKSEL и то не для источника тактирования применяются, а только для задержки при сбросе...
Я не это имел ввиду - я подумал, что ты частоту клоков оцениваешь каким-нить осциллом и видишь в восемь раз меньше, чем должно быть, а это возможно, например, если поставишь в свойстве модели меньшую частоту. Но, поскольку ты не частоту смотрел, а число клоков на шаг исполнения, то это предположение уже неактуально.
Так-что, если это важно - попробуй заменить модель тиньки на заведомо рабочую, может и прояснится, кто виноват и что делать.
Я дальше 6.95 не пошел (неинтересно), но попробовать можно - осцилл от семерки в 6.95-й работает же.
Во всяком случае, для проверки источника ошибки сойдет.
В шестерке эта модель в avr.dll находится - думаю, нужно создать в своей либе копию тиньки и в процессе сбора модели отредактировать ссылку на dll'ку, удалив двоечку - для пущей безопасности.
Я же говорю - скопируй всю модель в библиотеку user - это и безопаснее с точки зрения ненарушения файлов исходных библиотек.
1.Создаешь новую, пустую схему
2.кладешь туда компонент тиньку-15
3.декомпозируешь её
4.выделяешь мышкой всё
5.создаешь новый девайс - в нем все будет таким же, как в исходном, даже ссылка на dll - вот ее-то и нужно подправить.
GP1 писал(а):1. Разрешаеш прерывания, а вектора не задаеш
Все задано, просто сюда я не стал выкладывать очевидное.
GP1 писал(а):ldi temp,0x20 ; 50% pwm
out OCR1A,temp
Со всем разобрался, программу написал, правда не на асме, к сожалению. Однако как точно выставить скважность, так и не понял...
ШИМ 8-битный => максимальное значение 0xFF (255). Значит при 50% нужно указывать 0x80 (128), а Вы предлагаете 0x20 (32). Хм.. странно.
Тогда какое же все-таки максимальное и минимальное значение ШИМ в Tiny15?
Здравствуйте, уважаемые братья по разуму )
Такой вопрос может кто сталкивался.
Отлаживаю программу в Proteus устройства на МК ATTINY45, использую таймер/счетчик 1 для формирования импульсов скважностью 2 на порте PB1. Регистром OCR1C задается частота импульсов. Регистром OCR1A по сути дела фаза сигнала.
Суть в чем, в AVR Studio все замечательно работает. При каждом сравнении с OCR1A происходит смена состояния порта PB1, а при сравнении с OCR1C сброс счетчика (разумеется что OCR1C > OCR1A).
В протеусе же, при достижении OCR1A происходит и смена состояния PB1 (как положено) и еще и сброс счетчика (с кого-то фига). В результате чего, счетчик не достигает значения OCR1C. Таким образом, в протеусе частота на выходе порта PB1 начинает определяться регистром OCR1A а не OCR1C.
Было предположение что возможно при создании модели контроллера программисты допустили ошибку и спутали регистры OCR1A и OCR1C. но поменяв значения в них местами т.е. сделав OCR1A > OCR1C получилось что счетчик сбрасывался при достижении OCR1C и не достигал значения OCR1A, порт не переключался. получается счетчик сбрасывает как при сравнении с OCR1A так и с OCR1C. если бы регистры были спутаны результат бы был другой.
Может есть какая то хитрость в настройке счетчика атмелки? Или же все такие глюк протеуса... как тогда бороться с этим глюком?
Сам я в основном пишу для PICов и с атмелами пока знаком не так близко.
Посмотреть как ведет себя реальный МК пока нет возможности - нет даннго МК в наличии.
Вот программка которой исследовал работу счетчика.
Пишу в ImageCraft IDE for ICCtiny - поддерживает и tiny15, но при использовании мастера для шим генерирует вот такие строки:
//Timer1 init
TCCR1 = 0x00; //stop
TCNT1 = 0xF8; //count value
TCCR1 = 0x64; //start Timer, frequency = 0Hz
OCR10 = 0x00 //comparea value@
OCR11 = 0xFF; //compareb value
, а сам компилятор после этого пишет не знает, что это такое:
OCR10 = 0x00 //comparea value@
OCR11 = 0xFF; //compareb value
Забавно, подскажите пожалуйста, что нужно подключить, чтобы убрать этот ляп.
