-
- Так проблема была (видилась) в том, что протокол ждет точности формирования задержек порядка 20 команд. На такое время IRQ может и опоздать... Решается применением UART, SPI, PWM+Input Capture или "ручными" задержками с запрещенными прерываниями. Скрипач(47 знак., 12.04.2010 22:21 - 22:27)
- Перепутал, извиняюсь, режим Compare. Т.е. после выполнения каких-то действий задаётся время, через которое опять вызовется прерывание, считает из массива следующую функцию и временной промежуток после неё. - VAI(13.04.2010 08:57 - 09:09)
- Все равно не понятно: Ширина импульса "чтение 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)
- А что с обработчиками других прерываний? Принудительно разрешать? Теоретически, можно, но тогда нужно будет "самостоятельно разруливать" взаимосвязанные. Простор для "глюков" однако. Другое дело, камень с приоритетами прерываний. Там - да. - Скрипач(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)
- Подробности реализации таковы: VAI(1532 знак., 14.04.2010 10:45)
- Вообще-то было бы интересно услышать VAI, а не то, что вы, в отличии от меня, не сильно парились и быстро все запрограммировали :) - Скрипач(14.04.2010 00:37)
- Это ясно (это polling, только из прерывания). Вопрос (ссылка). Как я понял, просто забили на то, что теоретически на момент IRQ-таймера будет обрабатываться другое прерывание и эта задержка выбросит нас за 15мкСек гарантированно-устойчивого чтения Скрипач(89 знак., 13.04.2010 22:59 - 23:37, ссылка)
- см. выше, я чуть дополнил. К тому же у него всё-таки используется таймер, хотя и несколько иначе - koyodza(13.04.2010 21:20 - 21:23, ссылка)
- Сейчас я пытаюсь понять, почему у VAI работает без "аппаратных модулей". - Скрипач(13.04.2010 21:18)
- никакого "ожидания окончания события" внутри прерывания я не делаю. Это применительно не только к далласу, а вообще koyodza(475 знак., 13.04.2010 20:53 - 21:24)
- Б-ррр. Подождите! У нас ВЕСЬ импульс может быть 15мкСек. Плюс 20мкСек от "левого" прерывания...что-то не сходится. - Скрипач(13.04.2010 20:43)
- нужно стремиться к тому, чтобы ни один обработчик прерывания не выполнялся дольше некоторого времени, я обычно закладываю не больше 10-20мксек, смотря какой МК и какой девайс - koyodza(13.04.2010 17:24)
- Правильно, я их никогда не запрещаю. У меня MSP на 6 или 8 Мгц работают. Для 6 Мгц 167 нс на такт. 6 тактов - вход в прерывание, и ещё больше 80 тактов остаётся. А там, если глянуть по листингу, столько не нужно. VAI(1169 знак., 13.04.2010 11:34)
- а не надо их запрещать - koyodza(13.04.2010 11:10)
- Все равно не понятно: Ширина импульса "чтение 0" = 15мкСек. Если читать рано, попадем на переходных процесс, поздно - "опоздаем". 15мкСек = 120 команд@8MHz, т.е. опоздание вызова прерывания не такой уж невероятный случай. Как Вы это обошли? - Скрипач(13.04.2010 10:49)
- для 1w критичны задержки, которые собственно "формируют бит", вот те 15 и 60 мксек koyodza(282 знак., 12.04.2010 22:30 - 22:42)
- Стартовая 480 мкс как раз не критична. Она должна быть МИНИМУМ такой. Там единственный критичный интервал - после окончания Reset и до начала Presence, а это 60 мкс максимум. - Лeoнид Ивaнoвич(13.04.2010 11:30)
- То есть вот это(ссылка)? - Скрипач(12.04.2010 22:35, ссылка)
- можно и так - koyodza(12.04.2010 22:38)
- С ним тоже не все гладко. Если взять период следования бит близким к минимуму (60 мкСек) получим "узкое место" -> Успеть сформировать корректное новое задание для PWM. Особенно после передачи последнего бита :) - Скрипач(12.04.2010 22:45)
- а зачем период делать столь коротким? Какой в этом смысл? - koyodza(12.04.2010 22:48)
- Кстати, а нет ли в мк-по-умолчанию способа сгенерировать не ШИМ, а одиночный импульс? - Скрипач(12.04.2010 22:56)
- что-то не пойму - кто девайс продавать будет: Вы или я? koyodza(165 знак., 12.04.2010 23:01 - 23:04)
- Можно, конечно, период таймера сделать "ну-очень-большим", а в прерываниях "ручками" загружать в него значение -1 или -2, например. - Скрипач(12.04.2010 23:11)
- Без претензий. Я просто все еще под впечатлением от (ссылка). А вообще, насчет продавать, можно более предметно, если есть интерес. - Скрипач(12.04.2010 23:06, ссылка)
- что-то не пойму - кто девайс продавать будет: Вы или я? koyodza(165 знак., 12.04.2010 23:01 - 23:04)
- Да, можно. Только при использовании SPI таких "граблей" нет. (академически-беспристрастное сравнение вариантов, знаете ли :) - Скрипач(12.04.2010 22:54)
- Кстати, а нет ли в мк-по-умолчанию способа сгенерировать не ШИМ, а одиночный импульс? - Скрипач(12.04.2010 22:56)
- а зачем период делать столь коротким? Какой в этом смысл? - koyodza(12.04.2010 22:48)
- С ним тоже не все гладко. Если взять период следования бит близким к минимуму (60 мкСек) получим "узкое место" -> Успеть сформировать корректное новое задание для PWM. Особенно после передачи последнего бита :) - Скрипач(12.04.2010 22:45)
- можно и так - koyodza(12.04.2010 22:38)
- Перепутал, извиняюсь, режим Compare. Т.е. после выполнения каких-то действий задаётся время, через которое опять вызовется прерывание, считает из массива следующую функцию и временной промежуток после неё. - VAI(13.04.2010 08:57 - 09:09)
- аналогично, только вызов не по прерыванию, а в основном цикле раз в милисекунду, и без задержек koyodza(47 знак., 12.04.2010 17:30)
- VAI несколько в параллель опрашивает. С UART так не получится (или их несколько нужно будет) - Скрипач(13.04.2010 11:03)
- Да, весь порт сразу считываю - VAI(13.04.2010 11:07)
- в смысле у Вас 8 шлейфов? Ну мне такой осьминог пока не нужен был - koyodza(13.04.2010 11:10)
- Да, нужно не реже 1 раза в секунду получать температуру. Был 1 монстр, где потребовалось 8 термостатов... :-) - VAI(13.04.2010 18:26)
- так там и по одному шлейфу можно все 8 за секунду опросить - koyodza(13.04.2010 18:28)
- По одному шлейфу не получится. bialix(118 знак., 14.04.2010 17:00)
- у меня измерение запускается одновременно во всех датчиках (безадресно), а потом последовательно все вычитываются. Вычитать за 0,25сек 8 датчиков вполне реально - koyodza(14.04.2010 17:40 - 19:34)
- понятно. - bialix(16.04.2010 11:59)
- у меня измерение запускается одновременно во всех датчиках (безадресно), а потом последовательно все вычитываются. Вычитать за 0,25сек 8 датчиков вполне реально - koyodza(14.04.2010 17:40 - 19:34)
- Исторически, вначале стояли DS1821, затем их заменили на DS18B20, остальное всё железо оставили, как есть, несколько доработав программу. А потом подумали, что нам так даже удобнее... - VAI(13.04.2010 18:46)
- По одному шлейфу не получится. bialix(118 знак., 14.04.2010 17:00)
- так там и по одному шлейфу можно все 8 за секунду опросить - koyodza(13.04.2010 18:28)
- Да, нужно не реже 1 раза в секунду получать температуру. Был 1 монстр, где потребовалось 8 термостатов... :-) - VAI(13.04.2010 18:26)
- в смысле у Вас 8 шлейфов? Ну мне такой осьминог пока не нужен был - koyodza(13.04.2010 11:10)
- у меня сейчас на одном шлейфе висит до 8, но ничто не мешает количество увеличить - только ОЗУ больше потребуется - koyodza(13.04.2010 11:07)
- При опросе одного датчика на линии можно не возиться с их адресацией. - Скрипач(13.04.2010 13:31)
- так это в общем-то главное преимущество DS18 по сравнению с другими датчиками: возможность работать на одной линии. Если одна линия - один датчик, я лучше выберу что-то другое, не даллас - koyodza(13.04.2010 15:11)
- Есть такой критерий - цена. С чем сравниваем? Если с PT1000, то не забываем цену обвязки канала ADC. - Скрипач(13.04.2010 15:22)
- туда, куда ставят обычно ТСМ/ТСП, даллас не поставишь. Если речь идёт о "глубоко бытовом" применении, то один из наиболее дешёвых вариантов - терморезисторы koyodza(308 знак., 13.04.2010 15:31)
- Есть такой критерий - цена. С чем сравниваем? Если с PT1000, то не забываем цену обвязки канала ADC. - Скрипач(13.04.2010 15:22)
- так это в общем-то главное преимущество DS18 по сравнению с другими датчиками: возможность работать на одной линии. Если одна линия - один датчик, я лучше выберу что-то другое, не даллас - koyodza(13.04.2010 15:11)
- При опросе одного датчика на линии можно не возиться с их адресацией. - Скрипач(13.04.2010 13:31)
- Да, весь порт сразу считываю - VAI(13.04.2010 11:07)
- VAI несколько в параллель опрашивает. С UART так не получится (или их несколько нужно будет) - Скрипач(13.04.2010 11:03)
- Так проблема была (видилась) в том, что протокол ждет точности формирования задержек порядка 20 команд. На такое время IRQ может и опоздать... Решается применением UART, SPI, PWM+Input Capture или "ручными" задержками с запрещенными прерываниями. Скрипач(47 знак., 12.04.2010 22:21 - 22:27)