Абсолютно ничего сложного в том, чтобы начать работать с современными контроллерами в современной среде разработки, нет. Более того, при этом вы получаете массу вкусных, полезных, и главное — грамотно реализованных вещей, радикально ускоряющих и упрощающих разработку. Нет, я не про библиотеки «мигания светодиодом», хотя и их тоже достаточно — я про таймеры, многозадачность, сообщения, сервисы и всё остальное, что не имеет никакого смысла в 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). Мне кажется либо есть вариант сделать проще, либо вы все усложняете.
Как техническая реализация это все отлично. Хороший подход, а главное реализовали то, что хотели. Но с практической точки зрения, это лишнее и не даст вам никакой информации о здоровье улья. Хотя бы тот факт, что у слабой семьи начинают воровать мед пчелы из соседних сильных семей, вы своим подсчётом никак не увидите. Количество пчел летающих туда и обратно увеличится, а вы будете считать, что улей хорошо работает. И подобных нюансов много. Я в свое время сам пытался автоматизировать подобный процесс, в итоге остановился на том, что нет лучше показателя, чем ежедневный привес улья. Несколько ульев у меня стоят на весах, и по ним я ориентируюсь, как работают пчелы.
Вы пишите, что современные зарядники могут зарядить в хлам разряженные аккумуляторы. У меня Opus BT-3100 (v 2.2), если я в него вставляю в хлам разряженный аккумулятор, он показывает на экране null. Поэтому мне приходится первоначально толкнуть аккумулятор от обычного блока питания, а затем уже заряжаю его Opus'ом
У меня есть несколько знакомых, которые свои старые айфоны отдают детям. Вышла новая версия, он себе купил новый, предыдущий отошел жене, та свой отдала старшему ребенку и.т.д. С андроидами я такого не замечал, так как большинство предпочитает купить дешевый андроид и отдать его ребенку, нежели отдавать свой старый. На мой взгляд это еще одна из причин, почему вырастает срок использования.
В большинстве систем, работающих по реферальной схеме. После регистрации по реферальной ссылке, в личном кабинете можно увидеть логин человека, пригласившего вас. Зачастую, люди раскидывающие такие ссылки, активные пользователи подобных сервисов и есть смысл подбирать пароль к их кабинету, зная уже логин. Бывает так, что сама реферальная ссылка содержит в себе логин ее хозяина, который передается get запросом. Это я к тому, что найти логины активных пользователей в подобных сервисах, не такая уж и большая проблема)
На мой взгляд куда большие проблемы могут возникнуть выложив информацию об открытой уязвимости здесь, с полным мануалом о том, как ее использовать. Нежели если бы вы сначала уведомили об этом разработчиков и дождались закрытия уязвимости. Во всяком случае, если вы боитесь гонений, уведомить разработчиков можно и анонимно.
Начинал с Лутца, соглашусь с тем, что написано очень доступно. В последствии постоянно на столе держу «Дэвид М. Бизли — Python. Подробный справочник», в качестве справочника.
Когда только начинал использовать STM32, считал что CubeMX это нечто, которое до невозможности облегчает работу. Теперь часть моих проектов содержит вставки на CMSIS. А все потому, что создатели CubeMX не спешат исправлять косяки, на которые им указывают. По факту я так же использую куб, это очень удобно в плане генерации проекта, но когда всплывает какой либо косяк, на его поиск и исправление уходит много времени. И обычно решается написанием вставок на CMSIS.
Столкнулся с miui.su недели 3 назад(перешел на MIUI 8). В некоторых разделах меню несколько раз набрел на китайские иероглифы. Плюс проблемы с смс от Сбербанка. Пришлось отказаться и перейти на другую прошивку.
Вчера только читал второй выпуск «Зарубежная электронная техника» от 26.01.2017. Там есть небольшая статья про технологию MRAM памяти, которой тоже пророчат светлое будущее, возможно Вам и это будет интересно почитать.
Так скажем промышленное оборудование, для постоянной регистрации данных с большого количества датчиков. Когда возможностей семейства Atmega перестало хватать, перешел на семейство Xmega.
Вот здесь я сильно не согласен с Вами. Вы показываете одну строчку вызова функции, рассказываете о том как это упрощает порог вхождения в программирование электроники. По факту, если взять тот же HAL для STM32 и раскрыть любую его функцию то можно охренеть от всей той кучи всевозможных проверок которые там расписаны. Все это замедляет работу МК, увеличивает вес прошивки. В своих проектах, где использую HAL, я в большинстве случаев я вырезаю все эти не нужные участки, для оптимизации кода.
HAL как бы он мне не нравился, имеет большое количество всевозможных костылей на которые ты постоянно натыкаешься. Причем разработчики их не торопятся исправлять. Некоторые ошибки расписаны на их форуме еще года 3 назад, но все еще имеют место быть. И чтоб их обойти приходится лезть и изучать что делает функция.
Всевозможные тонкие настройки периферии. Например если в процессе работы, вам нужно изменить период работы таймера, приоритеты прерываний, скорость работы UART и.т.д. Все это требует полноценного чтения документации.
В случае использования готовых модулей(конструкторов) это возможно еще все прокатит, но при попытке сделать шаг в сторону обязательно споткнешься и начнешь изучать все более углубленно.
Плюс определенная ошибка(code 10, если не ошибаюсь), которая все еще есть в кубе. И для ее избавления необходимо править определенные функции, которые при новой генерации проекта генерируются по новой с той же проблемой.
На мой взгляд, для полноценного проекта и правда стоило бы использовать аппаратный USB, а для схемы «на коленке» сойдет и UART.
А для отладочных сообщений мне кажется удобнее использовать SWO.