>> |
№91630
15729953699070.png
(1134Кб, 1363x964)
Показана уменьшенная копия, оригинал по клику.
Вообще с термостатом у меня возникла мысль, сделать самому, потому что по примерным прикидкам, ведро парафина обеспечит несколько часов стабильной в пределах тысячной доли градусов температуры, стоит недорого, и выбросить потом не очень жалко. Но хотелось иметь инструмент, чтобы проверить насколько эта конструкция реально будет держать температуру, я для этого нужен логгер с хорошим разрешением. На Али набрел на такую платку, с сенсором температуры с разрешением в 0.01 градус, барометром, позволяющим измерять даже высоту с разрешением меньше метра, датчиком влажности, и еще зачем-то металлооксидным сенсором "качества воздуха", попугаи, показывающие наличие спиртов, угарного газа, метана, аммиака, паров бензина, сероводорода и прочих вкусняшек создающих восстановительную среду, можно забабахать алкотестер, лол: https://ru.aliexpress.com/item/33007706017.html Из коробки обещалось что оно уже запрограммировано и выдает данные через UART, подключить через переходник в USB, и можно дампить в файл: https://imgur.com/a/MgCQLiq На деле, оно выдавало только буквы ZZ и какой-то бинарный мусор, хаотично переводящий позицию строки в терминале, китайская утилита для конфигурации под виндой вообще не стартовала, в вайне с локалью LC_ALL=zh_CN в упор не хотела видеть эту платку, хотя нужный COM-порт в нем точно был доступен (проверял запуском PuTTY в вайне). На плате на микроконтроллере не была затерта маркировка, stm32f051k8, и было два широких металлизированных отверстия, заведенных по дорожкам к отладочным выводам. Подумал, ну ладно, снесу что там наворотили китайцы и напишу прошивку сам. Сразу же оказалось что по маркетинговым соображениям, stm32f0 сделаны не совместимыми в мелочах с более старшими сериями с которыми я ранее работал, библиотека SPL имеет немного другое API и просто закопипастить привычный по предыдущим поделкам проект не выйдет, нужно брать новый. Склонил готовый проект https://github.com/szczys/stm32f0-discovery-basic-template , вставил отвечающий за UART и работу со строками код из своих часов, потратил пару часов на вылавливание неправильных флагов линкера (он упорно не хотел стрипать libstm32f0, потом не мог найти _start, в конечном итоге пришлось привести флаги к виду как в моих старых проектах). Сперва микроконтроллер вообще не детектился программатором. Проблема оказалась аппаратной, слишком длинный провод питания, при коротких проводах от программатора, земляная петля и большие искажения сигнала: https://imgur.com/a/SX4YQCe Пришлось подпаяться поближе, на саму плату, тогда удалось считать версию чипа и убедиться что он жив. Прошиваться через st-flash микроконтроллер упорно не хотел, так как жадные китайцы выставили защиту от записи. Штатным способом сбросить защиту от записи не получалось, так как в микроконтроллере успели сконфигурировать watchdog, он успевал перезагрузиться за время заливки прошивки до команды на запись, и все обрывалось. Пришлось ставить openocd и опытным путем подбирать задержки, так чтобы прошивка сумела случиться. После небольшого допила настроек gpio, отличающихся от stm32f1, uart заработал. Для сенсора Бош запилил готовую библиотеку: https://github.com/BoschSensortec/BME680_driver Склонил, добавил в проект, передал указатели на нужные функции для работы с I2C, скопипастил реализацию I2C со своих часов (на нем сидела микросхема RTC), не собирается. Оказалось, что i2C там реализовано вообще полностью иначе, и нужно вдумчиво копать референс мануал и смотреть как все реализовано. Я поленился это делать, нашел готовый код под более старый датчик, выдрал реализацию i2c c него https://github.com/Brandon2255p/BMP180-STM32F0/blob/master/src/bmp180.c На сборке библиотеки для сенсора начала постоянно вылазить ошибка линкера section .ARM.exidx loaded at [00005080,00005087] overlaps section .data.... Функции внутри библиотеки содержат очень жирные, передаваемые по значению структуры, они все не влазят в регистры хилого процессора, а раскидать их по стеку линкер не смог, видимо сразу упершись в его недостаточные размеры. Еще полчаса начала выкидывать лишние структуры и проверки на нулевые указатели, выпилить всю подсистему отвечающую за анализ газа, пока не собралось. Прошиваю - глухо висит. Пробую перебирать тайминги i2c шины, копипастить други реализации - все бестолку. Причем, по отзывам у всех с этим семейством микроконтроллеров есть какие-то проблемы. В итоге нервы у меня закончились, и я кастрировал эту плату ножницами по металлу и подпаялся прямо к i2c-шине датчика: https://imgur.com/a/m4Ixc5d Подавив ЧСВ, нагуглил пример под этот датчик для ардуины, подключил к ардуине, скачал проект под нее https://github.com/adafruit/Adafruit_BME680 Выбрал bme680test.ino, свалил все файлы проекта и поправил пути к хедерам, так как разбираться как штатно в ардуино-иде добавлять библиотеки мне уже совсем не хотелось, собрал, залил - не работает. Включаю дебажные принты, датчик не отвечает: BME680 test I2C $E0 <= 0xB6, I2C $D0 => Failed to read 1 bytes from 77 Result: -2 Уже как акт отчаяния, напаиваю сигнальные линии плат друг на друга, чтобы исключить длинные провода и возможные искажения: https://imgur.com/a/IYoo8PB Тот же результат. Уже сегодня, сутки спустя, печатая эти строки и вставляя картинку понимаю что оставил длинной землю, готовясь посыпать голову пеплом и думая как понижать саморазогрев ардуины возле датчика достаю выброшенный в мусорное ведро макет, укорачиваю провода питания и заземления, пробую включить еще раз... и чуда не произошло, тот же результат. Скорее всего, сенсор был дохлым изначально, и возможно с другой платой повезло бы больше, но потраченной пары выходных просто жалко, за это время я мог бы запилить свою конструкцию с намного большим разрешением, а не реверсить ревершенное китайцами. От чего и был сегодняший бугурт, собственно.
|