caxapa.ru :: Протокол 1wire. Лучшая реализация?

Связанные сообщения

Есть такой документик, там последняя глава по теме2024-03-09

Коллеги, кто знаком с интерфейсом 1-Wire? Сначала идет Reset, потом Presence. Какая максимальная пауза может быть между Presence...2024-03-09

Скрипач, пророк (11.04.2010 14:00, просмотров: 40533)

Протокол 1wire. Лучшая реализация? Потихоньку "пристреливаюсь" к 1wire. Нужна помощь "обсуждением". Выбираю способ. "Polling" и "UART", похоже, не подходят. UART уже использован для других целей, а "Polling" будет "путаться под ногами" в других задачах. Есть еще две идеи: SPI(аналогично UART) и PWM+Timer. По SPI все примерно как и по UART, только будут заняты 4 ножки камня (жалко) По PWM+Timer, есть ненулевая вероятность, что прерывание от таймера совпадет с одним (или несколькими) от другой периферии и мы в нем прочитаем неверное значение бита (опоздаем). Что из "нюансов" я забыл? Каково, на практике, "окно чтения бита"? (влияние емкости линии на чтение "1" с одной стороны и время гарантированного удержания "0" с другой)

... но не любой ценой.

Ответить

- А я на MSP несколько градусников DS18B20 одновременно опрашиваю. Разбил весь алгоритм работы на отдельные шаги - функции, между которыми задержки VAI(523 знак., 12.04.2010 17:20)
  - Так проблема была (видилась) в том, что протокол ждет точности формирования задержек порядка 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)
        
        Есть. Таймерные А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)
    - для 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, ссылка)
        
        Да, можно. Только при использовании SPI таких "граблей" нет. (академически-беспристрастное сравнение вариантов, знаете ли :) - Скрипач(12.04.2010 22:54)
  - аналогично, только вызов не по прерыванию, а в основном цикле раз в милисекунду, и без задержек 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)
        
        Исторически, вначале стояли DS1821, затем их заменили на DS18B20, остальное всё железо оставили, как есть, несколько доработав программу. А потом подумали, что нам так даже удобнее... - VAI(13.04.2010 18:46)
      - у меня сейчас на одном шлейфе висит до 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)
        
        NTC10K? Не так уж дешево. Впрочем, вы правы, делать 1-wire без работы с адресами как-то некузяво. Просто я попутно пытаюсь изобрести "дуракоустойчивый" способ настройки этого дела. - Скрипач(13.04.2010 16:22)
        
        я брал 90 коп. в розницу. Дешевле - только диоды/транзисторы использовать, но с ними значительно сложнее работать - koyodza(13.04.2010 16:30)
- a moж тебе ds2482 поможет? - cvv(12.04.2010 17:12)
  - Да вроде и без него все получается. - Скрипач(12.04.2010 22:39)
- А почему поллинг не подходит? Прерывания запрещать нужно очень кратковременно, менее 70 мкс. Лeoнид Ивaнoвич(1945 знак., 11.04.2010 20:24)
  - Поллинг нужно увязывать нетолькособработчиками прерываний но и с другими задачами "в простом цикле". Можно, конечно, но неудобно. - Тоже Скрипач(11.04.2010 20:35, )
- для реализации "многофункционального контроллера" по ссылке вполне можно и поллинг использовать koyodza(82 знак., 11.04.2010 19:03, ссылка)
  - Да, туда именно поллинг и планировался. Тот проект "продавцы", увы, радостно просрали. Нарыл у нас, в Киеве, ребят нормально корпусирующих датчики температуры с любым (под заказ) термоэлементом. "Изучаю рынок" :) - Скрипач(11.04.2010 19:08)
- Для атмеловского АРМа я пользовал два канала таймера. Одним генерил импульсы, другим - читал их длительность. Получилось довольно аккуратно. Режим PWM не нужен - проще генерить одиночные импульсы, чтобы не быть зажатым по времени. - vmp(11.04.2010 16:43)
- Лучшая реализация - поставить камень с двумя uart. Сейчас их как грязи... Если это неприемлемо, то uart отдать под 1wire, и реализвоать soft uart в прерываниях (что проще). - Гудвин(11.04.2010 14:55)
  - А чем UART лучше чем SPI в роли "носителя 1-wire"? - Скрипач(11.04.2010 16:25)
    - Да ничем... Но "По SPI все примерно как и по UART, только будут Гудвин(58 знак., 11.04.2010 16:43)
      - Так посоветуйте взять камень "с лишними ножками". Их таки точно "как грязи" :) Железка - "чистый ногодрыг" и ставить туда более дорогой кристалл просто потому что такие бывают не очень хочется. - Скрипач(11.04.2010 16:49)
        
        кто-то совсем недавно хвастался маржой в десятки тысяч процентов. А тут м8 и нежелание что-либо менять... - koyodza(11.04.2010 17:31)
        
        Большая маржа и "нежелание что-либо менять" вещи взаимосвязанные :) - Скрипач(11.04.2010 18:31)
        
        m162 - два с небольшим бакса ;) - Гудвин(11.04.2010 17:19)
        
        Хорош, но PWM+Input capture на m8 тоже нормально (и на полтора бакса дешевле ;) - Скрипач(11.04.2010 19:04)
- а приоритеты прерываний есть? - AVF(11.04.2010 14:10)
  - База: atmega8. Приоритетов нет. Кристал можно и другой взять, не догма, но только если это действительно нужно (устройство выпускается давно, прицеливаюсь к "фенечке" в новую версию) - Скрипач(11.04.2010 14:15)
- InputCapture прикруить для фиксации момента фронта на шине и потом смотреть расстояие от PWM-овского начала импульса? Только две ноги могут понадобиться, выход PWM и вход CAPT - ReAl(11.04.2010 14:05)
  - Да, но смущает (в моем случае, Atmega8 Timer1) необходимость обрабатывать два прерывания на бит вместо одного (фронт и срез) и есть угроза "терять события": пришел "срез", ушли в обработчик, до окончания оного пришел "фронт" -> опаньки :( - Скрипач(11.04.2010 14:13)
    - Прерывание по capture должно отработаться до следующего прерывания по началу бита и может быть задержано - значение-то в ICR лежит. - ReAl(11.04.2010 14:19)
      - О том и толкую, что следующее событие (по-"фронту") это значение в ICR перепишет. Там, как я понял, нет буфера. - Скрипач(11.04.2010 14:23)
        
        На сколько я понял "здесь" Скрипач(434 знак., 11.04.2010 14:35)
        
        см. бит ICES1 - koyodza(11.04.2010 17:22)
        
        ВАХ-СПАСИБО :) Еще раз внимательно прочитал текст - там, блин, этот бит вообще не упоминается. "Внимательное чтение текста не заменят внимательного чтения сносок"(с) Такие дела :) - Скрипач(11.04.2010 18:40)
        
        "спасибо" на хлеб не намажешь - koyodza(12.04.2010 22:41)
        
        +1 После чего задержаться можно хоть и почти до конца следующего бита, но удобнее всё же до его начала закончить обработку. - ReAl(11.04.2010 17:25)
        
        Да,да, и период следования битов протоколом не ограничивается. Так, похоже, вполне нормально. Спасибо. - Скрипач(11.04.2010 18:47)

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