Программисты исстари делились на системных и прикладных. Датчик ничего решить не способен в принципе. Вопрос в том, который их двух программистов должен решать, что должен делать датчик.
На мой взгляд, если у датчика есть особенности (например, вносит искажения при чрезмерно частом использовании), то эти особенности следует учитывать системному программисту и не перекладывать на уровень прикладного. Последний должен думать о том, как правильно употребить показания датчика, а не как правильно их получить.
Что мешает тебе это в коде выплатить и добавить в Вики-тему? Гордость, может?)
Да я не спорю ни разу. Этот класс я использую именно в таком виде, опрашиваю из диспетчера задач, потому внутренними таймерами не заморачивался. Даже разрешение датчика там не устанавливаю - у меня температура выводится без дробей, потому точности 0,5 градуса - за глаза. И отдельной библиотекой не выкладывал, потому что только для одного датчика. Здесь же вики, а не гитхаб - просто примеры 
Вставлю и свои пять копеек 
Решать, что должен делать датчик, должен тот программист у которого датчик . Я говорю о тех, кто будет читать этот форум.
Вы оба правы, но каждый по своему.
Админ/у/ам я бы предложил наметить (или предложить) план раскрытия темы, ну например:
Назначение
- т.диапазон датчика
- разрядность
- время обработки результата
Железячные вопросы:
- схемы подключения, в том числе с гальванической развязкой
- длина линии, выбор сопротивления.
Логика работы датчика:
- префикс
- команды
- контрольная сумма, алгоритмы подсчета
Вот тут есть обо что копья поломать
Я как-то так бы написал 
Ну, тогда и я анекдот расскажу:
Сцепились как-то два спорщика и решили идти к раввину, чтоб он их рассудил. Приходят. Рассуди нас, говорят, Рабби 
Хорошо, отвечает раввин, пусть каждый выскажет свое мнение. Первый рассказал, и раввин сказал — ты прав! Рассказал и второй, и раввин сказал — и ты тоже прав! Подошел к спорщикам прохожий и спросил — Рабби, как это можно — и этот прав, и этот прав? 
На что раввин ответил — и ты тоже прав 
.
Ну, вы поняли я к чему
К примеру, датчик используется изредка. А тогда зачем мне его регулярно долбить с временем преобразования? Или же ты предлагаешь мне делать коррекцию результата при постоянном опросе?
Замечательный прием в споре: приписать оппоненту заведомо абсурдную точку зрения, чтобы потом с блеском ее опровергнуть.
Я где-то говорил “долбить постоянно”?
Делать нужно по уму: не опрашивать физически чаще, чем это допустимо. Например, не следует опрашивать чаще раза в секунду:
- если прикладная программа опрашивает 100 раз в секунду, физически опрашивать раз в секунду,
- если прикладная программа опрашивает 2 раза в секунду, физически опрашивать раз в секунду,
- если прикладная программа опрашивает 1 раз в секунду, физически опрашивать раз в секунду,
- если прикладная программа опрашивает раз в 2 секунды, физически опрашивать раз в 2 секунды,
- если прикладная программа опрашивает раз в час, физически опрашивать раз в час.
Всё равно есть нюансы. В данном случае getTemperature() получает результат предыдущего преобразования, а мне нужно текущего. А значит нужны изгаления, учитывающие особенности датчика. Либо задавать период опроса, либо получать данные по готовности.
Делать двойной опрос с интервалом в секунду
Ага, совсем наглядно.) Проще задавать в классе приемлемый период опроса. А тогда и в классе можно делать опрос, получая результат в любой момент. С другой стороны, во многих библиотеках указывается период опроса датчиков, и почему то их не волнуют проблемы начинающих.)
А Вы точно уверены, что то, что Вы утверждаете, что нужно, на самом деле нужно?
Есть такое понятие как погрешность. Общее правило, что погрешность имеет величину в одну-две единицы младшего разряда. Причем, погрешность, очевидно, существует как по оси амплитуды, так и по оси времени. Отсюда непосредственно следует, что задержка в показаниях на одну-две единицы (т.е. получение результата предыдущего преобразования, и даже пред-предыдущего) - это вполне допустимая погрешность.
Нет, в любой момент не получится, обработка данных идет 750мс. Т.е. либо мы ждем и блокируем работу, либо делаем двойной выстрел и получаем результат с запаздыванием в секунду.
я в классе в первых строках тоже написал
void readData() - опрос датчика; следует вызывать не чаще одного раза в секунду
ЗЫ: а если нужно получать данные именно в момент запроса, то и датчик нужно выбирать соответствующий. Ну хотя бы NTC
Ну это же ВЫ начали за час, а за час даже дом может успеть прогреться.) К примеру, я нажимаю кнопку и вижу предыдущую температуру. Текущую я увижу только через секунду. Как бы терпимо, но как то не аккуратненько.
1 лайк
А ты думай, что видишь текущую температуру и жить станет легче 
Это да. Так бы щёлк и увидел +9, но вчера, а через секунду 0, но сегодня.(
«Недостатки математического образования с наибольшей отчётливостью проявляются в чрезмерной точности численных расчётов»
(Карл Фридрих Гаусс)
Если заменить “расчетов” на “измерений”, а “математического” на “физического”, на истинность утверждения это не повлияет.
Еще раз: нормальная погрешность - это 1-2 единицы младшего разряда. И “предыдущая” и “пред-предыдущая” этому условию удовлетворяет. Все остальное - каприз, связанный с недостатками образования.
1 лайк
а скорость света почему не учитываете? для измерения температуры за бортом это очень важно
Вопросов больше не имею.
Рад за Вас.
Но, тем не менее, попытаюсь изложить, как я вижу решение следующей задачи:
Составить таблицу ежедневных данных по температуре в моменты времени: “6:00”, “12:00”, “18:00” и “24:00”.
- Выбираем периодичность опроса датчика температуры. Пусть будет раз в 3 минуты.
- Заносим во временную память результаты измерения с выбранной периодичностью (возможен оперативный анализ на достоверность с возможностью оповещения оператора).
Далее на примере точки “12:00”. - В момент времени “15:00” анализируем массив данных за интервал 9:00 - 15:00 (всего 121 значение).
- Добавляем к анализу данные по предыдущим (точки “6:00” и ранее) измерениям.
- Добавляем к анализу данные по температурам на ту же календарную дату в предыдущие годы.
- На основании всего этого вычисляем и заносим в ячейку “12:00” значение температуры. Попутно оцениваем достоверность и, если она вышла за допустимые пределы, посылаем сообщение оператору.
Вот как-то так.
И, кстати, (как это ни странно!) выдача результата измерения, произведенного датчиком температуры на предыдущем шаге, не не приведет к 6-часовому смещению результатов во времени.
Это к тому, что любые измерения надо организовывать по уму. Поэтому доводы типа “а вот если я сделаю какую-то глупость, датчик ведь выдаст не то значение, которое мне нужно” я считаю несостоятельными.