caxapa.ru :: Посмотри значения таймера в прерывании, в момент обновления там ведь не ноль. И порядок желательно поменять конкретно тут не помню а так старший обычно буферирован.

DL36 (10.08.2010 18:43, просмотров: 214) ответил Argon на Странность с таймерными прерываниями у PIC12 наблюдаю.

Посмотри значения таймера в прерывании, в момент обновления там ведь не ноль. И порядок желательно поменять конкретно тут не помню а так старший обычно буферирован.

Ответить

- порядок не влияет, уже проверял. а значение таймера не посмотреть - никакого дебагера нет, только умозрительно :) - Argon(10.08.2010 19:09)
  - МПЛАБСИМ? нету. - DL36(10.08.2010 19:39)
    - есть, но говорят, не симулирует работу таймера от внешнего LP. даже пробовать не стал - Argon(10.08.2010 20:14)
      - Тут можно имитировать внешний клок на одном из выводов, думаю тактироваться должен. - DL36(10.08.2010 22:51)
        
        софтовые симуляторы имеют свои грабли, чо-та неохота еще и с ними разбираться. у меня ж вполне нормальный дебаг получается с использованием пина, с к-рого беру частоту. кажется, этого должно быть достаточно. - Argon(10.08.2010 22:55)
  - Константу вычитать надо, а не присваивать. - testerplus(10.08.2010 19:21)
    - Хотел подвести к такому ответу. - DL36(10.08.2010 19:39)
      - а как можно сделать это атомарно и быстро? я избалован 32-битными ядрами, отсюда такие вот школьные вопросы. Спасибо! - Argon(10.08.2010 20:10)
        
        Атомарно не знаю, а так просто вычитать с учетом тактов занимаемых текущим обработчиком до момента записи новой константы. - DL36(10.08.2010 21:27)
        
        а, ну это-то даже я знаю. в начале обработчика совсем немного тактов, вряд ли это они влияют. У меня-то четкая закономерность - 1 период внешнего кварца... - Argon(10.08.2010 21:32)
        
        8 команд и видимо сохранение контекста какое то есть потом надо ДШ почитать, было там пропуск тактов после записи хотя где уже не помню. - DL36(10.08.2010 22:35)
        
        да какое там сохранение контекста... основной цикл в main() - глухой, for(;;) - Argon(10.08.2010 22:46)
        
        Так в конкретном случае об атомарности не надо заботиться. Для проверки предположения можно просто вычитать "TMR1L -= 16" и присваивать "THR1H = 0xFF". - testerplus(10.08.2010 22:30)
        
        а давно проверено, именно так. не помогает! - Argon(10.08.2010 22:44)
        
        В симуляторе с внешним тактированием T1CKI (как там сэмулировать тактирование с LP - не знаю) работает четко. Завтра на работе попробую в железе с LP. - testerplus(11.08.2010 00:46 - 01:00)
        
        Проверил в железе - работает четко: 1024 Hz. Писал на ассемблере с минимальным кодом прерывания 7 инструкций. Как только добавил 10 нопов - получил 963 Гц. Дело,скорее всего, вот в чем: testerplus(752 знак., 11.08.2010 13:35)
        
        Спасибо, так работает! Похоже, идея организовать UART через прерывания была плохой. - Argon(11.08.2010 14:26)
        
        А в Вашем пике есть CCP? Можно использовать прерывание Compare и модифицировать CCPR, не трогая TMR1. - testerplus(12.08.2010 10:03)
        
        Увы, нет. Пользую PIC12F675. Так что придется делать UART через задержки... - Argon(12.08.2010 10:38 - 11:02)
        
        возьмите PIC12F683 (есть CCP и больше памяти) или дождитесь PIC12F1822 (будет аппаратный UART и больше памяти за те же деньги - ожидаются в начале октября) - Илья(12.08.2010 11:08)
        
        уточню: у меня rfPIC12F675 :) Да собственно, проблемы-то нет - через задержки по тому же таймеру1 с ожиданием TMR1IF вроде нормально получается. - Argon(12.08.2010 11:11)
    - неужели для такой малой частоты 32 кГц (по сравнию с ядром 1 МГц) есть какая-то разница? - Argon(10.08.2010 19:30)
      - Почему нет? Программа в момент переполнения TMR1 могла заниматься обработкой прерывания от другого источника. >32 тактов задержки - запросто. - testerplus(10.08.2010 19:32)
        
        а нет других источников прерываний. - Argon(10.08.2010 20:14)

Микроконтроллеры PIC