caxapa.ru :: порядок не влияет, уже проверял. а значение таймера не посмотреть - никакого дебагера нет, только умозрительно :)

Argon (10.08.2010 19:09, просмотров: 213) ответил DL36 на Посмотри значения таймера в прерывании, в момент обновления там ведь не ноль. И порядок желательно поменять конкретно тут не помню а так старший обычно буферирован.

порядок не влияет, уже проверял. а значение таймера не посмотреть - никакого дебагера нет, только умозрительно :)

Ответить

- МПЛАБСИМ? нету. - 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