Comments 68
А вот с теми что отвечают за температуру просто отасс.
Они помечены в конце как «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));
А сделано это для повышения точности рассчетов. Ведь все рассчеты происходят в целых числах.
Если отбросить лишние биты, то вы огрубите все рассчеты. Намного правильнее проводить линейную интерполяцию в х8 и только в самом конце поделить на 8, что бы получить градусы. Иначе вы не получите заявленной точности в 0.5 градуса.
Вы можете считать что значения T0 и T1 — это числа с фиксированной точкой, при чем после точки идут три двоичных разряда.
Иногда такие странные вещи по причине обратной совместимости появляются.
Если отбросить лишние биты, то вы огрубите все рассчеты. Намного правильнее проводить линейную интерполяцию в х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. И с каждой десятков градусов точность будет падать ещё в два раза. Вот тут то вас и спасут три лишние бита.
Снова углубляюсь в даташиты чтобы понять откуда взялись этои странные множители “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]
Нигде больше.
И цифры рассчитанные получаются явно не в процентах и градусах если их оставить в коде.
Боюсь усердные монтажники реально покрыли датчик тонким слоем лака.
С учётом, что это очень плохо монтирующийся LGA (у них контактные площадки — медные необлуженные), запросто могли бахнуть побольше хорошего, текучего флюса.
Эти датчики конкретно не видел, но все что мне попадались в аналогичных корпусах таки имели облуженные контакты.
Эти датчики конкретно не видел, но все что мне попадались в аналогичных корпусах таки имели облуженные контакты
Мы конкретно с этими тоже не работали, предпочитаем Sensirion. Но всё прочее у ST в таких корпусах, что мы используем — гироакселерометры, барометры — имеет на пузе тоненькую текстолитовую пластинку с необлуженными контактами. Вручную ставится сложнее, чем облуженные, т.к. при нагреве тут же окисляется — так что если монтажник ставил совсем руками, а не трафаретом-пастой-печкой, и думать он обучен не сильно, то он гарантированно в итоге решил флюса положить побольше, и хорошего — EFD, Amtech там какой-нибудь. А они при нагреве становятся очень текучими — и ими легко заляпать мелкий корпус сверху.
Это не художник так видит. Это оно 2x2 мм размером и в полностью прозрачном корпусе :)
Первыми вопросами были «где тут первая нога?» (надо под 30-кратной лупой рассматривать кристалл, он немного несимметричный), «можно ли это брать пинцетом?» (можно) и «что это вообще такое???».
Ранее мне приходилось работать только с инерциальными датчиками от ST в подобных корпусах.
Надеюсь что даже если действительно флюсом залили то это не испортило его свойств окончательно.
Кстати, не сталкивались с тем, что у подобного рода датчиков нестандартные требования к монтажу пайке имеются. Ограничения по типам применяемых флюсов, температурному режиму и тому подобное?
Ограничения по типам применяемых флюсов, температурному режиму и тому подобное?
Нет, не сталкивался. У датчиков влажности есть только требования по регидратации после пайки — то есть восстановлению датчика. Температуры — феном греть, вообще говоря, нежелательно любые компоненты, но мы по мере возможности всё паяем в печке, там 220 °С максимум. Флюсы по-любому используем неагрессивные, EFD или Amtech.
P.S. У барометров LPS331AP после пайки феном верхняя крышка рыжеет, как ржавая. Но показания выдают корректные.
Датчики должны были паять вроде в Резоните. Достаточно солидная контора чтобы печки иметь. Впрочем, учитывая то что это пока лабораторные образцы в единичном исполнении, а плата очень простая, могли заказать ручную пайку и сэкономить на трафарете.
Как «Резонит» делает такие партии — не знаю, но монтажник, не оборудованный мозгом, может быть на производстве любого размера. Те же китайцы, например, на мелких партиях лажают просто невероятно и гонят сплошной брак.
Ну или как пример — тот же «Резонит» недавно нам переделывал стальной трафарет, т.к. их инженер сделал с ним необъяснимую хрень, обрезав лист практически по контуру платы.
Ну или как пример — тот же «Резонит» недавно нам переделывал стальной трафарет, т.к. их инженер сделал с ним необъяснимую хрень, обрезав лист практически по контуру платы.Экономить начали? Раньше они делали просто огромных размеров трафареты даже для очень маленьких плат. Вообще у них бывают косяки, но следует признать что в основном на нестандартных заказах.
Вообще написали бы статью о том, как вы устроили своё штучное и мелкосерийное производство. Думаю многим было бы интересно!
У нас в заказе конфигуратор какой-то гигантский трафарет посчитал, я попросил сразу обрезать до 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% :)
Вот тут насколько я понял используют в расчётах таки 10 битные значения без обрезки. Но странного умножения на 10 я не заметил. В общем надо будет тоже попробовать с 10 битными значениями поработать. Увеличится точность или нет не понятно, но не уменьшится это точно :)
Температура у меня похоже нормально вычисляется. Грею рукой — показывает 34 градуса. Учитывая то что часть тепла уходит в плату — норма. Насчёт влажности есть некоторые сомнения пока. маловаты значения как то.
Странно, а почему она вообще упасть может? Ведь это буквально аналогично умножению и последующему делению на 8 или 2
Для влажности в регистре калибровки H1_rH_x2 расположено совсем малое число. Половина разряда для него — существенная величина. В случае, если младший разряд в регистре на самом деле хранит ерунду, то может прилично снизить точность в такой ситуации. Грубо говоря когда я его учитывал то у меня получалась влажность более ста. Убрал стало выходить 57-58 процентов, что очень похоже на правду. Про дополнительную операцию деления после преобразований в случае лишнего битика я не забыл, сразу говорю.
Мы не знаем методику процесса калибровки. В младших регистрах может содержаться шумовая составляющая, а не полезные данные. Тогда учитывая их мы только снижаем точность вычислений, а не повышаем.
ARM далеко не все с hardfp. Если говорить про Cortex-M, там hard fp есть у Cortex-M4F и Cortex-M7F.
У меня там по любому много вычислений с плавающей точкой и экономить лишних сто 50-100 байт нет смысла. Оптимизировать или нет код конкретного проекта под целочисленную арифметику каждый программист решает сам в зависимости от многих факторов.
В этом смысле да, soft fp на cortex-m существенно приятнее такового на avr или msp430. Поэтому довольно часто используют fixed point.
Я-то зацепился за
системы команд для вычислений с плавающей точкой
Конечно, удачный перенос строки (при отображении) перед этой строкой тоже сыграл свою роль =)
Теоретически решение от mdn-tech можно считать оптимальным. Для меня правда на последнем этапе всё равно следует перевести его во float. Появится немного времени я испытаю его со своими калибровочными значениями и если и с ними оно даст хорошую точность применю в своём проекте и исправлю в статье.
перевести его во float
Во всяких увлажнителях/осушителях это приходится делать, т. к. реально нужна абсолютная влажность, а там уже вычисления приходится делать с плавающей точкой, т. к. диапазон значений слишком большой. У вас аналогичная ситуация, это волюнтаристское решение или что-то иное?
Кстати, у меня тоже небольшой оффтопик. Почему вы перестали писать на эту площадку. Почитал вашу последнюю статью она очень недурственна и хорошо оформлена кстати.
У меня складывается впечатление что хабр угасает в последнее время как уникальное явление. На него всё меньше пишут независимые авторы, а пустоты заполняются позаимствованными с других сайтов новостями и «переводными статьями» от редакторов. Я вижу что очень многие авторы с хорошими рейтингами уже по два-три года не публикуют своих статей. Интересно почему перестали писать например вы?
В первую очередь из-за нехватки времени. Вещи связанные с микроконтроллерами — хобби, и времени на него сильно не хватает.
Есть задумки по другим темам, но они, скорее, сначала будут публиковаться в редхэтовских блогах, а потом переводится для хабра. Аналогично некоторые другие статьи тоже хочу сначала публиковать на английском, а позже на хабре, если будет не лень.
Но я не очень представляю, когда смогу найти на это время: есть ещё куча вещей по апачевскому проекту, где я committer & pmc, и по ansible, где я maintainer пачки модулей в core modules.
Ещё один демотивирующий, хотя и слабый, фактор — относительно слабая реакция и невысокие оценки для статей узкой тематики. По сравнению с статьями «про котиков» типа новостей очередного браузера на движке хромиума или статей «как нажать далее-далее-готово». В общем, нормальные статьи теряются среди тонн этого мусора и оказываются недооценены, поэтому стараюсь их находить и вовремя плюсовать.
Один день программиста ембеддера. Написать драйвер для датчика влажности HTS221 от STM — это очень просто?