Pull to refresh

Comments 68

Извините, не понял перехода от «младший бит не используется» к «надо всего семь». Откуда еще 2 неиспользуемых взялись?
Вы немного запутались, что и немудрено. Там два типа регистров. Те которые за влажность отвечают, они в конце помечены «x2»? что видимо надо понимать как умноженные а два. Они просто делятся на два ну или сдвигаются вправо на байт.
А вот с теми что отвечают за температуру просто отасс.
Они помечены в конце как «x8» их сначало приходится сдвигать вправо на три, тоесть остаётся в них пять значащих. А потом добавлять по два бита из другого регистра в старшие разряды! В результате получаем также значащих 7 бит 8-3+2
Вот кусок кода, который это делает. Он грузит сразу четыре бита и занимается перестановками, формируя два значения калибровки для температуры из трёх исходных регистров

// 1. Read from 0x32 & 0x33 registers the value of coefficients T0_d egC_x8 and T1_de gC_x8
	// 2. Read from 0x35 register the value of the MSB bits of T1_deg C and T0_deg C
	if (!RDHTS221regs(adr_T0_degC_x8,buffer,4))
		return 0;
	HTS221str.T0_degC = (buffer[0]>>3)+(0x60&(buffer[3]<<5));
	HTS221str.T1_degC = (buffer[1]>>3)+(0x60&(buffer[3]<<3));


А, это разные регистры T/H. Не обратил внимание, спасибо.
Я специально полез в даташит, что бы разобраться что к чему. Мне кажется, вы не совсем поняли, для чего это было сделано.
А сделано это для повышения точности рассчетов. Ведь все рассчеты происходят в целых числах.

Если отбросить лишние биты, то вы огрубите все рассчеты. Намного правильнее проводить линейную интерполяцию в х8 и только в самом конце поделить на 8, что бы получить градусы. Иначе вы не получите заявленной точности в 0.5 градуса.

Вы можете считать что значения T0 и T1 — это числа с фиксированной точкой, при чем после точки идут три двоичных разряда.
Спасибо за интерес, но в даташите и их формулах, приведённых в апликейшине, почему то требуют производить сдвиги, я не сам это придумал, так что боюсь дело в чём то другом.
Извините, но в даташите в примере делят на 8 в самый последний момент. Как раз для того, что бы не терять точность. Не поделитесь ссылкой на аппноут? Хочу посмотреть как там.
Но не лучше ли тогда вручную сдвигать вправо на n бит, когда требуется точность?

Иногда такие странные вещи по причине обратной совместимости появляются.
Очень похоже на правду. Хотел подобный вариант в опрос включить, но забыл
Так мы нули получим справа. Вместо значащих бит. Сдвинув влево, автор поста загрубил калибровку в 8 раз.
Если отбросить лишние биты, то вы огрубите все рассчеты. Намного правильнее проводить линейную интерполяцию в х8 и только в самом конце поделить на 8, что бы получить градусы.

Но они то сами предлагают огрублять! Если одну пару значений «огрубить», а вторую нет то все расчёты «съедут» я полагаю.
Ну в даташите они огрублять не предлагают. Давайте посмотрим ещё аппноут.
The T0 and T1 calibration temperature values are
actually composed of 10 bits (unsigned), where the 2 MSB are in reg 35h, and the 8 LSB are
in regs 32h and 33h, respectively. T0 and T1 are the actual calibration temperature values
multiplied by 8.

А как тогда трактовать последнее предложение. Может прав lorc и можно посчитать с этими дополнительными тремя битами, а потом уже округлить?
Последнее предложение просто неаккуратно сформулировано.

