FastDS18B20_328_168 быстрый и универсальный режим работы

[lfgjikjjyj]

2025-11-08_100706.png

FastDS18B20_328_168_(Code_-_Professional).ubi

----------------------------------------------------------------------------------------------------------

FastDS18B20_328_168_v1.0_(Code_-_Professional).ubi

(можно подключить несколько датчиков в проекте но только один на каждый пин)
----------------------------------------------------------------------------------------------------------

для ардуино

Блок меньше грузит мк выдавая больше цыклов чем другие блоки
к примеру :
блок кандидатов - нагружает код в 21,6мкс или 46к цыклов в сек
из пользовательских блоках - помнится выдавал 222к цыклов в сек
FastDS18B20_328_168 - нагружает код в 1,7мкс или 593к цыклов в сек

Адрес датчика не считывается поэтому должен присутствовать только один датчик на каждом пине

ERROR = 1 нормально // 0 ошибка датчика

Время обновления данных не должно быть меньше минимального порога от выбраного разрешения
Интервал поиска датчика не должно быть меньше минимального порога от выбраного разрешения

Так же дополнительно на выбор -
Разрешение :
9 бит - 0,5 °C
10 бит - 0,25 °C
11 бит - 0,13 °C
12 бит - 0,0625 °C

Минимальный порог опроса :
9 бит - 100мс
10 бит - 200мс
11 бит - 400мс
12 бит - 800мс

с быстрым опросом особо не увлекаться ибо сам датчик забирает в каждом опросе 8,8мс себе на обработку не зависимо от битности

[montirovka]

Решил проверить блок FastDS18B20_328_168 с уже припаянным датчиком DS18B20 к плате ESP12F. Сравнил с блоком от Гайвера.
Блок FastDS18B20_328_168 оказался быстрее блока Гайвера.

[lfgjikjjyj]

под есп надо адаптировать
но даже с ним чистый фпс так скажем у 8266 равен 161к цыклов сек это при 80мгц в равных условиях с атмегой на этом блоке
тут можно сказать что ардуина в почти 4 раза круче при работе с этим датчиком
можно конечно включить турбо на 8266 до 160мгц но это всеволиш удвоит цыклы до 322к что всеравно не дотянет до ардуино
притом что надо почитать можно ли регистры закинуть доступ к пину шины ваера тогда ардуина будет ещё быстрее
так же можно и на 8266 почитать о регистрах но ардуино она всеравно не перегонит в этой ситуации слишком много оберток

и в флпроге использовать подщёт цыклов плохая идея она помоему на микросах построена а те притом маштабируеются ещё не помню но там муть с ними какая то уже изучал этот вариант
самое идеальное найти время работы чистого пина а потом время кода и отнять из него этот самый измерительный пин это и будет чистовой фпс но опять же при условии влияния флпрога но тут уже никуда на нём все и крутится

[lfgjikjjyj]

По поводу замеров
Вы берете кусочки времени исполнения лупа в течении секунды и видите допустим их было как вы говорите 99к примерно
Но туда у вас вошло весь мусор и чтение датчика и какоето событие от самого флпрога и сам уарт смазал сильно результат ...
Более того каждая секунда может быть разная сойдутся в одной куча запросов и вовсе получите пробелы на пару сек как у меня было на 8266 с 6 дэсками и вай-фай...
Да важный параметр но не объективный а выборка из времени работы мк

Я же беру точечный момент когда ничего не происходит и Луп бегает по остаточные повторяющимся строчкам
К примеру тот же датчик да он сделал запрос в течение 8.8мс и с этим ничего не сделаешь уже но после него осталось время повторения лупа - это время что вы оставили мк для других задач
Так вот это время оно чистое я его эфимерно привожу количественно к секунде
Почему эфимерно так сделаем опрос более 1 сек и уже оно не будет эфимереым и будем видеть действительно в какой-то момент у нас как я уже приводил на 8266 будет 161к просто я его вычислил через один чистовой промежуток лупа
И когда вы начинаете править оптимизировать код допустим того же датчика то вы сразу видите отклонение того времени что вы оставляете мк после себя
Да оно мизерное но весь луп потом и сложится из этих кусочков
К примеру я могу опросить своим блоком более 10 датчиков в то время когда штатный сможет опросить только один датчик за это же время - отсюда и идёт дайте нам мк с побольше частотой а то с маленькой не справляется в видение одной архитектуры
Да можно включить турбо на 8266 под 160мгц будет в два раза быстрее но и иногда не стабильные а можно оптимизировать и остаться на 80мгц стабильными будет быстрее притом ещё

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

