caxapa.ru :: Перепутал, извиняюсь, режим Compare. Т.е. после выполнения каких-то действий задаётся время, через которое опять вызовется прерывание, считает из массива следующую функцию и временной промежуток после неё.

VAI (13.04.2010 08:57 - 09:09, просмотров: 89) ответил Скрипач на Так проблема была (видилась) в том, что протокол ждет точности формирования задержек порядка 20 команд. На такое время IRQ может и опоздать... Решается применением UART, SPI, PWM+Input Capture или "ручными" задержками с запрещенными прерываниями.

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

Ответить

- Все равно не понятно: Ширина импульса "чтение 0" = 15мкСек. Если читать рано, попадем на переходных процесс, поздно - "опоздаем". 15мкСек = 120 команд@8MHz, т.е. опоздание вызова прерывания не такой уж невероятный случай. Как Вы это обошли? - Скрипач(13.04.2010 10:49)
  - а не надо их запрещать - koyodza(13.04.2010 11:10)
    - Правильно, я их никогда не запрещаю. У меня MSP на 6 или 8 Мгц работают. Для 6 Мгц 167 нс на такт. 6 тактов - вход в прерывание, и ещё больше 80 тактов остаётся. А там, если глянуть по листингу, столько не нужно. VAI(1169 знак., 13.04.2010 11:34)
      - А что, других прерываний в системе нет? Или у вас допустим вызов IRQ из другого IRQ? - Скрипач(13.04.2010 12:44)
        
        Есть. Таймерные А0, А1, B0, B1, по концу преобразования АЦП, связь по RS232... Но если мне надо в прерывании делать что-то длительное, то я перед этим разрешаю прерывания. - VAI(13.04.2010 13:01)
    - А что с обработчиками других прерываний? Принудительно разрешать? Теоретически, можно, но тогда нужно будет "самостоятельно разруливать" взаимосвязанные. Простор для "глюков" однако. Другое дело, камень с приоритетами прерываний. Там - да. - Скрипач(13.04.2010 11:18)
      - нужно стремиться к тому, чтобы ни один обработчик прерывания не выполнялся дольше некоторого времени, я обычно закладываю не больше 10-20мксек, смотря какой МК и какой девайс - koyodza(13.04.2010 17:24)
        
        Б-ррр. Подождите! У нас ВЕСЬ импульс может быть 15мкСек. Плюс 20мкСек от "левого" прерывания...что-то не сходится. - Скрипач(13.04.2010 20:43)
        
        никакого "ожидания окончания события" внутри прерывания я не делаю. Это применительно не только к далласу, а вообще koyodza(475 знак., 13.04.2010 20:53 - 21:24)
        
        Сейчас я пытаюсь понять, почему у VAI работает без "аппаратных модулей". - Скрипач(13.04.2010 21:18)
        
        см. выше, я чуть дополнил. К тому же у него всё-таки используется таймер, хотя и несколько иначе - koyodza(13.04.2010 21:20 - 21:23, ссылка)
        
        Это ясно (это polling, только из прерывания). Вопрос (ссылка). Как я понял, просто забили на то, что теоретически на момент IRQ-таймера будет обрабатываться другое прерывание и эта задержка выбросит нас за 15мкСек гарантированно-устойчивого чтения Скрипач(89 знак., 13.04.2010 22:59 - 23:37, ссылка)
        
        вы хотите гарантировано получить результат после первого же чтения или допускается повторное чтение датчика в случае неудачи? если второе, то вероятность возникновения "левого" прерывания точно в определенный момент транзакции может быть не так страшна. - Snaky(14.04.2010 02:45)
        
        подробности реализации koyodza(747 знак., 14.04.2010 00:12)
        
        Вообще-то было бы интересно услышать VAI, а не то, что вы, в отличии от меня, не сильно парились и быстро все запрограммировали :) - Скрипач(14.04.2010 00:37)
        
        Подробности реализации таковы: VAI(1532 знак., 14.04.2010 10:45)
        
        Спасибо. - Скрипач(14.04.2010 12:53)
        
        "парился", как раз сильно, поскольку моя основная задача не позволяла прерывать её дольше чем на 10-15мксек, а прерываний в системе было достаточно много. Да и опрос далласов был не на втором и не на третьем месте по приоритету, он вообще был "в koyodza(132 знак., 14.04.2010 00:50)

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