Считать надо со всеми наличествующими битами, округлять — в самом конце.
Ну я бы именно так делал. Точность рассчетов будет выше на этих три бита.
Я так понимаю, калибровка происходит следующим образом: они охлаждают чип, очень точно замеряют температуру T0_deg и снимают показание АЦП, которое называют T0_OUT, потом подогревают чип, замеряют температуру T1_deg и замеряют показание АЦП которое станет T1_OUT.
Но у них заявленная точность 0.5 градуса, а, чувствительность — вообще 0.0016 градуса. Поэтому они не могут сохранить T0_deg и T1_deg в целых градусах. Поэтому они добавляют ещё три бита точности и таким образом хранят эти значения с точностью 1/8 градуса.
Пока ваши измерения между T0 и T1 — это в принципе не очень страшно. Но судя по примеру из даташита, у них T0 около +10, а T1 — около +20. Итого всего 10 градусов разницы. Поэтому если вы попробуете измерить температуту +40, у вас точность уже будет в два раза хуже, чем на промежутке 10-20. И с каждой десятков градусов точность будет падать ещё в два раза. Вот тут то вас и спасут три лишние бита.
Кстати, что до влажности 1000% — там скорее всего имелись в виду не проценты, а промилле (тысячные доли).
С одной стороны это вероятное предположение. С другой стороны измерения с помощью этого датчика дают показания в районе 20 — 29 в зависимости от погоды за окном. На улице сплошные дожди и я сильно сомневаюсь, что влажность у меня в квартире от двух до трёх процентов.
Ну я так понимаю, что показания 20-29 появились после того, как вы убрали умножение на 10:

Снова углубляюсь в даташиты чтобы понять откуда взялись этои странные множители “10” в расчётах по методу линейной интерполяции. Пол часа внимательной вычитки не проясняет причин их появления.

Пробую выкинутьих из кода и внезапно перемещаюсь обратно в среднюю полосу — 29 градусов и 20 процентов влажности.


До того, наверное, было 200 «процентов» влажности, не так ли? И 290 «градусов» (на самом деле 29.0).
Собственно, вот цитаты из того самого аппноута:

@param Pointer to the returned humidity value that must be divided by 10 to get the value in [%]

@param Pointer to the returned temperature value that must be divided by 10 to get the value in ['C]
Странная история. Упоминания об этих множителях есть только в комментариях к программе.
Нигде больше.
И цифры рассчитанные получаются явно не в процентах и градусах если их оставить в коде.
Да там вообще аппноут сделать отвратительно, честно говоря. Такое ощущение, что код писал один человек, а сам документ — другой (при чем, менее понимающий).
собственно и информация калибровки в регистрах тоже отвратительно сгруппирована
Отсюда и коэф. 10 в расчетах, вероятно.
Влажность 20% — как-то маловато, если вы не в центре пустыни живёте.
ну утром было 29. У меня есть смутное предположение что кулибины могли залить его слегка сверху лаком. Поскольку он ёмкостный это не должно полностью нарушить работоспособность, но вот как раз уменьшить показания влажности может.
Меньше 60, по идее, при комнатной температуре не должно быть.
ну я вроде бы не в джунглях однако
Если в Москве, то по прогнозу на ближайшие 10 дней – от 50 до 82 процентов на улице.
Около. Москвы.
Боюсь усердные монтажники реально покрыли датчик тонким слоем лака.
Под лаком он показывал бы всё время примерно одно и то же, независимо от реальной влажности. Флюсом скорее заляпали, даже если потом мыли — с датчика всё уже не смоется.

С учётом, что это очень плохо монтирующийся LGA (у них контактные площадки — медные необлуженные), запросто могли бахнуть побольше хорошего, текучего флюса.
Да нет влажность он определяет ёмкостным методом. Тонкая плёнка просто ухудшает чувствительность. С ёмкостными датчиками я слава богу повозился прилично за свою карьеру.
Эти датчики конкретно не видел, но все что мне попадались в аналогичных корпусах таки имели облуженные контакты.
Эти датчики конкретно не видел, но все что мне попадались в аналогичных корпусах таки имели облуженные контакты


Мы конкретно с этими тоже не работали, предпочитаем Sensirion. Но всё прочее у ST в таких корпусах, что мы используем — гироакселерометры, барометры — имеет на пузе тоненькую текстолитовую пластинку с необлуженными контактами. Вручную ставится сложнее, чем облуженные, т.к. при нагреве тут же окисляется — так что если монтажник ставил совсем руками, а не трафаретом-пастой-печкой, и думать он обучен не сильно, то он гарантированно в итоге решил флюса положить побольше, и хорошего — EFD, Amtech там какой-нибудь. А они при нагреве становятся очень текучими — и ими легко заляпать мелкий корпус сверху.
Впрочем, у нашего монтажника глаза стали квадратными, когда он увидел не это, а TI OPT3001, хехе.



Это не художник так видит. Это оно 2x2 мм размером и в полностью прозрачном корпусе :)

