На мой взгляд это весьма логичный шаг со стороны администрации, вызывать модератора по призыву @uspeli. Это как автоматическая реакция ботов на матершинные слова в чате. Пользователи Pikabu так скажем сами ставили маркер, на непотребный контент, чем облегчали работу модераторам. Я даже удивлён, что они так поздно реализовали это.
Лет 5 назад наверно часто пользовался приложением «Раскрыватель» в том же ВК. Выполняет несколько шагов, один из которых как я понял тот, что вы описали. Во всяком случае полученный результат меня всегда радовал.
Есть NAND c SPI(x1, x2, x4 интерфейсом), с которых можно считывать одновременно по 4 линиям SI. Скорость конечно не как у параллельной NAND, но близка к этому. Из плюсов меньший размер и меньшее количество задействованных ног.
Я 15 лет назад(на заре появления телефонов) тоже самое про пчел слышал от старшего поколения. Скоро все пчелы вымрут, хрен знает кто будет все растения опылять. Как и про нефть, когда поступал учиться. Мол скоро кончится, не нужно идти в нефтянку. По факту и пчелы и нефтяники пока еще живут и приносят хороший доход своим семьям.
На сколько мне известно, пчелы летают за мёдом на расстояние не больше 3 километров. Большее расстояние преодолевают разведчики, когда ищут новое место жилья для роя. И тогда стирание их памяти даже играло бы нам на руку, если бы разведка не возвращалась, а улей не роился. Но пчелы либо подстраиваются под это, или ищут места ближе 5 км для новой колонии. Хотя природой у них заложено улететь как можно дальше от родового улья.
И опять же, если верить литературе, то чем дальше летит пчела, тем меньшее количество мёда она приносит.
В свое время боялись высоковольтной линии, которая резала путь от нашей пасеки до медоносных угодий. Поэтому первое время вывозили пчел в поля. Со временем, мы поняли, что пчелам совершенно пофиг на эти столбы с проводами. т.к. под столбами сады, там цветут весной яблони, вишни и пчелы их прекрасно опыляют(сами специально ходили смотрели). Не говоря уже о том, что они каждый день пролетают под проводами в одну сторону и возвращаются уже с мёдом под ними обратно.
Что касается сотовой связи. Я опять же задавался этим вопросом, когда собирал автоматику для своих пчел, которая передаёт данные по GSM каналу. И я неоднократно сталкивался с тем, что улей начинает гудеть, если на телефон рядом с ним приходит вызов.
Но на самом крупном русскоязычном форуме пчеловодов есть обширная тема, связана с сотовой связью и её влиянием на пчел. И если с ней ознакомиться, то тоже есть ряд людей у которых рядом с пасекой стоят сотовые вышки и пчелы прекрасно себя чувствуют рядом с ними уже несколько лет. В связи с чем могу сделать вывод, что ознакомившись с подобными статьями в самом начале я действительно боялся пагубного действия на пчел, но на практике все оказалось не так страшно.
В качестве геотаргетинга на мой взгляд можно было бы попробовать выбрать всякого рода студенческие общаги либо сами учебные заведения. Студенты всегда нуждаются в деньгах, плюс возрастная категория совпадает.
Нужно провести как минимум какие нибудь исследования в плане того, как пчелы будут себя вести рядом с wifi, и всякого рода другими радиоканалами.
Например мои пчелы к телефону в кармане относятся более менее нормально. Но как только на телефон начинает приходить вызов, то улей сразу начинает гудеть. Я думаю есть какие то определенные частоты, находясь рядом с излучателем которых, пчелы будут себя чувствовать более менее комфортно, а с некоторыми в корне наоборот.
И я думаю будет мало хорошего, если подобный раздражающий фактор будет постоянно присутствовать в улье. Семья скорее всего тупо покинет его.
Я могу сказать, что они очень лёгкие. У знакомого такую пасеку в прямом смысле, сдуло ветром. Поэтому необходимо придумывать какое нибудь крепление или утяжелитель.
В последнем абзаце видимо случайно вырезалось: У себя в помещении установил нагреватель с ПИД контроллером для регулировки температуры. Плюс собрал устройство на базе STM32+GSM модем. По звонку присылает мне температуру и влажность.
Я как то уже писал в комментариях на хабре про это, но повторюсь.
Лето:
Контролировать температуру каждого улья на мой взгляд бессмысленно, пчелы сами с этим прекрасно справляются. Откровенно слабые ульи выявляются при периодическом осмотре.
Самое информативное это вес улья, но это очень затратно, т.к. датчики веса очень дорогие. Но это позволило бы видеть растёт ли вес улья каждый день, или не изменяется или того хуже уменьшается. У сильного улья, ежедневный привес бывает достигает 1кг.
Контролировать шум или количество пчел у улья не информативно, т.к. у слабого улья начинают воровать сильные семьи, а визуально выглядит что улей работает ударными темпами.
Летом моя автоматизация сводится к видеонаблюдение, чтоб видеть какой улей роился в моё отсутствие и пара контрольных ульев стоит на старых напольных весах(те кто по старше я думаю помнят, как они раньше стояли в магазинах и на складах).
Зима:
На улице пчел давно никто у нас не оставляет, пчел заносят в специальное). Плюс заложил аварийное оповещение по СМС, на случай отключения электричества или выхода температуры за заданные на ПИД регуляторе пределы.
C RTOS я особо не работал, разве что читал цикл статей по FreeRTOS в одном журнале. Но мне кажется, что и там скорее всего найдется то, что потребует более углубленного изучения.
К тому же изучение Reference Manual на тот же FreeRTOS(с которым я более менее знаком) займет не на много меньше времени, чем изучение документации на HAL.
Но это опять же, сугубо мое мнение.
Для примера Tiny с которой недавно сталкивался: Attiny1616
На мой взгляд это МК, не для замены мелкой логики=)
Хотя не спорю, у всех задачи в плане разработки стоят разные. И понятие мелкая логика у каждого в плане масштабности несет разный характер в зависимости от уровня знаний и размеров схем, в которыми он работает.
Абсолютно ничего сложного в том, чтобы начать работать с современными контроллерами в современной среде разработки, нет. Более того, при этом вы получаете массу вкусных, полезных, и главное — грамотно реализованных вещей, радикально ускоряющих и упрощающих разработку. Нет, я не про библиотеки «мигания светодиодом», хотя и их тоже достаточно — я про таймеры, многозадачность, сообщения, сервисы и всё остальное, что не имеет никакого смысла в 2018 году нашей эры писать руками, потому что всё это уже написано до вас и, скорее всего, сильно лучше, чем когда-либо напишете вы.
Вот здесь я сильно не согласен с Вами. Вы показываете одну строчку вызова функции, рассказываете о том как это упрощает порог вхождения в программирование электроники. По факту, если взять тот же HAL для STM32 и раскрыть любую его функцию то можно охренеть от всей той кучи всевозможных проверок которые там расписаны. Все это замедляет работу МК, увеличивает вес прошивки. В своих проектах, где использую HAL, я в большинстве случаев я вырезаю все эти не нужные участки, для оптимизации кода.
HAL как бы он мне не нравился, имеет большое количество всевозможных костылей на которые ты постоянно натыкаешься. Причем разработчики их не торопятся исправлять. Некоторые ошибки расписаны на их форуме еще года 3 назад, но все еще имеют место быть. И чтоб их обойти приходится лезть и изучать что делает функция.
Всевозможные тонкие настройки периферии. Например если в процессе работы, вам нужно изменить период работы таймера, приоритеты прерываний, скорость работы UART и.т.д. Все это требует полноценного чтения документации.
В случае использования готовых модулей(конструкторов) это возможно еще все прокатит, но при попытке сделать шаг в сторону обязательно споткнешься и начнешь изучать все более углубленно.
Что касается абзаца про смерть AVR и исторического использования этих МК. На мой взгляд это можно сказать про Mega, Xmega и их ARM МК. Xmega и ARM от Atmel не смогли завоевать популярность народа(в России точно). Семейство Mega не обновляется и эти контроллеры все еще используются электронщиками со стажем, которые к ним привыкли. Но у Atmel есть семейство 8 битных Tiny. Которое постоянно обновляется, пользуется спросом и имеет куда более богатую аналоговую периферию и больше таймеров чем тот же STM32F030(который привели для сравнения).
Добавление USB в программу, сулит большие объемы исходного кода, которые будут мозолить глаза и отвлекать.
Плюс определенная ошибка(code 10, если не ошибаюсь), которая все еще есть в кубе. И для ее избавления необходимо править определенные функции, которые при новой генерации проекта генерируются по новой с той же проблемой.
На мой взгляд, для полноценного проекта и правда стоило бы использовать аппаратный USB, а для схемы «на коленке» сойдет и UART.
А для отладочных сообщений мне кажется удобнее использовать SWO.
У самого подобной задачи на STM32 ещё не было, но неужели там все на столько сложно!? У той же Xmega есть модуль Awex, который запускаешь и настраиваешь значение мертвого времени и частоту(для данного случая мертвое время было бы равно 0). Мне кажется либо есть вариант сделать проще, либо вы все усложняете.
И опять же, если верить литературе, то чем дальше летит пчела, тем меньшее количество мёда она приносит.
Что касается сотовой связи. Я опять же задавался этим вопросом, когда собирал автоматику для своих пчел, которая передаёт данные по GSM каналу. И я неоднократно сталкивался с тем, что улей начинает гудеть, если на телефон рядом с ним приходит вызов.
Но на самом крупном русскоязычном форуме пчеловодов есть обширная тема, связана с сотовой связью и её влиянием на пчел. И если с ней ознакомиться, то тоже есть ряд людей у которых рядом с пасекой стоят сотовые вышки и пчелы прекрасно себя чувствуют рядом с ними уже несколько лет. В связи с чем могу сделать вывод, что ознакомившись с подобными статьями в самом начале я действительно боялся пагубного действия на пчел, но на практике все оказалось не так страшно.
Например мои пчелы к телефону в кармане относятся более менее нормально. Но как только на телефон начинает приходить вызов, то улей сразу начинает гудеть. Я думаю есть какие то определенные частоты, находясь рядом с излучателем которых, пчелы будут себя чувствовать более менее комфортно, а с некоторыми в корне наоборот.
И я думаю будет мало хорошего, если подобный раздражающий фактор будет постоянно присутствовать в улье. Семья скорее всего тупо покинет его.
Лето:
Контролировать температуру каждого улья на мой взгляд бессмысленно, пчелы сами с этим прекрасно справляются. Откровенно слабые ульи выявляются при периодическом осмотре.
Самое информативное это вес улья, но это очень затратно, т.к. датчики веса очень дорогие. Но это позволило бы видеть растёт ли вес улья каждый день, или не изменяется или того хуже уменьшается. У сильного улья, ежедневный привес бывает достигает 1кг.
Контролировать шум или количество пчел у улья не информативно, т.к. у слабого улья начинают воровать сильные семьи, а визуально выглядит что улей работает ударными темпами.
Летом моя автоматизация сводится к видеонаблюдение, чтоб видеть какой улей роился в моё отсутствие и пара контрольных ульев стоит на старых напольных весах(те кто по старше я думаю помнят, как они раньше стояли в магазинах и на складах).
Зима:
На улице пчел давно никто у нас не оставляет, пчел заносят в специальное). Плюс заложил аварийное оповещение по СМС, на случай отключения электричества или выхода температуры за заданные на ПИД регуляторе пределы.
К тому же изучение Reference Manual на тот же FreeRTOS(с которым я более менее знаком) займет не на много меньше времени, чем изучение документации на HAL.
Но это опять же, сугубо мое мнение.
На мой взгляд это МК, не для замены мелкой логики=)
Хотя не спорю, у всех задачи в плане разработки стоят разные. И понятие мелкая логика у каждого в плане масштабности несет разный характер в зависимости от уровня знаний и размеров схем, в которыми он работает.
Вот здесь я сильно не согласен с Вами. Вы показываете одну строчку вызова функции, рассказываете о том как это упрощает порог вхождения в программирование электроники. По факту, если взять тот же HAL для STM32 и раскрыть любую его функцию то можно охренеть от всей той кучи всевозможных проверок которые там расписаны. Все это замедляет работу МК, увеличивает вес прошивки. В своих проектах, где использую HAL, я в большинстве случаев я вырезаю все эти не нужные участки, для оптимизации кода.
HAL как бы он мне не нравился, имеет большое количество всевозможных костылей на которые ты постоянно натыкаешься. Причем разработчики их не торопятся исправлять. Некоторые ошибки расписаны на их форуме еще года 3 назад, но все еще имеют место быть. И чтоб их обойти приходится лезть и изучать что делает функция.
Всевозможные тонкие настройки периферии. Например если в процессе работы, вам нужно изменить период работы таймера, приоритеты прерываний, скорость работы UART и.т.д. Все это требует полноценного чтения документации.
В случае использования готовых модулей(конструкторов) это возможно еще все прокатит, но при попытке сделать шаг в сторону обязательно споткнешься и начнешь изучать все более углубленно.
Плюс определенная ошибка(code 10, если не ошибаюсь), которая все еще есть в кубе. И для ее избавления необходимо править определенные функции, которые при новой генерации проекта генерируются по новой с той же проблемой.
На мой взгляд, для полноценного проекта и правда стоило бы использовать аппаратный USB, а для схемы «на коленке» сойдет и UART.
А для отладочных сообщений мне кажется удобнее использовать SWO.