Проекты с использованием протокола OneWire
На главную
Обзор программ
Обзор плат
Проекты на базе:
Arduino Nano
Arduino Uno
Arduino Pro Micro
Arduino Mega
Digispark
Проекты с использованием:
Потенциометр
Джойстик
Кнопка
Реле
RGB
Дисплей
SD карта
Электрон.
ключ
Энкодер
Сдвиг. регистор
Д. температуры
Д. влажности
Д. растояния
Д. газа
Батарея
Средства связи:
Bluetooth
Android
GSM
USB
I2C (TWI)
SPI ICSP
UART
One Wire
Парал.
интерфейс
Двигатели:
Шаговый мотор
Постоянного тока
Servo
Еще:
О нас
Oбъявление
Обратная связь
YouTube канал
Проекты с использованием протокола OneWire
Самодельный GSM контроллер отопления на базе Arduino UNO и модуля SIM800L
Как сделать самодельный контроллер для управления циркуляционным насосом для отопления.
Удаленное управление отоплением по SMS, и запрос данных о температуре влажности и состоянии сети 220 вольт
Открыть полностью
Дубликатор домофонных ключей на базе Arduino NANO своими руками.
Статья о том, как сделать простой и бюджетный дубликатор домофонных ключей, для считывания и записи ключей RW1990.
К плюсам можно отнести: компактность, простоту сборки и использования, а так же возможность записи универсального или своего индивидуального кода.
Открыть полностью
Лучший эмулятор Arduino UnoArduSim V2.
6. Четвертая серия.
Набор из 5 простых скетчей, которые использовались в этой серии.
В этой серии рассматриваются модули: SPI, I2C, One Wire (датчика температуры DS18b20), функция осциллограф, и модуль UNO который вы не найдете не в одном другом эмуляторе.
Открыть полностью
GSM сигнализация на базе Arduino UNO и GSM модуля SIM800l Версия 2.0
Обновленная версия GSM сигнализации, на базе Arduino UNO и GSM модуля SIM800l
В этой версии сигнализации 2.0 добавлена возможность постановки и снятия с охраны при помощи ключа таблетка, также теперь параметры сохраняются в энергонезависимую память, и в схему добавлено реле, которым также можно…
Открыть полностью
Автоматическое проветривание помещений на Arduino UNO MH-Z19B и DHT11.
Контроль уровня CO2 и влажности.
Статья с материалами, для изучения и сборки контроллера уровня CO2 и влажности в помещениях, на Arduino UNO MH-Z19B и DHT11.
Управление прибором осуществляется, при помощи ANDROID устройства.
Для связи используется Bluetooth модуль HC-06.
Открыть полностью
1-wire
Технология достаточно старая и широко употребляемая
Изначально, выведена на рынок компанией Dallas — Все помнят таблетки для домофонов iButton- это оно
Устройство соединяется с контроллером по одному проводу (кроме общего) — отсюда название. Большое преимущество в том, что каждый чип имеет свой адрес, что позволяет термометры соединять просто параллельно
Я провел массу экспериментов с данным стандартом.
Спешу поделиться результатами:
Хуже всего, если для управления 1-wire шиной не использовать никаких специализированных контроллеров (подключение напрямую к PIN у Arduino устройств) — в этом случае, проблемы возникают уже при длине кабеля более 3-х метров
Для моих целей такое расстояние не подходило, поэтому я использовал I2C to 1-wire мост DS2482-100
Стоимость чипа на Aliexpress менее 100 руб, чип имеет аппаратный драйвер шины с режимом strong-pullup, что в разы увеличивает надежность работы системы.
Альтернативные решения, как правило, используют USB контроллеры шины 1-Wire на основе DS2490 но это подразумевает использование компьютера в составе контура управления. По опыту, надежность комплексного решения, включающего в себя PC, операционную систему, ПО, сетевую инфраструктуру, в любом случае ниже решения, локализованного в пределах одного контроллера. Поэтому ответственные задачи регулирования я реализовывал таким образом, что это регулирование происходит автономно, контроллером.
У себя я использую шлейф длиной около 150 м.
Термометры опрашиваются, относительно, устойчиво, что позволило предельно дешево и управляемо реализовать систему управления теплыми полами. Но сбои в считывании значений датчиков присутствуют. (В особенности, когда задействовано диммирование освещения или работает приточная вентиляция с фазовой регулировкой мощности нагревательного элемента)
Контроллер опрашивает датчики циклично, поэтому, единичные сбои не влияют на функционирование.
Если датчик не смог прочитаться 20 раз — нагревательный элемент отключается.
На практике, я рекомендовал бы, все же, не превышать длину шлейфа в 100м для более устойчивой работы.
Кроме термометров, я пробовал использовать самую разнообразную перефирию, вооружившись Datasheet — ами написав множество процедур для управления следующими чипами и устройствами на их базе:
DS2413
DS2408
DS2890
Если коротко — себя это не оправдало
Основная проблема — все же не очень хорошая помехозащищенность
Борьба с помехами в сети 1-Wire
Это, пожалуй, самое непростое в данной технологии.
Описываю свой опыт:
- Шину 1-Wire прокладывайте на расстоянии от высоковольтных проводов, трансформаторов LED освещения и проводов LED освешения (провода дают сильную помеху за счет того, что сила тока велика и используется ШИМ модулирование)
- Не надо использовать экранированную витую пару. Я проложил STP 5-й категории, но при попытке заземлить экран — связь полностью теряется. Предполагаю, что это связано с увеличением емкости проводника.
- По отзывам, невитая пара (самый дешевый двужильный провод) дает лучший результат.
- Хороший опыт — подтягивать дальний конец провода через резистор 3-4 КОм к стабилизированному фильтрованному источнику питания 5Вольт.
- Отводы от шины в 2-3 метра, в целом, не ухудшают качества работы системы, но прилично упрощают монтаж.
SingleWireSerial — библиотека Arduino, поддерживающая однопроводную полудуплексную последовательную связь
Я работал над аппаратным отладчиком, использующим протокол debugWIRE, но не смог заставить его работать надежно.
Итак, я работал над собственным решением, которое привело к библиотеке SingleWireSerial. Он удовлетворяет следующим трем требованиям: однопроводная последовательная связь, чрезвычайно точная и надежная скорость до 125 кбит/с, а также возможность установки скорости связи во время работы.
Введение
Свет увидела новая библиотека Arduino: SingleWireSerial. Он поддерживает однопроводную полудуплексную последовательную связь. Используя функцию захвата входных данных микроконтроллеров AVR, он чрезвычайно точен и надежно поддерживает битрейт до 250 кбит/с. И, вопреки названию, его можно использовать даже в двухпроводном режиме.
История вопроса
Ранее в этом году я работал над аппаратным отладчиком, использующим протокол debugWIRE. Но я не мог заставить его работать надежно. Одна проблема заключалась в последовательной связи с использованием только одной линии (вывод RESET микроконтроллера). Люди придумывали разные решения, но ни одно из них не работало у меня надежно.
Итак, недавно я решил запрограммировать свое собственное решение, которое привело к Библиотека SingleWireSerial . Он удовлетворяет следующим трем требованиям:
- однопроводная последовательная связь,
- чрезвычайно точная и надежная скорость до 125 кбит/с,
- скорость связи может быть установлена во время работы.
Во-первых, обычно асинхронная последовательная связь осуществляется по двум проводам. Если кто-то хочет ограничить связь только одним проводом, это возможно. Но тогда должен быть строгий протокол о том, какой стороне разрешено передавать данные. Например, если мастер — это тот, кто отправляет запросы или запросы, на которые отвечает ведомый, ясно, кто находится в роли отправителя в каждый момент времени. Все это решается на программном уровне. На аппаратном уровне необходимо придумать решение, позволяющее двум сторонам отправлять и получать данные только по одному проводу. Или можно решить эту проблему и на программном уровне.
Во-вторых, если вы хотите передавать строки о температуре в помещении, то никто не будет раздражаться, когда в какой-то момент времени будет отображаться неправильная температура. Когда вы отлаживаете систему и из-за ошибки связи отображается неверное значение, то, конечно, это расстраивает. debugWIRE, к сожалению, не имеет какой-либо формы обнаружения ошибок, поэтому приходится полагаться на тот факт, что ошибки связи вообще нет. Так как скорость связи установлена равной системным часам, деленным на 128, при частоте системных часов 16 МГц скорость связи будет 125 кбит/с. Итак, нам нужна безошибочная последовательная связь на скорости 125 кбит/с!
В-третьих, если скорость обмена данными известна заранее во время компиляции, тогда picoUART, вероятно, является лучшей альтернативой. Однако с помощью debugWIRE мы узнаем о скорости связи только во время выполнения. Кроме того, мы хотим максимально приблизиться к скорости передачи данных микроконтроллера, которую мы хотим отладить, которая может отличаться от стандартной, поскольку тактовая частота контролируется внутренним RC-генератором.
Single-wire: аппаратное или программное решение?
Вы можете создать однопроводное последовательное решение в основном двумя способами. Во-первых, вы можете каким-то образом соединить линии TX и RX. Во-вторых, у вас есть только одна строка с самого начала.
Для соединения TX и RX требуется некоторое внешнее оборудование. В примечаниях по применению Microchip AN2658 это подробно описано с использованием двух транзисторов — одного инвертора и одного драйвера с открытым коллектором. Того же эффекта можно добиться более простым способом, подключив подтягивающий резистор к линии RX и диод между линиями RX и TX с анодом на линии RX, как показано на следующем рисунке.
Соединение TX и RX
Высокий уровень на линии TX не повлияет, т.е. общая линия будет подтянута резистором. Низкий уровень на линии TX опустит общую линию. Однако, в зависимости от того, какой тип диода используется, оно будет снижено только до 0,3-0,7 вольт. Этого должно быть достаточно для всех практических целей, потому что микросхемы CMOS обнаруживают низкий уровень до 0,3 В пост.
тока.
Использование этого небольшого дополнительного оборудования позволяет использовать аппаратный UART. Однако один раздражающий побочный эффект этого аппаратного решения заключается в том, что все отправленные байты также принимаются и должны быть проигнорированы.
Второй тип решения использует бит-бэнг, т. е. управление одним выводом с помощью программного обеспечения. Переключая направление вывода между входом и выходом (с низким уровнем), создается выход с открытым стоком, аналогичный приведенному выше. Обычные программные библиотеки UART не поддерживают это из коробки. Впрочем, адаптировать их не так уж и сложно. OnePinSerial — это такая адаптация SoftwareSerial для использования в отладчике debugWIRE. Однако он достаточно ломкий. Когда включено прерывание миллиса, а оно есть в описываемом отладчике, то OnePinSerial не получает надежно на скорости 125 кбит/с.
Совпадение захвата ввода и сравнения вывода
Одна из проблем с решениями UART с перебором битов заключается в том, что приходится полагаться на знание того, какой код производит компилятор, чтобы сгенерировать правильную синхронизацию.
И генерация кода может быть разной для разных версий компилятора. Например, в классе SoftwareSerial вы найдете код, компилируемый в зависимости от определенных версий компилятора. Конечно, можно использовать встроенный ассемблерный код, который дает вам полный контроль над тем, какие машинные инструкции выполняются. Однако решение, реализующее настраиваемую во время выполнения скорость связи с использованием этой техники, кажется мне серьезной проблемой.
Вторая проблема заключается в том, что прерывания, например прерывание по миллисекундам, могут спутать синхронизацию при приеме байта. Класс SoftwareSerial использует прерывание смены контакта для обнаружения заднего фронта начального бита. Если прерывание по миллисекундам инициируется непосредственно перед поступлением стартового бита, то процедура получения прерывания может в худшем случае начаться с опозданием на 6,7 мкс. Для более медленных битрейтов это может быть терпимо. Однако для 125 кбит/с битовое время составляет 8 мкс, поэтому можно легко пропустить бит.
Библиотека AltSoftSerial, которую я рассматривал в предыдущем сообщении в блоге, использует функцию под названием input capture . Это поддерживает отметку времени для определенных событий, таких как спадающий фронт. Значение таймера в этот момент времени сохраняется в регистре захвата ввода (ICR) и, возможно, вызывается прерывание. С помощью этой функции всегда можно получить точное время запуска стартового бита, даже если в это время обслуживалось другое прерывание. Если также записать время фронтов, следующих за начальным битом, можно легко восстановить переданный байт.
На самом деле, нужен еще и таймер, который сообщает вам, когда заканчивается байт. Этого можно добиться, используя функцию сравнения выходных данных с соответствием . Это двойная функция захвата ввода. Здесь нужно записать значение в выходной регистр сравнения (OCR), и если таймер соответствует этому значению, запускается некоторое заранее сконфигурированное действие, такое как изменение уровня выходного вывода или инициирование прерывания.
Установив значение таким образом, что после 8,5 битных времен такое прерывание будет вызвано, можно взять всю информацию, собранную путем записи времени нарастания и спада фронтов, и вернуть полученный байт.
Ускорение
Проблема с библиотекой AltSoftSerial заключается в том, что для каждого фронта в передаваемом байте возникает прерывание, и в конце передаваемого байта приходится выполнять много работы. Это не устойчиво при высоких битрейтах, то есть 115200 бит/с и выше.
Чтобы решить эту проблему, я поместил все вышеописанные вещи в одну процедуру прерывания. Это работало так себе, но не очень надежно. Чтобы докопаться до сути, я использовал (в очередной раз) свой логический анализатор Saleae. А без него мне, наверное, было бы тяжело разобраться в проблемах.
Вот установка, показывающая логический анализатор, плату FTDI, которая отправляет байты с разной скоростью связи, и Arduino UNO, работающую с новой библиотекой. Кстати: я использовал те же скетчи Arduino и скрипты Python для тестирования своей библиотеки, что и при оценке различных последовательных библиотек.
Экспериментальная установка
Я вставил код для генерации коротких импульсов в критических частях ISR. При этом я смог заметить две проблемы. Подпрограмме обработки прерывания требовалось слишком много времени для запуска и слишком много времени для завершения ISR.
Во-первых, время между задним фронтом стартового бита и временем сохранения ICR было довольно большим, как видно на следующем рисунке, который показывает, что происходит на скорости 125 кбит/с.
Начальное время ISR
Во втором ряду видны две метки. Первый сигнализирует момент времени, когда ICR был сохранен, второй — когда все настроено на запись входящего байта. Требуется 2,7 мкс, чтобы достичь момента, когда ISR сохранил ICR и переконфигурировал входной захват для записи нарастающих фронтов. Большая часть этого времени посвящена проталкиванию регистров в стек. Всего сохраняется 15 регистров, что занимает примерно 2 мкс. Кроме того, обработка прерывания занимает (в худшем случае) 10 тактов, а шумоподавление занимает еще 4 такта, что вместе составляет почти 1 мкс.
Если миллисекундное прерывание возникает непосредственно перед задним фронтом начального бита, это может привести к пропуску фронта и, следовательно, бита, т. е. к ошибке чтения. Мне удалось сократить время запуска, объявив ISR «голым», а затем сохранив и восстановив регистры с помощью встроенного ассемблерного кода. К счастью, известно, какие регистры нужно сохранять. Это позволило мне сохранить ICR раньше, чем все регистры были помещены в стек. Результат всего этого показан на следующей картинке (опять же на 125 кбит/с).
Тайминг с голым ISR
Как видно, время запуска уменьшено до 1,75 мкс (маркер P0). Вторая вспышка все еще относительно запоздала. Но это событие должно произойти до середины первого бита данных, что легко достижимо, даже если миллисекундное прерывание замедляет ISR.
В третьей строке отсчитывается время финишного периода ISR. Первый импульс сигнализирует о моменте, когда байт был прочитан, а второй сигнал указывает на момент непосредственно перед тем, как ISR выполнит «возврат из прерывания».
Как видно (маркер P1), это довольно много уходит в стоповый бит, оставляя программе пользователя не так много времени для обработки байта.
Способ решения этой проблемы заключается в уменьшении объема постобработки и уменьшении числа восстанавливаемых регистров. Я решил эту проблему, переписав все с использованием встроенного ассемблерного кода и применив функцию сопоставления выходных данных для определения середины битового времени в качестве точек выборки. Это позволило мне уменьшить количество регистров до 5 (вместо 15). Кроме того, я свел постобработку полученного байта к сохранению его в буфер и последующему восстановлению регистров.
Окончательная синхронизация со встроенной сборкой ISR
Как видно (маркер P0), теперь для завершения ISR требуется чуть менее 1 мкс. Таким образом, при скорости 125 кбит/с ISR возвращает 2,5 мкс до завершения обработки последнего бита данных, добавляя 5 мкс ко времени, в течение которого пользовательская программа может обработать полученный байт, по сравнению с предыдущей версией.
ICR теперь сохраняется через 1,3 мкс, и вопрос может заключаться в том, достаточно ли это короткое время, чтобы гарантировать, что следующий фронт (один из первого байта данных) не затирает ICR. Как уже упоминалось, прерывание по миллисекундам в худшем случае может занимать 6,7 мкс. Эти два времени в сумме составляют 8,0 мкс, что составляет всего один бит времени. По этой причине необходим более подробный анализ, учитывающий все допущения наихудшего случая, но исключающий любые артефакты, возникающие при измерении.
В худшем случае прерывание по миллисекундам использует 106 циклов. Мы должны добавить 4 такта инструкции, которая может выполняться между ISR millis и нашей ISR, затем 7 тактов для обработки прерывания и перехода к начальному адресу, и, наконец, 4 такта для нажатия одного регистра и чтения младшего байта ИКР. Как только мы прочитали младший байт, старший байт сохраняется во временном регистре. Задержкой в 4 цикла для распознавания края из-за шумоподавления можно пренебречь, поскольку эта задержка применяется ко всем краям.
Также можно игнорировать 2 цикла, которые необходимы для создания метки. В сумме получается 106+4+7+4 = 121 цикл, что на 7 меньше, чем 128. Другими словами, мы можем легко справиться с последовательным потоком битов, который на 5% быстрее.
Итак, что насчет других красных меток? Второй импульс сигнализирует о моменте времени, когда был настроен регистр совпадения выходного сравнения, что должно произойти до середины первого байта данных. Как видно из измерения P2, времени осталось достаточно. Третья красная вспышка — это момент времени, когда мы готовы сэмплировать первый бит. Это должно произойти до завершения первого бита. Предполагая, что 75% битового времени можно использовать, следует сделать это за 12,5% до конца. Как видно (маркеры P3), даже при 30% до конца тайминг не критичен.
Сказав все это, со 121 циклом мы очень близки к пределу, и если изменится реализация прерывания миллиса или генерация кода компилятором, могут возникнуть проблемы. Так что для гарантированной 100% безошибочной связи (даже в будущем) я бы отключил прерывание миллиса при использовании библиотеки на скорости 125 кбит/с.
Давайте, наконец, посмотрим, что происходит на скорости 250 кбит/с, когда вызывается прерывание по таймеру.
Отсчет времени отключен из-за прерывания миллиса
Маркеры P0 показывают, что коммуникационный ISR задерживается (скорее всего, из-за прерывания по миллисекундам). Вместо сохранения ICR через 1,4 мкс после заднего фронта начального бита требуется 3,7 мкс, прежде чем это произойдет. Однако никакого вреда не будет, потому что критическая точка времени составляет 4 мкс после спада. Однако установка OCR происходит на 400 нс позже (маркеры P1). В четвертом ряду нет желтых меток, которые отмечают точки выборки. И, следовательно, никакие байты не распознаются/не принимаются.
Эмпирические результаты
Я провел стресс-тестирование новой библиотеки таким же образом, как и другие программные и аппаратные UART. Результаты представлены в следующей таблице. Подводя итог, можно сказать, что библиотеку можно использовать на скорости до 125 кбит/с даже при включенном прерывании по миллисекундам.
Библиотека может справиться даже со скоростью 250 кбит/с, но в этом случае прерывание по миллисекундам должно быть отключено.
| Битрейт | Отклонение | Отклонение скорости RX | ||
| 1200 | -0.1% | -5.9% | +5.4% | |
| 2400 | -0.1% | -5.8% | +5.4% | |
| 4800 | -0.1% | -6.0% | +5.2% | |
| 9600 | -0.1% | -5.8% | +5.3% | |
| 19200 | -0.1% | -5.7% | +5.3% | |
| 38400 | -0.1% | -5.7% | +4.9% | |
| 57600 | -0. 2% | -5.3% | +5.1% | |
| 115200 | -0.2% | -5.3% | +4.8% | |
| 230400 | +0.6% | -4.2% | +5.3% | # |
| 7812 | -0.1% | -5.8% | +5.2% | |
| 15625 | -0.1% | -5.7% | +5.2% | |
| 31250 | -0.1% | -5.6% | +5.1% | |
| 62500 | -0.1% | -5.3% | +4.9% | |
| 125000 | -0.1% | -5.2% | +4.9% | |
| 250000 | -0.1% | -4.8% | +3.5% | # |
| 500000 | -0. 1% | ____ | ____ | |
| 1M | -15.9% | ____ | ____ | |
Отклонение скорости передачи и возможные отклонения скорости при приеме данных
(‘#’ = отсутствие миллисекундного прерывания, ‘*’ = 2 стоповых бита)
Резюме
Новая библиотека SingleWireSerial работает очень надежно и безотказно до 250 кбит/с. Он реализует последовательный интерфейс по одному проводу, но его также можно использовать в двухпроводном режиме. Итак, я, вероятно, буду использовать его в будущем во всех контекстах, в которых я использовал SoftwareSerial 9.0012 ранее, при условии, что соответствующие контакты доступны. И я определенно планирую использовать его в своем следующем испытании для реализации отладчика debugWIRE.
Первоначально эта статья была размещена по адресу https://hinterm-ziel.de/index.php/2021/10/30/one-line-only
Датчики— Эмуляция устройств 1-wire
спросил
Изменено 4 года, 3 месяца назад
Просмотрено 11 тысяч раз
Я хочу сделать микросхему ATTiny ведомой на шине 1-wire, с собственным серийным номером и списком команд для ее конкретных функций.
Я хочу знать, могу ли я использовать библиотеку one wire с сайта arduino для отправки данных в качестве ведомого устройства.
Например, у вас может быть ведомое устройство в одной комнате с несколькими типами датчиков, которые будут сообщать ведущему о запрошенной информации, или ведущее устройство может приказать ему управлять чем-то вроде жалюзи.
Вопрос Должен ли я контролировать линию шины и отвечать на запрос от мастера, а также учитывать, как обычный датчик будет отправлять данные? На какой частоте я должен запускать ведомое устройство, чтобы получить наилучшую функциональность?
Я не буду использовать паразитную силу, как примечание.
- датчики
- библиотека
- attiny
- 1-wire
6
Насколько я знаю, библиотека 1-wire, которую вы указали в своем вопросе, позволяет действовать только как мастер, а не как ведомый.
Я только что выпустил библиотеку для превращения платы Arduino в ведомое устройство 1-wire, здесь: https://github.
com/neuoy/OneWireArduinoSlave (изменить: перемещено сюда https://gitea.youb.fr/youen /OneWireArduinoSlave). Я использую его в своей пользовательской системе домашней автоматизации, и он работает безупречно в моей настройке (мастер 1-wire, DS9490R, подключен к ноутбуку через USB, а также обеспечивает питание Arduino, который является Arduino Uno). Библиотека обрабатывает низкоуровневые детали: сопоставление ПЗУ, отправку и получение байтов (что на самом деле довольно сложно сделать правильно, в основном невозможно без логического анализатора). Остальное зависит от тебя.
Он полностью реализован с помощью прерываний, все коммуникации выполняются в фоновом режиме, вы можете выполнять другой код, как обычно, параллельно, и получать уведомления с помощью обратных вызовов при получении байтов и т. д. Отправка байтов мастеру также асинхронна.
Я также знаю, что существует по крайней мере еще одна библиотека, https://github.com/MarkusLange/OneWireSlave, как прокомментировал выше Ryu_hayabusa.