Первыми вопросами были «где тут первая нога?» (надо под 30-кратной лупой рассматривать кристалл, он немного несимметричный), «можно ли это брать пинцетом?» (можно) и «что это вообще такое???».
Спасибо за информацию. Этот проект не я курирую, меня пригласили в качестве программиста встраиваемых систем в него уже когда он пробуксовывать начал. Поэтому монтаж не я курирую, но вроде должны этим опытные люди заниматься. Сегодня постараюсь проверить как там на самом деле обстоит.
Ранее мне приходилось работать только с инерциальными датчиками от ST в подобных корпусах.
Надеюсь что даже если действительно флюсом залили то это не испортило его свойств окончательно.
Кстати, не сталкивались с тем, что у подобного рода датчиков нестандартные требования к монтажу пайке имеются. Ограничения по типам применяемых флюсов, температурному режиму и тому подобное?
Опытные люди — это такое понятие, относительно. От нашего монтажника, например, я с удивлением узнал, что есть мало мест, где люди паяют пастой и печкой — с ручным нанесением и ручной расстановкой. Лично он вообще с такими местами не сталкивался. В основном тыкают паяльником. В SMD. И феном в крайних случаях. С потрясающей производительностью и внешним видом пайки.

Ограничения по типам применяемых флюсов, температурному режиму и тому подобное?


Нет, не сталкивался. У датчиков влажности есть только требования по регидратации после пайки — то есть восстановлению датчика. Температуры — феном греть, вообще говоря, нежелательно любые компоненты, но мы по мере возможности всё паяем в печке, там 220 °С максимум. Флюсы по-любому используем неагрессивные, EFD или Amtech.

P.S. У барометров LPS331AP после пайки феном верхняя крышка рыжеет, как ржавая. Но показания выдают корректные.
Спасибо.
Датчики должны были паять вроде в Резоните. Достаточно солидная контора чтобы печки иметь. Впрочем, учитывая то что это пока лабораторные образцы в единичном исполнении, а плата очень простая, могли заказать ручную пайку и сэкономить на трафарете.
Ну тут есть разные варианты — паяльник, фен вручную, трафарет пластиковый с ручным нанесением, трафарет стальной с ручным нанесением, трафарет стальной на автоматической линии. Мы для мелких прототипов используем трафареты с ручным нанесением, например, причём пластиковые режем сами на бытовом плоттере за 17 тыр — по 0603 включительно он справляется нормально.

Как «Резонит» делает такие партии — не знаю, но монтажник, не оборудованный мозгом, может быть на производстве любого размера. Те же китайцы, например, на мелких партиях лажают просто невероятно и гонят сплошной брак.

Ну или как пример — тот же «Резонит» недавно нам переделывал стальной трафарет, т.к. их инженер сделал с ним необъяснимую хрень, обрезав лист практически по контуру платы.
Ну или как пример — тот же «Резонит» недавно нам переделывал стальной трафарет, т.к. их инженер сделал с ним необъяснимую хрень, обрезав лист практически по контуру платы.
Экономить начали? Раньше они делали просто огромных размеров трафареты даже для очень маленьких плат. Вообще у них бывают косяки, но следует признать что в основном на нестандартных заказах.
Вообще написали бы статью о том, как вы устроили своё штучное и мелкосерийное производство. Думаю многим было бы интересно!
Да не думаю, просто человек о чём-то своём думал. Может, день у него был неудачный.