[ecoins]

Решил проверить блок FastDS18B20_328_168 с уже припаянным датчиком DS18B20 к плате ESP12F. Сравнил с блоком от Гайвера.
Блок FastDS18B20_328_168 оказался быстрее блока Гайвера.

Рекомендации для тестирования - не используйте при выводе строковые переменные.
Работа со строками поглощает много ресурсов процессора - память и быстродействие.
Блоки консоли позволяют работать напрямую с численными переменными.

FastDS1820_png.png

Fast_DS18B20_ESP12F_9.6.4_eis.zip

И возможно при работе на ESP32 этот блок работать не будет, особенно если проект большой. И при работе Wi-Fi в особенности.
Как ни странно в силу особенности архитектуры на ESP32 работа с пинами не очень быстрая, на больших проектах это ограничение начинает сказываться.
Поэтому в FLProg и появилась своя библиотека OneWire и DS1820.
И блок из кандидатов в условиях помех будет работать существенно быстрее - в нем повторяются только транзакции, которые были с ошибками из за помех на линии или прерывания Wi-Fi в момент какой-то транзакции.
----
По быстродействию блока из кандидатов.
Не думаю, что он медленнее. Возможно не корректен метод измерения.
-----
С уважением, ecoins.

[montirovka]

Решил проверить блок FastDS18B20_328_168 с уже припаянным датчиком DS18B20 к плате ESP12F. Сравнил с блоком от Гайвера.
Блок FastDS18B20_328_168 оказался быстрее блока Гайвера.

Рекомендации для тестирования - не используйте при выводе строковые переменные.
Работа со строками поглощает много ресурсов процессора - память и быстродействие.
Блоки консоли позволяют работать напрямую с численными переменными.
FastDS1820_png.png
Fast_DS18B20_ESP12F_9.6.4_eis.zip

И возможно при работе на ESP32 этот блок работать не будет, особенно если проект большой. И при работе Wi-Fi в особенности.
Как ни странно в силу особенности архитектуры на ESP32 работа с пинами не очень быстрая, на больших проектах это ограничение начинает сказываться.
Поэтому в FLProg и появилась своя библиотека OneWire и DS1820.
И блок из кандидатов в условиях помех будет работать существенно быстрее - в нем повторяются только транзакции, которые были с ошибками из за помех на линии или прерывания Wi-Fi в момент какой-то транзакции.
----
По быстродействию блока из кандидатов.
Не думаю, что он медленнее. Возможно не корректен метод измерения.
-----
С уважением, ecoins.

А можно увидеть проект этот же проект только что бы корректно показывались минусовые температуры? Переменная в формате unsigned long не позволяет отображать минусовые значения. Поэтому я сделал через string. Я вот здесь про это писал. В версии FLProg 9.6.7 эту проблему не исправили?

[ecoins]

Решил проверить блок FastDS18B20_328_168 с уже припаянным датчиком DS18B20 к плате ESP12F. Сравнил с блоком от Гайвера.
Блок FastDS18B20_328_168 оказался быстрее блока Гайвера.

Рекомендации для тестирования - не используйте при выводе строковые переменные.
Работа со строками поглощает много ресурсов процессора - память и быстродействие.
Блоки консоли позволяют работать напрямую с численными переменными.
FastDS1820_png.png
Fast_DS18B20_ESP12F_9.6.4_eis.zip

И возможно при работе на ESP32 этот блок работать не будет, особенно если проект большой. И при работе Wi-Fi в особенности.
Как ни странно в силу особенности архитектуры на ESP32 работа с пинами не очень быстрая, на больших проектах это ограничение начинает сказываться.
Поэтому в FLProg и появилась своя библиотека OneWire и DS1820.
И блок из кандидатов в условиях помех будет работать существенно быстрее - в нем повторяются только транзакции, которые были с ошибками из за помех на линии или прерывания Wi-Fi в момент какой-то транзакции.
----
По быстродействию блока из кандидатов.
Не думаю, что он медленнее. Возможно не корректен метод измерения.
-----
С уважением, ecoins.

