Хммм. Уже минимум лет 5 пользую bme/bmp в том числе и на улице. Никаких проблем с отрицательными температурами не испытываю. Да, сами датчики дохнут за 1-3 года на улице (чем крупнее город, тем быстрее %) Сначала влажность, позже давление и температура).
Полез читать по ссылке. Похоже, там народ где-то некорректно использует знаковые переменные. В Бошевских примерах не зря приведение перед каждой переменной натыкано… У меня единый код под 8бит (AVR) и 32бит (ESP, STM32) с int32 вычислениями. Да, несколько адаптированный мной в погоне за местом в АВР, но в целом, соответствует даташитовским примерам и/или реализации Adafruit. И я не пользую для расчетов float, только для отдачи результата (если уже чем-то используется и не потянет за собой всю библиотеку)
За давностью лет могу не вспомнить, но как написали выше, там хитро.
Насколько вспоминается из описаний того времени, то, что до 20-25кВ, это не ионизация «по типу от грозы и хвойного леса», а как раз провокация производства озона. То ли коронным разрядом, то ли недостаточной энергией ионов для их отрыва. И, как следствие, озон и что-то там ещё про менее летучие ионы, от которых, кстати, голова и должна болеть. (воспринимать, есс-но, с поправкой на N-летнюю давность описания и аберрации памяти :) )
В вентиляцию их обычно и ставят в «промышленных» масштабах. Как для, собственно, ионизации, так и для чистки воздуха. Только дорого/затратно это для «домашнего» использования ибо КПД в канале сильно падает…
Лет уже под 20, наверно, назад взял себе биполярный ионизатор для комнаты — «Янтарь». Пользуюсь до сих пор (разве что поменял вентилятор на более тихий). Субъективно, лучше высыпаешься. Объективно — ощутимо меньше пыли __летает__ в воздухе (зато по поверхностям — вся...) и не «убиваются» поверхности за ионизатором, как в однополяных.
6. Погуглить ещё немного и понять, что ионизаторы типа люстры Чижевского, без смены полярности — ппц квартире (любимая тема в 90х, кто помнит, по аналогии с белым налётом от пьезо-увлажнителей) в плане неотмываемых чёрных пятен — пофиг!
7. То, что для эффективной генерации ионов надо 25кВ написано даже в википедии — не, диодов многовато получицца!
Так о том и речь, что не бегает она по всей строке — при первом вхождении нуля вываливается. Что в BSD, что в glibc — stackoverflow.com/a/1733294/2320413
А… кажись дошло — если строка не пустая, то получаем лишний цикл вычисления длины… :)
Собс-но, фраза «Если на вход подается большая строка, то каждый её символ всё равно будет сравнён со строковым нулём.» ввела в заблуждение
Зачем функции, возвращающей число символов _до_ завершающего нуля «пробегать все символы строки»? Увидит первый «0» и остановится. Тут максимум «оптимизация» вызова функции вместо сравнения ИМХО…
+1
Ничего. Плохого :)
Я как раз о том, что даже «типа-низкий-железный-уровень» и то даёт вдвое оверхеда…
Попробовал собрать gcc 4.5 (лень было пути прописывать к 7): text data bss dec hex filename
804 336 916 2056 808 mk/blink.elf
Вот. А с учётом порядка 280 байт «полезного» кода для кнопок и кода SOS, так и втрое!
1. про атрибут советуют и где-то на ST-шном форуме, но это как-то грустно — там с пару десятков ошибок вываливается при линковке — все их править? И это не мой код, а потроха HAL-а…
(привет, EddyEm :) ) понять, а) как это указать в Кубе (никак — ибо нет опции для _PWM1) б) сообразить, как сделать то же самое, средствами LL или HAL, причём так, чтобы было легко поправить под F0 и F1 (ну и перенести на другой таймер до кучи, чтоб на F030 завелось). Пока всё в образовательных целях ))
3. При сборке штатным Makefile с правками на DEBUG=0 и оптимизацией -Os оно, вроде, и так отключается (там везде (?) assert_param, что раскрывается в пустое место в Release)
ЗЫ: глянул пример «nolib» blink через SysTick — на «чистых регистрах» — там тоже 1144 байта бинарник — по сравнению моим тайменром на LL — примерно вдвое разница на только инициализацию фактически
Не, прозрение не катит :) там по-умолчанию эти опции включены (ну, для gcc — точно), а вот с lto всё гораздо грустнее — что HAL, что LL не собираются в таком режиме, потому как линкер выкидывает все обработчики прерываний и ещё кучу всего из потрохов HAL-a
Ща, в процессе изучения stm32, пытаюсь перевести известный код 1wire на таймере с DMA из обращения к регистрам в (хотя бы) LL — третий день ищу, чем же оно пишет в TIM_CCMR2 :( То, что делается в 1 строку присвоения регистру, тут выливается в 10-30 байт структуру, плюс вызов нескольких функций :( А опции запуска таймера в режиме PWM в Cube32MX вообще не оказалось (в stm32fxx_ll_lim.h он есть)
Вот тут уже начинаешь подумывать, а не фиг ли с ней, переносимостью (тем более на другую линейку всё равно править — сравнивал stm32f103 и stm32f030)?.. Думаю, всё хорошо в меру…
arm-none-eabi-size build/hal_tim3_blink.elf
text data bss dec hex filename
4492 20 1636 6148 1804 build/hal_tim3_blink.elf
arm-none-eabi-size build/ll_tim3_blink.elf
text data bss dec hex filename
1900 12 1564 3476 d94 build/ll_tim3_blink.elf
бинарники, соответственно, 4512 и 1920 байт. Из кода — только дёрганье пином в обработчике прерывания…
Почему не докрутить — даже, кажется, штатно в армбиане есть — overlayroot называется.
Хуже, если надо синхронизировать изменения обратно — у меня, когда экспериментировал с pine64, не вышло перемонтировать r/o раздел в r/w из скрипта (только из консоли). Ну и штатного механизма синхронизации, кажется, так и нет.
По работе идёт Шнайдеровская EcoStruxure — кто работал с TAC Vista — похоже. Visio-подобный редактор, бо́льшая часть — векторная с «примочками» на javascript. В 3й версии они переделали веб-морду и добавили в неё дашборды для вывода на планшеты.
Весьма шустро и гибко (если ты программист и хоть немного в javascript), но привязано к их железу или серверному софту.
… ну и цены :(((
ЗЫ: для домашних поделок — пока OpenHAB+HABPanel+NodeRed, но хочется чего-то более СКАДА-подобного
У меня с разных датчиков (MySensors, MQTT/ESP8266, i2c, 1wire, ping и т.п.) всё собирается в NodeRed на OrangePi. Вполне себе.
А если немного повозиться, то и вместо «портянки» с js функциями, можно делать свои блоки для большего удобства и компактности :)
Для минимального GUI достаточно «встроенного» dashboard или вовсе самописные web-странички, что-то более серьёзное — тот же MajorDoMo, OpenHab, Homie и прочие
Только у него максимальный ток 4.5А (!) по паспорту
Сам пока делал распределённую систему с одним насосом от компьютерной «водянки» и кучи капельниц, воткнутых в общую трубу. Так себе регулировка вышла — трубка капельницы «засыхает/залипает» под зажимом и через какое-то время перестает течь.
Пока смотрю на недорогие перистальтические насосы с Али, валяется пара, в деле пока не пробовал — неудобно, заполнение водой критично (по крайней мере для китайского исполнения), а мне из «бочки» качать… да ещё и они не уличные, на балконе не бросишь под дождём
При наличии достаточно «прямых» рук и мелкого паяльника магически получаем +2 GPIO (4, 5) без особых усилий, помимо стандартных RX, TX, GPIO 14, GPIO0 (кнопка), GPIO13 (светодиод). Паяются тонким проводом прямо к ноге микросхемы и выводятся на пустые контакты от RF приёмника.
Во всяких готовых конструкторах (ESPEasy, Tasmota и т.п.) как раз эта дополнительная пара и используется :)
Отдельный "+" за «Вампирчик»-а — в своё время, в походах от пары недель до месяца, был практически панацеей с гибкими солнечными панелями «от того же источника» :)
Но, таки да — в этом посте только «вода», а хотелось бы «мяса» и стоимости — звучит весьма вкусно как для домашних поделок, так и для выездов-походов, в коих Вампирчик был весьма полезен.
Угу. Как-то так и думал делать. Ибо готовое с Арм(Расп)-биана синхронизироваться даже с костылями не желало…
На тот момент останавливало не вполне очевидное поведение этого overlayroot — там много чего принудительно «режется» помимо просто подъёма оверлея. Ну и не хотелось писать логику синхронизации рукам — что удалять, что копировать.
Ща, буду запускать очередную поделку на Зеро — будет повод вернуться к вопросу
Эту утилиту я знаю и «ручным» запуском её overlayroot как раз и пользуюсь (вручную там точно можно отменить оверлей для внешних дисков, через менюшки было нельзя на момент моих эксперментов)
Вопрос был про фразу «overlayfs с дропом на диск при выключении» — мне помечталось, что есть готовое решение обратной синхронизации оверлея на флешку. Год-два назад готового рабочего варианта не было. Даже записал себе в «дальние проекты» сделать скрипт хоть частичной синхронизации, но всё как-то не до него
В своё время (тоже) настраивал «встроенный» overlayfs на Pi/Pine64. И так и не нашёл такого решения. Пока устраивает внешний HDD с разрешением на запись — всё равно туда видео и openHAB постоянно пишут.
Ну… у вышеупомянутой LD3985 так вообще — 6… Как раз LK112 в этом отношении гораздо интереснее. Но — 150мА.
С другой стороны, 1117 хоть до 15В, но при большой разнице вход/выход быстро превращается в кипятильник :(
ЗЫ: давно «мечтаю» перейти на импульсники, но как-то пока не нашёл удобного чипа и обхожусь готовыми китайскими блоками, припаянными на плату. Ибо купить рассыпуху выходит раза в 2-3 дороже
Я в своих поделках с малым потреблением перешёл на XC6206 (любимая китайская «662k» во всех их поделках): и ток 250мА — обычно хватает на ESP8266, и утечка по факту около 0.7мкА — датчик на ATMega328 + NRF24L01 живёт по полгода без зарядки дохлого китайского LiPo.
Полез читать по ссылке. Похоже, там народ где-то некорректно использует знаковые переменные. В Бошевских примерах не зря приведение перед каждой переменной натыкано… У меня единый код под 8бит (AVR) и 32бит (ESP, STM32) с int32 вычислениями. Да, несколько адаптированный мной в погоне за местом в АВР, но в целом, соответствует даташитовским примерам и/или реализации Adafruit. И я не пользую для расчетов float, только для отдачи результата (если уже чем-то используется и не потянет за собой всю библиотеку)
Насколько вспоминается из описаний того времени, то, что до 20-25кВ, это не ионизация «по типу от грозы и хвойного леса», а как раз провокация производства озона. То ли коронным разрядом, то ли недостаточной энергией ионов для их отрыва. И, как следствие, озон и что-то там ещё про менее летучие ионы, от которых, кстати, голова и должна болеть. (воспринимать, есс-но, с поправкой на N-летнюю давность описания и аберрации памяти :) )
Лет уже под 20, наверно, назад взял себе биполярный ионизатор для комнаты — «Янтарь». Пользуюсь до сих пор (разве что поменял вентилятор на более тихий). Субъективно, лучше высыпаешься. Объективно — ощутимо меньше пыли __летает__ в воздухе (зато по поверхностям — вся...) и не «убиваются» поверхности за ионизатором, как в однополяных.
7. То, что для эффективной генерации ионов надо 25кВ написано даже в википедии — не, диодов многовато получицца!
%))
А… кажись дошло — если строка не пустая, то получаем лишний цикл вычисления длины… :)
Собс-но, фраза «Если на вход подается большая строка, то каждый её символ всё равно будет сравнён со строковым нулём.» ввела в заблуждение
Зачем функции, возвращающей число символов _до_ завершающего нуля «пробегать все символы строки»? Увидит первый «0» и остановится. Тут максимум «оптимизация» вызова функции вместо сравнения ИМХО…
Ничего. Плохого :)
Я как раз о том, что даже «типа-низкий-железный-уровень» и то даёт вдвое оверхеда…
Попробовал собрать gcc 4.5 (лень было пути прописывать к 7):
text data bss dec hex filename
804 336 916 2056 808 mk/blink.elf
Вот. А с учётом порядка 280 байт «полезного» кода для кнопок и кода SOS, так и втрое!
2. У меня обратная «задача» — по простому коду (привет, EddyEm :) ) понять, а) как это указать в Кубе (никак — ибо нет опции для _PWM1) б) сообразить, как сделать то же самое, средствами LL или HAL, причём так, чтобы было легко поправить под F0 и F1 (ну и перенести на другой таймер до кучи, чтоб на F030 завелось). Пока всё в образовательных целях ))
3. При сборке штатным Makefile с правками на DEBUG=0 и оптимизацией -Os оно, вроде, и так отключается (там везде (?) assert_param, что раскрывается в пустое место в Release)
ЗЫ: глянул пример «nolib» blink через SysTick — на «чистых регистрах» — там тоже 1144 байта бинарник — по сравнению моим тайменром на LL — примерно вдвое разница на только инициализацию фактически
Ща, в процессе изучения stm32, пытаюсь перевести известный код 1wire на таймере с DMA из обращения к регистрам в (хотя бы) LL — третий день ищу, чем же оно пишет в TIM_CCMR2 :( То, что делается в 1 строку присвоения регистру, тут выливается в 10-30 байт структуру, плюс вызов нескольких функций :( А опции запуска таймера в режиме PWM в Cube32MX вообще не оказалось (в stm32fxx_ll_lim.h он есть)
Вот тут уже начинаешь подумывать, а не фиг ли с ней, переносимостью (тем более на другую линейку всё равно править — сравнивал stm32f103 и stm32f030)?.. Думаю, всё хорошо в меру…
arm-none-eabi-size build/hal_tim3_blink.elf
text data bss dec hex filename
4492 20 1636 6148 1804 build/hal_tim3_blink.elf
arm-none-eabi-size build/ll_tim3_blink.elf
text data bss dec hex filename
1900 12 1564 3476 d94 build/ll_tim3_blink.elf
бинарники, соответственно, 4512 и 1920 байт. Из кода — только дёрганье пином в обработчике прерывания…
Хуже, если надо синхронизировать изменения обратно — у меня, когда экспериментировал с pine64, не вышло перемонтировать r/o раздел в r/w из скрипта (только из консоли). Ну и штатного механизма синхронизации, кажется, так и нет.
Весьма шустро и гибко (если ты программист и хоть немного в javascript), но привязано к их железу или серверному софту.
… ну и цены :(((
ЗЫ: для домашних поделок — пока OpenHAB+HABPanel+NodeRed, но хочется чего-то более СКАДА-подобного
А если немного повозиться, то и вместо «портянки» с js функциями, можно делать свои блоки для большего удобства и компактности :)
Для минимального GUI достаточно «встроенного» dashboard или вовсе самописные web-странички, что-то более серьёзное — тот же MajorDoMo, OpenHab, Homie и прочие
Сам пока делал распределённую систему с одним насосом от компьютерной «водянки» и кучи капельниц, воткнутых в общую трубу. Так себе регулировка вышла — трубка капельницы «засыхает/залипает» под зажимом и через какое-то время перестает течь.
Пока смотрю на недорогие перистальтические насосы с Али, валяется пара, в деле пока не пробовал — неудобно, заполнение водой критично (по крайней мере для китайского исполнения), а мне из «бочки» качать… да ещё и они не уличные, на балконе не бросишь под дождём
Во всяких готовых конструкторах (ESPEasy, Tasmota и т.п.) как раз эта дополнительная пара и используется :)
Но, таки да — в этом посте только «вода», а хотелось бы «мяса» и стоимости — звучит весьма вкусно как для домашних поделок, так и для выездов-походов, в коих Вампирчик был весьма полезен.
На тот момент останавливало не вполне очевидное поведение этого overlayroot — там много чего принудительно «режется» помимо просто подъёма оверлея. Ну и не хотелось писать логику синхронизации рукам — что удалять, что копировать.
Ща, буду запускать очередную поделку на Зеро — будет повод вернуться к вопросу
Эту утилиту я знаю и «ручным» запуском её overlayroot как раз и пользуюсь (вручную там точно можно отменить оверлей для внешних дисков, через менюшки было нельзя на момент моих эксперментов)
Вопрос был про фразу «overlayfs с дропом на диск при выключении» — мне помечталось, что есть готовое решение обратной синхронизации оверлея на флешку. Год-два назад готового рабочего варианта не было. Даже записал себе в «дальние проекты» сделать скрипт хоть частичной синхронизации, но всё как-то не до него
В своё время (тоже) настраивал «встроенный» overlayfs на Pi/Pine64. И так и не нашёл такого решения. Пока устраивает внешний HDD с разрешением на запись — всё равно туда видео и openHAB постоянно пишут.
С другой стороны, 1117 хоть до 15В, но при большой разнице вход/выход быстро превращается в кипятильник :(
ЗЫ: давно «мечтаю» перейти на импульсники, но как-то пока не нашёл удобного чипа и обхожусь готовыми китайскими блоками, припаянными на плату. Ибо купить рассыпуху выходит раза в 2-3 дороже