У нас в заказе конфигуратор какой-то гигантский трафарет посчитал, я попросил сразу обрезать до 20x15 см — курьеру везти проще, нам больше не надо. Ну они и обрезали. До 10x7 или около того. По внешнему контуру падов плюс пять миллиметров — в гербере краёв платы даже не было.

Напишу обязательно, когда руки дойдут. Могу лишь сказать, что http://cameo-plotter.ru/shop/machines/curio.php — великая вещь, свою стоимость он окупил уже много раз.

Джунгли, не джунгли, а во https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B8%D0%BC%D0%B0%D1%82_%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%B2%D0%BE%D1%81%D1%82%D0%BE%D0%BA%D0%B0 летом влажность в районе 80-90% (временами и выше) — норма. Ну а для комфортного проживания, ЕМНИП, нужна влажность 40-60%, в противном случая начинают пересыхать слизистые оболочки носа, глаз. А так, относительная влажность в Сахаре около 30% :)

А так, относительная влажность в Сахаре около 30%

Честно говоря не ожидал!
На github есть коды к датчику — там не смотрели как люди считают? Есть разница с appNote?
Если есть ссылка, то киньте, с удовольствием посмотрю
https://github.com/search?utf8=%E2%9C%93&q=HTS221
Трудно найти здравое зерно в этом чулане. Либо обрывки кода, либо слишком глобальные творения — дрова под ОС какие то.
Вот тут насколько я понял используют в расчётах таки 10 битные значения без обрезки. Но странного умножения на 10 я не заметил. В общем надо будет тоже попробовать с 10 битными значениями поработать. Увеличится точность или нет не понятно, но не уменьшится это точно :)
UFO just landed and posted this here
Странно. Там вроде достаточно простые вычисления, совершенно непонятно почему float не хватает.
Температура у меня похоже нормально вычисляется. Грею рукой — показывает 34 градуса. Учитывая то что часть тепла уходит в плату — норма. Насчёт влажности есть некоторые сомнения пока. маловаты значения как то.
UFO just landed and posted this here
Спасибо. Теоретически возможен вариант когда H_T_ou t < H0_T0_ou t и тогда будет беда. Нужно беззнаковое значение использовать. Кстати, причём здесь множитель 10 я так и не понял. У вас с ним нормально считается?
точнее знаковое значение, сорри
UFO just landed and posted this here
Выражаю благодарность всем пользователям, принявшим участие в обсуждении, особенно хочется отметить mdn-tech, olartamonov и lorc. Исправил начальный вариант программы. Заменил переменные на float, что повысило точность вычислений. Показания влажности у меня после этого стали много более адекватными.
Попытка использовать младшие битики регистров H0_rH_x2,H1_rH_x2,H0_T0_OUT,H1_T0_OUT почему то не привела к повышению точности. В случае влажности она даже существенно упала.

Странно, а почему она вообще упасть может? Ведь это буквально аналогично умножению и последующему делению на 8 или 2

Не аналогично.
Для влажности в регистре калибровки H1_rH_x2 расположено совсем малое число. Половина разряда для него — существенная величина. В случае, если младший разряд в регистре на самом деле хранит ерунду, то может прилично снизить точность в такой ситуации. Грубо говоря когда я его учитывал то у меня получалась влажность более ста. Убрал стало выходить 57-58 процентов, что очень похоже на правду. Про дополнительную операцию деления после преобразований в случае лишнего битика я не забыл, сразу говорю.
Мы не знаем методику процесса калибровки. В младших регистрах может содержаться шумовая составляющая, а не полезные данные. Тогда учитывая их мы только снижаем точность вычислений, а не повышаем.
UFO just landed and posted this here
для 8 битного варианта микроконтроллера ваш код безусловно предпочтительней. Для ARMов с их ресурсами и гораздо лучше оптимизацией системы команд для вычислений с плавающей точкой вполне и мой вариант проходит. Умножение на 10 перед делением действительно несколько улучшает точность операции целочисленного деления.