А можно увидеть проект этот же проект только что бы корректно показывались минусовые температуры? Переменная в формате unsigned long не позволяет отображать минусовые значения. Поэтому я сделал через string.

Блок из кандидатов мы когда тестировали - вроде бы работал во всем диапазоне температур.
Выше +80 градусов не стоит мучать.
Есть хорошая и более дешевая альтернатива - NST1001.
Работает в широком диапазоне температур.
В кандидатах есть блок.
Есть использовать подключение по принципу один пин - один сенсор, то NST1001 похоже лучше по всем параметрам(диапазон, точность, быстродействие).
С уважением, ecoins.

[montirovka]

Я про минусовые температуры.

2025-11-10_10-43-40.png

[lfgjikjjyj]

Я не говорил что кандидат медленный я сказал что он оставляет меньше ресурсов для мк
Что у меня что у кандидата ускорить получение данных не получится ибо сам датчик очень медленный и временые рамки фиксированные на получение данных
Речь шла о предоставлении ресурсов времени для мк после опроса датчика
Вы получили данные убедились что они целостные примерно 10мс оторвали от секунды а вот дальше те строчки что притащил блок в Луп уже валяются баластом по сути на мк тратит время бесполезно и речь шла о сокращении этого времени

А есп32 там всё просто есть задумка отказаться от ваера и уйти на апаратник рмт и тогда ни КПУ или вай-фай или блютуз не будут оказывать на датчик никакого влияние

[Phazz]

Решил проверить блок FastDS18B20_328_168 с уже припаянным датчиком DS18B20 к плате ESP12F. Сравнил с блоком от Гайвера.
Блок FastDS18B20_328_168 оказался быстрее блока Гайвера.

Рекомендации для тестирования - не используйте при выводе строковые переменные.
Работа со строками поглощает много ресурсов процессора - память и быстродействие.
Блоки консоли позволяют работать напрямую с численными переменными.
FastDS1820_png.png
Fast_DS18B20_ESP12F_9.6.4_eis.zip

И возможно при работе на ESP32 этот блок работать не будет, особенно если проект большой. И при работе Wi-Fi в особенности.
Как ни странно в силу особенности архитектуры на ESP32 работа с пинами не очень быстрая, на больших проектах это ограничение начинает сказываться.
Поэтому в FLProg и появилась своя библиотека OneWire и DS1820.
И блок из кандидатов в условиях помех будет работать существенно быстрее - в нем повторяются только транзакции, которые были с ошибками из за помех на линии или прерывания Wi-Fi в момент какой-то транзакции.
----
По быстродействию блока из кандидатов.
Не думаю, что он медленнее. Возможно не корректен метод измерения.
-----
С уважением, ecoins.

А можно увидеть проект этот же проект только что бы корректно показывались минусовые температуры? Переменная в формате unsigned long не позволяет отображать минусовые значения. Поэтому я сделал через string. Я вот здесь про это писал. В версии FLProg 9.6.7 эту проблему не исправили?

а зачем вы используете Ulong?

[montirovka]

Я не понял кому был адресован вопрос. Отвечу я за себя. У меня формат string. Почему так, я написал выше.
Сделал два проекта для ESP32. Один с датчиком NST1001 и блоком из кандидатов, а другой с DS18B20 и блоком из этой темы.
NST1001.

2025-11-10_18-05-34.png

Результат теста.

2025-11-10_18-02-38.png

Fast DS18B20.

2025-11-10_17-43-48.png

Результат теста.

2025-11-10_17-40-18.png

Я просто сравнил на голом проекте. До сегодняшнего дня я не делал проектов на NST1001. Понравилась скорость изменения температуры. То что датчик малюсенький, скорость большая. По даташиту максимальная длина линии до 2 метров. Как работает с более длинной линией хотелось бы узнать.
Про блок FastDS18B20_328_168. Наверное надо выход Error поменять на Ok.

[Ander]

А поменяйте в плате задачу со свободной на медленную (1 рас в сек) интересен результат будет.
а второй тест вовсе без диспетчера.

[montirovka]

Без диспетчера с блоком NST1001.

2025-11-10_19-47-02.png

Медленная задача NST1001.

2025-11-10_19-50-38.png

2025-11-10_19-51-45.png

FastDS18B20 сегодня не успею тест сделать.
Завтра с утра сделаю.

[Ander]

Спасибо.