Всем привет, возникла такая проблема, может кто сталкивался? Заказал датчик движения HC-SR501. По описанию продавца он выглядит так
На деле получил вот это
Нет электролитов, но там я как понял стоят танталовые конденсаторы, нет стабилизатора на 3,3 в, это тоже решаемо, но самое главное нет джампера на H/L, там стоит резистор на 10 кОм и датчик работает в режиме L. А мне надо H. Можно ли что-то сделать, удалить, перемкнуть? Может кто в курсе? За качество фото сорри.
Мой долгострой. Проект далек от завершения. Но промежуточные результаты уже не стыдно показать. Плата моей разработки, заказана у китайцев. 180 диодов ws2812b-mini, wemos d1 mini в качестве контроллера. Эксперименты с генерацией палитр и нестандартными таблицами мэппинга.
Да, название копия из оригинального поста Народный измеритель пульсации света Сей же пост не плагиат, а вариант другого исполнения, ещё более бичёвского и простого в реализации, но код, практически, оригинальный.
Для понимания принципа работы измерителя, читайте оригинальную статью, уважаемого ammo1.
Немного вступления
В оригинале, используется дисплей TFT 1.77, который стоит от 165рублей на текущий день, а я использовал oled 0.96 4 pin, что стоит аж 110 рублей. Вы сейчас посмеётесь, дескать 55 рублей, того не стоят, но это цены на али, в наших магазинах, может быть совсем другая разница.
Кроме того, я поменял NodeMCU из оригинала на WeMos d1 mini, т.к. wemos дешевле и компактнее, но сам мк esp8266 тот же. К сожалению, в отличие от NodeMCU, питать WeMos d1 mini 9 вольтовой батарейкой, не выйдет, потому что, максимальное напряжение 6В, об этом ниже.
Питание
На оригинальном WeMos d1 mini должен быть стабилизатор ME6211C33, но, похоже, на али, дешёвыми, продаются именно клоны, на которых установлен стабилизатор с маркировкой 4b2k, которой обозначается XC6204B332. Оригинальный wemos d1 mini можно питать напряжением до 6В, клоны так же придерживаются этого. У меня есть аккумуляторы 18650, извлечённые из мёртвой батарейки ноутбука, один из них и питает самоделку. Можно использовать пальчиковые батарейки, а ещё проще от внешней батареи(power bank), которая, я думаю, есть у многих. Прибор для измерения пульсация света, нужен далеко не всегда, и я не вижу особых проблем, попользоваться им с помощью внешнего питания, если уж совсем нет других вариантов.
Ближе к делу
А тут всё просто, подключаем oled дисплей, по i2c к мк это D2(sda) D1(scl), по умолчанию или другие пины, если хотите. Temt6000 подключается к единственному, аналоговому входу(A0 к S). Не вижу смысла рисовать, что и как подключается, потому что соединить 3.3 с VDD и V, а G с GND и G, не составляет никаких проблем.
Библиотеку я использовал GyverOLED, она есть в репозитории arduino ide. Сам "измеритель пульсаций" требует библиотеку GyverFilters, которая так же, есть в репозитории.
Я убрал всю графику и на экран выводятся только kp1, kp2, Emax, Emin, Eenv, что лично мне, хватает. В оригинальном скетче были переменные, которые никак не использовались, я их все удалил.
Есть у меня, замечательная, китайская, rgb лампочка, которая управляется с пульта. Лампа полная хрень, пылится в коробке, но для теста хорошо подходит.
Для себя я собрал прибор, сочетающий в себе: датчик температуры(htu21d); датчик света(bh1750); измеритель пульсаций(temt6000).
Ниже скрины из видео теста лампы. В приложенном выше скетче, на дисплей выводится то же самое, только нет первых двух строк.
Зачастую в процессе разработки собственных устройств или моддинга уже существующих, встаёт задача выполнения стороннего кода: будь то ваши собственные программы с SD-флэшек, или программы, написанные другими пользователями с помощью SDK для вашего устройства. Тема компиляторов и кодогенерации достаточно сложная: чтобы просто загрузить ELF или EXE (PE) программу, вам нужно досконально разбираться в особенностях вашей архитектуры: что такое ABI, релокации, GOT, отличие -fPIE от -fPIC, как писать скрипты для ld и т. п. Недавно я копал SDK для первых версий Symbian и основываясь на решениях из этой ОС понял, каким образом можно сделать крайне «дешевую» загрузку любого нативного кода практически на любом микроконтроллере, совершенно не вникая в особенности кодогенерации под неё! Сегодня мы с вами: узнаем, что происходит в процессе загрузки программы ядром Linux, рассмотрим концепцию, предложенную Symbian Foundation и реализуем её на практике для относительно малоизвестной архитектуры — XTensa (хотя она используется в ESP32, детали её реализации «под капотом» для многих остаются загадкой). Интересно? Тогда добро пожаловать под кат!
❯ Как это работает?
Думаю, для многих моих читателей реализация процесса загрузки exe-программ и dll-библиотек в память процесса оставалась эдаким чёрным ящиком, в детали реализации которого вдаваться не нужно. Отчасти это так и есть: современные ОС разруливают процесс загрузки бинарников в память сами, не требуя от программиста вообще ничего, даже понимания того, куда будет загружена его библиотека или программа.
Давайте для общего понимания вкратце разберемся, как происходит загрузка программ в Windows/Linux:
1. Система создаёт процесс и загружает в память программы секции из ELF/PE. Обычные программы для своей работы используют 3 секции: .text (код), .data (не-инициализированный сегмент памяти для глобальных переменных), .bss (сегмент памяти для инициализированных переменных). Каждому процессу выделяется собственное адресное пространство, называемое виртуальной памятью, которое не позволяет программе испортить память ядра, а также позволяет не зависеть от разметки физической памяти на выполняющей машине. Концепцию виртуальной памяти реализует специальной модуль в процессоре, называемый MMU.
2. Если бы наши программы не использовали никаких зависимостей в виде динамических библиотек, то на этом процесс загрузки можно было бы закончить: каждая программа имеет свой адрес загрузки, относительно которого линкер строит связи между обращениями к коду/данным программы. Фактически, для самых простых программ линкеру остаётся лишь прибавить адрес загрузки программы (например, 0x100) к каждому абсолютному обращению к памяти. Однако современные программы используют десятки библиотек и для всех предусмотреть собственный адрес загрузки не получится: кто-то где-то всё равно будет пересекаться и вероятно, портить память. Кроме того, современные стандарты безопасности в Linux рекомендуют использовать позиционно-независимый код, дабы использовать преимущества ASLR (Address Space Layout Randomization, или простыми словами возможность загрузить программу в случайное место в памяти, дабы некоторые уязвимости, завязанные на фиксированном адресе загрузки программы перестали работать).
3. Поэтому для решения этой проблемы придуман т. н. динамический линкер, который уже на этапе загрузки программы или библиотеки патчит программу так, чтобы её можно было загрузить в любой участок памяти. Для этого используются данные, полученные от обычного линкера а этапе компиляции программы: помимо .text, .data и .bss, линкер создаёт секции .rel и .rel-plt, которые называются релокациями. Если объяснять совсем условно, то релокации — это просто запись вида «какой абсолютный адрес в коде программы нужно пропатчить» -> «на какое смещение его пропатчить». Самая простая релокация выглядит вот так:
Где по итогу:
.rel-plt же служит для резолвинга вызовов к dll/so: изначально программа ссылается на заранее определенные в процессе компиляции символы, которые уже в процессе загрузки патчатся на физические адреса функций из загруженной библиотеки.
И казалось бы — всё очень просто, пока в дело не вступают GOT (Global Offset Table — глобальная таблица смещений) и особенности реализации конкретного ABI. И ладно бы x86 или ARM, там всё разжевано и понятно, однако на других архитектурах начинаются проблемы и не всегда очевидно что и где за что отвечает.
А ведь чаще всего нужно просто загрузить небольшую программу, которой не нужны комплексные загрузчики: немного кода, немного данных и всё. И тут у нас есть три выхода:
Писать полноценный загрузчик ELF-бинарников. ELF может оказаться громоздким для некоторых окружений и его реализация может оказаться тривиальной не для всех.
Зарезервировать определенный сегмент в памяти (пусть с 0xFFF по 0xFFFF) и скомпилировать нашу программу с адресом загрузки 0xFFF с параметром -fno-pic. В таком случае, линкер сгенерирует обращения к памяти по абсолютным адресам — если переменная лежит по адресу 0xFFF, то программа будет обращаться сразу к этому адресу памяти, без необходимости что либо динамически линковать. Именно такой подход использовался во времена ZX Spectrum, Commodore 64 и MS-DOS (однако там роль «виртуальной памяти» выполняла такая особенность 8086, как сегменты). У такого подхода есть и минусы: относительная невозможность загрузки сразу нескольких программ одновременно, зарезервированное пространство линейно отъест небольшой кусок памяти у основной прошивки, нет возможности динамической аллокации секций. Зато такой код теоретически будет работать быстрее, чем PIC.
Проблемы реализации такого способа: иногда нужно лезть в систему сборки основной прошивки и патчить скрипт линкера так, чтобы он не трогал определенный регион памяти. В случае esp32, например, это требует патча в сам SDK и возможного «откола» от мейнлайн дистрибутива.
Использовать программу с относительной адресацией, однако без сегментов .bss и .data. Самый простой в реализации способ, который к тому же очень экономичен к памяти, позволяет загружать программу в любое место и пользоваться всеми фишками динамического аллокатора и не требует вмешательств в основную прошивку, кроме примитивного загрузчика программ. Именно его я и предлагаю рассмотреть подробнее.
Недавно мы сидели в чате ELF-сцены (разработка нативных программ под телефоны Siemens, Sony Ericsson, Motorola и LG с помощью хаков) и думали, как же можно реализовать загрузчик сторонних программ на практически неизвестных платформах. Кто-то предлагал взять ELF под основу — однако с его реализацией под некоторые платформы есть трудности, а кто-то предлагал писать «бинлоадер» — самопальный формат бинарников, который получается из, например, тех же эльфов.
В это же время я копал SDK для Symbian и хорошо помнил, что в прикладных приложениях для этой ОС нет поддержки глобальных переменных вообще. Да, сегмент .data и .bss полностью отсутствует — переменные предлагается хранить в структурах. Почему так сделано? Всё дело в том, что каждая программа в Symbian — это dll-библиотека, которую загружает EKA и создаёт экземпляр CApaApplication. И дабы была возможность загрузить dll один раз для всех программ (что справедливо для системных библиотек), ребята полностью выкинули возможность использования любых глобальных переменных. А ведь идея интересная!
Однако в таком подходе есть несколько серьезных ограничений:
Отсутствие глобальных переменных может стать проблемой при портированиии уже существующего софта, хотя вашим программам ничего не мешает передавать в каждую функцию структуру с глобальным стейтом, который можно при необходимости изменять. Кроме того, нет ограничений на использование C++ (за исключением необходимости ручной реализации new/delete и отсутствием исключений).
Отсутствие преинициализированных данных. Вот это уже может стать относительно серьёзной проблемой, у которой, тем не менее, есть свои обходные решения. Например если вы храните команды для инициализации дисплея в таблице, или какие-либо калибровочные данные — вы не сможете их объявить, просто используя инициализаторы в C. Тоже самое касается и строковых литерал. Тут есть два варианта: часть таблиц можно вынести на стек (если эти самые таблицы достаточно маленькие), либо подгружать необходимые данные из бинарника с помощью основной прошивки (например, LoadString и т. п.).
Давайте же на практике посмотрим, имеет ли право на жизнь такой подход!
❯ Практическая реализация
Формат нашего бинарника будет до безобразия прост: небольшой заголовок в начале файла и просто сырой дамп сегмента .text, который можно экспортировать из полученного elf даже без необходимости писать скрипт для линкера. При этом нужно учесть, что ESP32 — это микроконтроллер частично Гарвардской архитектуры, т. е. шина данных и кода у него расположены отдельно. Однако у чипа есть полноценный MMU, который позволяет маппить регионы физической памяти в виртуальную память, чем мы и воспользуемся в итоге!
Заголовок нашего бинарника будет выглядеть вот так:
Программа общается с основной прошивкой посредством псевдо-syscall'ов: функции, которая в качестве первого аргумента ожидает номер нужной службы и один 32х-битный указатель для описания структуры с параметрами. Реализация syscall'ов — одна из самых простых и неприхотливых с точки зрения обратной совместимости с будущими прошивками.
Концептуально всё очень просто: GetGlobalStateSize сообщает нашему загрузчику размер структуры для хранения глобального стейта, в то время как Start уже фактически заменяет main() в нашей программе. Необходимости в crt0 нет, поскольку весь необходимый инит выполняет бутлоадер ESP32. Впрочем, при желании вы можете выделить отдельный стек для вашей программы — это повысит надежность, если выполняемая программа удумает испортить стек.
-fno-pic отключает генерацию кода, зависимого от GOT, -nostdlib и -nostartfiles убирает из билда crt0 и stdlib, благодаря чему мы получаем только необходимый код. --section-start задает смещение для загрузки секции .text на 0x0 (в идеале это делать необходимо из скрипта для ld). objcopy скопирует из полученного ELF только необходимую нам секцию .text.
Как же это работает на практике? Давайте дизассемблируем выходной бинарник и посмотрим, что у нас дает на выхлопе cc:
Обратите внимание, что Start вызывает подфункции с помощью инструкции CALLX8, которая в отличии от обычного Immediate-версии CALL8, выполняет переход относительно текущего адреса в PC, благодаря чему переход полностью независим от адреса загрузки программы в памяти. А благодаря тому, что все данные, в том числе и указатель на глобальный стейт передаются через стек, нет необходимости релокейтить сегменты данных.
По итогу всё, что нужно от загрузчика бинарников — это загрузить программу в память для инструкций, выделить память для структуры с стейтом программы и передать управление Start. Всё! Конкретно в случае ESP32, у нас есть два возможных решения задачи загрузки программы в память:
Загрузить программу в IRAM. Такая возможность теоретически есть, однако на практике загрузчик ESP32 устанавливает права только на чтение и выполнение на данный регион памяти. Попытка что-то скопировать туда закончится исключением SIGSEGV. Кроме того, сегмент IRAM относительно небольшой — всего около 200Кб.
Самопрограммирование. Для этого, в esp32 есть два механизма — Partition API и SPI Flash API. Я выбрал Partition API для простоты реализации.
Для нашей прошивки необходимо будет переразметить флэш-память. Для этого запускаем idf.py menuconfig, идём в Partition Table -> Custom partition table CSV. Создаём в папке проекта partitions.csv, куда пишем:
Как видите, ничего сложного в выполнении сторонних программ при условии соблюдении некоторых ограничений нет. Да, в таком подходе есть как серьезные плюсы, так и минусы, однако он делает своё дело и позволяет реализовать запуск игр на кастомных игровых консолях, или сторонних программ на самодельных компьютерах. Ну и конечно же не стоит забывать про плагины! Авось в вашем решении нужна возможность расширения функционала устройства, однако предоставлять исходный код или даже объектные файлы нет возможности — тогда вам может пригодится и такая методика.
Пожалуй, стоит упомянуть ещё один… очень своеобразный метод, который я иногда встречаю при реализации самодельных компьютеров. Люди пишут… эмуляторы 6502/Z80 :) И если такой подход ещё +- применим к ESP32, то в AVR просадки производительности будут слишком серьезными. Так зачем, если можно использовать все возможности ядра на максимум?
Полезный материал?
Приходилось ли загружать сторонний код в ваших устройствах?
По сути, это должен быть не первый пост, потому что описываемый датчик полностью несамостоятельный и без базы от него нет пользы. Это не урок или статья "сделай сам", это просто описание моего датчика, вдруг, кого то вдохновит и/или поможет. База представляет собой микроконтроллер esp32, со всякими датчиками и радиоприёмником на частоте 433мГц. О ней, может быть, как-нибудь в следующий раз, или нет, хз.
Решил значит я замутить себе метеостанцию, дабы в любой момент, со смартфона видеть актуальную температуру, да и вообще, набирать статистику. Под рукой была nodemcu v3 на базе микроконтроллера esp8266.
nodemcu v3
Первая проблема, это питание. Я выбрал батарейки типа AA. На батарейках пишут 1.5В, но это не типа среднее напряжение или как там правильно, новая батарейка без проблем может выдавать 1.6 и чуть больше. 2 батарейки могут выдать 1.6*2=3.2, что допустимо для esp8266, но это пик, а я планирую высаживать батарейки по максимуму т.е. до 1В и ниже, а это уже 2В и ниже. Минимальное напряжение esp8266 2.5В(согласно датащиту https://www.espressif.com/sites/default/files/documentation/...). Плюс, я живу в Сибири и у нас бывают морозы, значит, напряжение надо бы повыше, с запасом.
3 батарейки AA это максимум 1.6*3=4.8, можно округлить до 5В. Для esp8266 5В это много, но в nodemcu v3 есть стабилизатор ams1117, который позволяет подавать до 15В, а на выходе у него те самые 3.3В. Но, не всё так гладко, т.к. у этого стабилизатора ток потребления 5 мА, а это значит, даже если вообще исключить потребитель, стабилизатор всё равно будет кушать 5мА. Согласно batterytest.ru, у батарейки GP Super ёмкость 2451, а это значит, её хватит всего на 2451/5=490,2ч или 20 дней при условие, что в цепи один лишь стабилизатор.
Я выпаял стабилизатор ams1117 и использовал MCP1700-3302E. У MCP1700-3302E ток потребления всего 1.6мкА, хотя, в комментариях, на али писали, что стабилизатор подделка и его потребление выше, но честно, я не замерял, решил довериться. Его максимальное, входное напряжение 6В, но это всё ещё выше 5В. Падение напряжения так же низкое, это я уже замерял, и даже при входе менее 3В, на выходе было лишь на несколько десятых ниже входа, а это значит, что 3 разряженные батарейки смогут выдать 1*3=3В, что будет хватать для питания esp8266.
Далее, была другая проблема, даже если не использовать wi-fi, при включение esp8266 инициализирует его, из за чего краткосрочно вырастает потребление, а экономить надо каждый мАч. Решение нашлось в примере LowPowerDemo, где в readme есть ссылка на https://github.com/esp8266/Arduino/issues/6642#issuecomment-... таким образом, можно отключить wi-fi с контроллер сразу будет загружаться в режиме модемного сна.
Если нет wi-fi, то как передавать данные? С помощью 433мГц и передатчика SYN115. Изначально, я просто подключил его на gpio 14. Но оказалось, что в глубоком сне esp8266 не сохраняет состояние пинов, т.е. даже если я даю команду LOW, 14 пин все равно станет HIGH, когда esp8266 уйдёт в deep sleep. Таким образом, SYN115 не только не перестаёт работать и засоряет эфир(моя китайская метеостанция, теряла связь со своим датчиком, в этот момент), но у нас так же повышенное потребление.
Есть вот такая интересная пикча, на ней видно, что gpio 15, единственный пин, который должен быть притянут к земле, чтобы esp8266 нормально запустилась. По логике, раз там должен быть низкий уровень для старта, значит и в глубоком сне, там будет сохраняться низкий уровень. Я точно не помню, с SYN115 или с другим передатчиком, но ESP8266 отказывалась запускаться, будто я подаю на 15 пин высокий уровень. Так, я решил использовать mosfet 2N7000, его управление на GPIO 15, SYN115 на GPIO 14, таким образом, неважно, какое состояние gpio 14, если gpio 15 LOW.
Датчик температуры и влажности, я решил использовать AHT20, хотя, обычно, в инструкциях про метеостанции, этот датчик не упоминается. Работает по i2c, потребление от 250-980мкА. Можно было, его тоже посадить на тот же mosfet, что и SYN115, но мне было лень.
Всё это запихал в корпус с ali, верхние отверстия заклеил, по боком насверлил отверстий. Чтобы избежать попадания влаги внутрь, сделал небольшие крылья, вырезанные из пластиковой бутылки. Испытания весной прошли успешно, какой бы дождь не лил, а ветер не дул, всё продолжало работать.
корпус
Самого фото датчика у меня нет, он на балконе, вскрывать и фотать влом, но я нарисовал схему.
От 2 батареек к аналоговому пину А0 провод подключён для контроля заряда батареи.
Теперь об реальном опыте, а он есть.
Несколько дней назад, у нас были морозы, показатель датчика немного завышали, относительно прогноза из интернета, примерно на +1градус. Хотя, смотря какому прогнозу верить, ведь если я смотрю в 4 источниках(яндекс,гисметео,пр5,yr.no), то вижу несколько отличающиеся цифры.
Вот такие данные получены моим датчиком.
усреднённые по времени суток данные
суточный график
Результаты меня порадовали, датчик не замёрз, батарейки выжили. Специально для зимы, покупал в dns батарейки Nanfu AA, т.к. согласно тестам https://batterytest.ru/1120 очень даже ничего.
У меня нет данных, сколько может проработать датчик от батареек, т.к. я впервые занимаюсь всем этим, и делал много ошибок, прежде чем прийти к описанному выше, батарейки высаживались достаточно активно. Первые батарейки проработали с 26.05 по 3.07 и напряжение 2 батареек было 1.98В, следовательно, каждая разрядилась, примерно до 1.98/2=0.99В. Потом были поставлены батарейки под брендом КОСМОС, но я их поменял на Nanfu AA т.к. боялся, что всю зиму те не проживут. КОСМОС проработали с 3.07 по 18.11 и 2 батарейки выдавали 2.44В т.е. батарейки ещё, вполне, были живы.
Вообще, метеостанция, это первое что я делал на esp, ранее, у меня не было опыта как с esp, так и с arduino, да вообще с микроконтроллерами, точно так же, как и не держал ранее паяльник в руках. Это я к тому, что если, вдруг, вдохновитесь, не бойтесь пробовать. У меня был только небольшой опыт в программирование, поэтому, я писал скетч сам, как хотелось, но библиотеки, конечно же, брал готовые. Но и без опыта программирования, в интернете куча готового кода, собирай, заливай и радуйся.
Питал по micru usb от 5В, загорелся суровый шестиногий светодиод, сигнализирующий о перегрузке (плохой контакт...) А так же вышел волшебный дымок на котором как известно и работает электроника
Я так понимаю это какой-то генератор импульсов, или что-то нужное для понижения напряжения (не особо шарю). Но думаю, если питать от 5В, то мне эта микруха то и не нужна (?) Выдрать её, минус на gnd, плюс на vin или прям на стабилизатор – и должно запуститься (?)
В общем крайне важно заставить эту штуку до завтрашнего вечера работать без дыма и красного каления, кинув какую-нибудь перемычку вместо микрухи, или выдрав её оттуда. Помогите опознать микросхему, дабы понятно было что это и что с ней делать
Основной используемый принцип -запросы и обработка ответов по смарт-протоколу APC За исключением того, что плату мониторинга/управления собираем на основе WemosD1mini.
Дешевизна решения очевидна, с учетом того, что самая дешевая сетевая плата AP9640 (без внешних датчиков) стоит более 500$
Плата собрана по традиции в коробочке из под Тик-Така.
Цель реализации:
мониторинг основных параметров UPS на WEB странице, а также в представлении XML и JSON
доступ к плате по WiFi. Сохранение параметров подключения
сигнализация аварии - отправка сообщения на PHP скрипт по ссылке
сбор информации о окружающей температуре и влажности
сохранение настроек в EEPROM FLASH
Детали
Wemos D1 mini
max3232 module без DB9 разъема
разъем DB9 папа
DHT-21 датчик температуры и влажности (опционально)
Схема простого подключения APC smart к RS232 COM порту ПК:
ups_alarm_script_url - ссылка на скрипт, для передачи алерта пропадания/появления питания, на email или телеграмм, в формате http://server/mail= или похожем.