ARM далеко не все с hardfp. Если говорить про Cortex-M, там hard fp есть у Cortex-M4F и Cortex-M7F.

Естественно, но даже какой нибудь Cortex-M0 который кстати и стоит у меня в этом проекте и то намного быстрее справляется с такими задачами чем PIC или AVR
У меня там по любому много вычислений с плавающей точкой и экономить лишних сто 50-100 байт нет смысла. Оптимизировать или нет код конкретного проекта под целочисленную арифметику каждый программист решает сам в зависимости от многих факторов.

В этом смысле да, soft fp на cortex-m существенно приятнее такового на avr или msp430. Поэтому довольно часто используют fixed point.


Я-то зацепился за


системы команд для вычислений с плавающей точкой

Конечно, удачный перенос строки (при отображении) перед этой строкой тоже сыграл свою роль =)

Да, я понял.
Теоретически решение от mdn-tech можно считать оптимальным. Для меня правда на последнем этапе всё равно следует перевести его во float. Появится немного времени я испытаю его со своими калибровочными значениями и если и с ними оно даст хорошую точность применю в своём проекте и исправлю в статье.
перевести его во float

Во всяких увлажнителях/осушителях это приходится делать, т. к. реально нужна абсолютная влажность, а там уже вычисления приходится делать с плавающей точкой, т. к. диапазон значений слишком большой. У вас аналогичная ситуация, это волюнтаристское решение или что-то иное?

У меня всё даже хуже — этот датчик часть газоанализатора.
Кстати, у меня тоже небольшой оффтопик. Почему вы перестали писать на эту площадку. Почитал вашу последнюю статью она очень недурственна и хорошо оформлена кстати.
У меня складывается впечатление что хабр угасает в последнее время как уникальное явление. На него всё меньше пишут независимые авторы, а пустоты заполняются позаимствованными с других сайтов новостями и «переводными статьями» от редакторов. Я вижу что очень многие авторы с хорошими рейтингами уже по два-три года не публикуют своих статей. Интересно почему перестали писать например вы?

В первую очередь из-за нехватки времени. Вещи связанные с микроконтроллерами — хобби, и времени на него сильно не хватает.
Есть задумки по другим темам, но они, скорее, сначала будут публиковаться в редхэтовских блогах, а потом переводится для хабра. Аналогично некоторые другие статьи тоже хочу сначала публиковать на английском, а позже на хабре, если будет не лень.


Но я не очень представляю, когда смогу найти на это время: есть ещё куча вещей по апачевскому проекту, где я committer & pmc, и по ansible, где я maintainer пачки модулей в core modules.

Понятно. Успехов! Впрочем для хабра программирование микроконтроллеров — гадкий утёнок, минимальные права на жизнь которого они признали с большим трудом.

Ещё один демотивирующий, хотя и слабый, фактор — относительно слабая реакция и невысокие оценки для статей узкой тематики. По сравнению с статьями «про котиков» типа новостей очередного браузера на движке хромиума или статей «как нажать далее-далее-готово». В общем, нормальные статьи теряются среди тонн этого мусора и оказываются недооценены, поэтому стараюсь их находить и вовремя плюсовать.

Полностью согласен. Беда в том, что мусора всё больше и больше, а авторских статей всё меньше и меньше. Причём в еженедельные и даже ежедневные топы попадает как правило мусор, во многом лжепереводы или слегка обработанные новости.
UFO just landed and posted this here
Спасибо, в ближайшее время поправлю код в статье с учётом ваших изысканий. Сейчас готовлю второй вариант платы к запуску, подправлю свой код, проверю работу, на практике, тогда выложу.
Sign up to leave a comment.

Articles