FlProg

тест 9,7,1

Датчик так себе: слишком медленный, и, более того, сильно нагружает МК.
И чем ниже битность, тем сильнее, потому что время транзакции всегда одно и то же, а вот количество опросов — чем больше, тем выше спам этих транзакций.


+ выбор пина
+ период опроса
+ выбор битности разрешения
+ режим работы
+ каждый датчик имеет свои собственные настройки


Шаг измерения:
9 бит — 0,5;
10 бит — 0,25;
11 бит — 0,125;
12 бит — 0,0625.

Несколько шин: конверсии идут параллельно, но транзакции на шине последовательные; каждая дополнительная шина добавляет ~9 мс шинного времени в цикл. Для 5 шин накинь ~+40 мс к минимуму:
9 бит — 100 мс;
10 бит — 200 мс;
11 бит — 400 мс;
12 бит — 800 мс.

Можно запрограммировать сам датчик на пороги температуры, и он сам будет сравнивать и слать только флаг выхода за диапазоны. Ограничение — это только целые числа.
В итоге вместо транзакции получения данных температуры в 6,67 мс тратим транзакцию длиною в 1,32 мс.
Пригодится может там, где не нужны данные температуры, но нужен мониторинг вне диапазонов, а также можно построить терморегулятор, опять же, если не нужны показания температуры.
Можно прошить его EEPROM датчика, но я не нашёл этому применение; взамен просто на этапе загрузки закидываем в его SRAM пороги и битность.


Результаты тестов:
Диспетчер отключен.
Опрос раз в 1000 мс, 12 бит.
Замер 5 сек — от начала данных до начала шестых данных, итого имеем 5 полных периодов опроса данных, усредняем к 1 сек.
Все замеры в 9,7,1:
— профильный блок;
— блок кандидатов;
— блок пользовательский.
Про кандидата уже ничего не хотелось бы говорить, но пока он опрашивает один датчик, профильный опросил 4 датчика.
Для понимания масштаба загруженности: при работе этих датчиков пустой код с измерителем пина крутится 101 000 раз в сек.
Можно подрубить в МК турбо на 160 МГц — будет пошустрее.
Работать с датчиком можно, но когда их очень много, то уже никакая частота не поможет и никакой МК.
И чем больше датчиков, тем больше фиксированных «дырок» в лупе в единицу времени измерения. Вот если б разрабам хватило ума встроить овердрайв в датчик, то тогда датчик работал бы в х10 раз быстрее.
В итоге шина умеет это делать а датчик нет.

Добрый день аесли работать через микросхему DS2480

Не пользовался таким. Да и потребности в нём нету.

Это что-то типа аппаратного модуля по работе с шинными датчиками: с одной стороны, снимаете нагрузку с процессора частично, потому что UART всё равно создаст небольшой фон в лупе, либо, если через прерывание делать, опять же, это некая дырка в лупе будет небольшая, конечно, только в этот момент уже по сравнению с датчиком программной реализации.

Но зато Wi-Fi не будет на него влиять своими прерываниями, но, опять же, подключить туда можно один датчик, скорее всего.

Я же показал вариант с пятью рабочими датчиками на не проблемных пинах. Хотя можно ещё добавить четыре пина, и того теоретически можно потянуть девять датчиков, только вот для работы не останется пинов тогда.

Был у меня проект, где я использовал шесть датчиков и Wi-Fi-мониторинг на страницу. Их блок я использовал какой-то из форума, пользовательский, не помню на тот момент, и в итоге никаких проблем у меня не было, да и в коде не было ничего такого критически важного, на чтобы влияли эти датчики. Потому что сам Wi-Fi — он просто их подвинет, и всё. Чтобы выполнить свои действия, опрос просто размазывался по лупу, даже если Wi-Fi порвёт транзакцию. Но ничего страшного: CRC не совпадёт, и всё, через секунду он восстановится со следующими данными, а блокировка переменной температуры не даст пройти мусору.

у меня с такой микросхемой работают до 20 датчиков на линии больше 70 метров правда не с контроллером с компом

lfgjikjjyj писал(а): 28 авг 2026, 19:32 Я же показал вариант с пятью рабочими датчиками на не проблемных пинах. Хотя можно ещё добавить четыре пина, и того теоретически можно потянуть девять датчиков, только вот для работы не останется пинов тогда.

Уважаемый lfgjikjjyj, поскольку нет самого файла flp с испытаниями датчиков, то можно только догадываться о схеме подключения. По видимому для каждого датчика вы создаёте отдельный вход. Но все датчики DS18B20 можно посадить параллельно друг другу на одну единственную шину. Протягиваются три проводка (GND,+V и общая для всех сигнальная шина 1Wire ). И так, параллельно от датчика к датчику протягиваете по 3 провода. Датчиков на одной шине 1Wire может быть очень много. Именно об этом и говорит уважаемый tolochko:

tolochko писал(а): 28 авг 2026, 20:29 у меня с такой микросхемой работают до 20 датчиков на линии больше 70 метров правда не с контроллером с компом

Вообще, конечно же, ваши испытания с графиками и численными значениями - великолепны. Спасибо вам за ваши труды, результаты очень полезны для всех кто пытается работать с микроконтроллерами.

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

Не приемлю паразитное питание, в этой цепочке — не 100% предсказуемость. Тем более, как любому аппаратчику, ему пофигу, как долго он будет тактировать этот датчик. Пусть он его тактирует хоть все 750 миллисекунд непрерывно вместо 9, а вот для контроллера это лишний удлинённый промежуток времени транзакции.
Хотя можно попробовать на rmt собрать есп32 как аппаратным вариантом работы но ими не планирую заниматься у меня шестьдесят шестых навалом пока что.

А отдельная шина 1-Wire для каждого датчика — там даже не надо знать адреса. Собираешь одной командой, как будто со всех датчиков. Замена датчика вообще беспроблемная: любой втыкаешь, втыкаешь следующий, втыкаешь — ему адреса не нужно. Ну и 100% предсказуемость: датчик не перескочишь, не промахнёшься, обращаешься к конкретному экземпляру со стопроцентной уверенностью. А также индивидуальные настройки для каждого датчика.