Ну нельзя же сразу вываливать на голову весь объем информации. Уже в данном объёме текст статьи получился сложным для прочтения за один раз.
за Ваши статьи спасибо большое, труд не маленький проделан. Прочел обе)
А вы предлогаете сразу раскачать статью до энциклопедии.
не совсем, это как бы варианты для последующих статей.
Ардуино все таки не та платформа, где борятся за оптимизацию кода.
ардуино это хорошая платформа для популяризации программирования микроконтроллеров с очень низким порогом входа и большой свободой выбора (наборы библиотек в огромном количестве, аппаратные модули и т.д). И вот тут уже может возникнуть проблема, когда пользователь подключает несколько неоптимизированных модулей и не понимает почему условная метеостанция не работает.
Я не говорю что надо "упарыватся" в оптимизацию, но важно показать возможные слабые места при совмещении с другим кодом.
Все ваши доводы конечно правильные, но не про ардуино
просто мнение, я могу в чем-то и ошибаться. Вопрос не в платформе как таковой, а в подходе к написанию кода (в том числе и для микроконтроллеров). Вы ведь лучше меня понимаете, что "arduino style" как плашка низкосортного кода появилась из некоторых библиотек. При этом есть и хорошо написанные модули, я вон например у себя на армах использую ArduinoJson. Из коробки прекрасно завелось, документация хорошая.
Напомню, статья про кнопку. Материал достаточно ёмкий, и в нем нет места для разъяснений работы с прерываниями.
Поэтому, по моему мнению, важно обозначать возможные проблемные места. Да можно прям в прерывании сделать некое действие, но вызывать блокирующий обмен по I2C все же не стоит. А вот почему, я Вам расскажу в следующей статье, где пойдет речь об обработчиках прерываний. Ведь расскажите?
В тексте я упомянул о том, что есть разные варианты обмена. Но акцент статьи всетаки не об этом.
Если фоновая программа в цикле опрашивает состояния какого-то глобального флага, который когда-то может быть установлен в прерывании, то чем это принципиально отличается от синхронной обработки без прерываний?!
цикл не крутится непрерывно, он "спит" и ждем событий. Любого. В том же STM (за не ARM контроллеры не скажу, не имел опыта), например, можно сделать что-то вроде:
в таком случае у вас обработка вне прерывания, но максимально близко к нему. Понятно, что наличие чего-то долго выполняющегося ломает данную систему, но тогда стоит посмотреть в сторону ОСРВ.
В фоновой программе работает какой-то процесс, и вдруг в прерывании меняется его состояние... сомнительно тоже.
для этого придумали мьютексы и машину состояний, которая оперативно отработает изменение состояния.
Мне кажется, что отреагировать на кнопку в прерывании обработкой каких-то данных - это не самая плохая идея. А вот потом уже подготовленные данные могут быть приняты и обработаны в фоновой программе. И на основе этих данных можно и флаги менять, и состояния переключать.
зависит от вида реакции. одно дело просто зажечь лампочку и/или зафиксировать время нажатия, другое запустить какой-нибудь долгий процесс. например, по нажатию на кнопку в зависимости от текущего состояния батарейки (опросить батарейку или менеджер питания), состояния прибора (опросить входы) нужно принять то или иное решение. В таком случае, в прерывании кнопки мы находимся гораздо дольше, что не всегда полезно.
Опять же, а если у вас таких прерываний не одно, а десять? Приоритетами замучаешься разруливать.
Видимо кто-то из комментаторов застрял в конце прошлого века. И до сих пор считает машинные циклы в подпрограммах.
Отвечу за себя исходя из личного опыта.
NRF52840 работаем со стеком BLE. Проброс событий из стека (закрытая либа) в основное приложение выполнен через программно генерирующий модуль событий (SWI EGU). Для BLE важны тайминги, реакция на события должна быть мгновенной, любой длительный процесс в обработчике приводит к краху стека. Да такты не считаем (пишем на С++), но обращаем внимание на это.Один из вариантов, проброс текущего ID события стека в высокоприоритетную задачу, где в кратчайшее время производится анализ события.
На stm32l0 (не самый быстрый контроллер на М0+ ядре) делал простой планировщик (с блекджеком, но без куртизанок) на машине состояний в обработчике прерываний systick. в полне себе работоспособное решение получилось. в прерывании находился примерно 150 - 200 мкс при частоте 1кГц. вполне допустимо, но и система была простой.
Современные контроллеры имеют достаточную производительность, чтобы не только флаги устанавливать в прерываниях.
То есть можно забить на оптимальный код? а если скорости и памяти не хватает, возьми МК пожирнее?
Всему есть предел, писать на ассемблере чтоб получить на 500, ну пусть на 1000 байт меньше кода тоже не стоит. Но и сидеть в обработчике прерывания больше 100 мкс порою слишком расточительно.
Для примера, посмотрите хотя бы как реализован HAL-драйвер в прерываниях таймеров у STM32
HAL от STM32 это весьма спорная штука, его небезосновательно ругают за плохую производительность. На багрепорты они реагируют порою никак. Из крайнего раза (в начале этого года), исправляли с коллегой функцию установки пина в 0. вместо использования регистра GPIOx->BSRR (который они в своем же Reference Manual рекомендуют для этих целей) почему-то использовали GPIOx->ODR. на первый взгляд разница небольшая, но для синхронного переключения нескольких пинов оказалось критичным.
в свое время был сильно шокирован, когда вместо SPL функции GpioPinSet использовал прямую запись в регистр из той же функции и получил разницу между вызовом события и реакцией на пине в десятки раз меньше ...
возможно имеется в виду, что в прерывании взводим флаг (или меняем переменную состояния для объекта, если объект глобальный), который уже потом в цикле (или в другом важно месте акромя обработчик прерывания) опрашивается и принимается решение о дальнейших действиях.
студенты медики читая конспект своего однокурсника по латыни случайно вызвали дьявола. тут же наверно можно призвать терракотовую армию во главе с императором драконом, не иначе)
зачем разрабатывать систему, которая упростит жизнь врачу, избавив его от избыточной писанины, если можно разработать ИИ для распознавания почерка? Были же попытки разработки шаблонов форм, под типовые заболевания.
p.s не думал что проблема почерка актуально для всего мира.
а объем кода какой будет на выходе? Для большого ПК или микрокомпьютера на линуксе вполне себе удобное решение, куда он видимо и заточен.
Но вот для МК (что-то типовое: до 100 МГц, 1 - 2 МБ ПЗУ, 256 - 512 кБ ОЗУ) с учетом что память нужно будет по другие полезные задачи, точно применимо будет?
для чего заморачиваться, если есть универсальная лошадка в виде J-Link(железо + софт)? причем на любой вкус, хочешь полноценно через GUI, хочешь через консоль. я для нашего производства bat файл делал, на входе путь до хранилища с файлами и код изделения, и все)
Я раньше на работе вынужден был использовать кейл. После этого куб как манна небесная!
Iar (на тот момент хороший компилятор - ужасный редактор кода), Keil (прикручивал запуск скриптов до/после компиляции, было удобно, но дорогой зараза), AC6 (тот же эклипс, стшники сначала его предлагали), Attolic пробовал до того, как он кубиком стал. сейчас вот Segger Embedded Studio и Visaul Studio (не код!) для nrf5340. В последней нравится редактор, но процесс сборки не быстрый. в SES есть как плюсы (для нордиков бесплатно), так и минусы (автодополнение работает плохо).
Так что однозначно лучшей среды нет, везде свои плюс\минусы. Но ИМХО по теме статьи, Qt для МК в таком виде слишком уж избыточно. Особенно если использовать только редактор кода.
запуск самой среды, переключение между отладка/написание кода (забыл как в экплисе это называется), по сравнению с Segger Embedded Studio тормозит.
Он вроде уже в нескольких потоках компилирует.
Сам этап компиляции может и быстро происходит, не сравнивал настолько детально.
Графическая настройка тактирования и прочие фичи - это функции CubeMX
Это нравится. Cube IDE нет.
Опять же повторюсь, на мой вкус этот фломастер не вкусный).Я не говорю что оно плохое, я говорю что оно не всем нравится. Поэтому я смотрю на альтернативы Cube IDE, тем более что она только под ST, что не есть удобно при работе с другими МК.
личные предпочтения могут быть. на мой вкус, в кубике полезно две вещи: наглядное распределение пинов с возможностью выбора альтернативы и дерево тактирования. Плюс-Минус полезен расчетчик потребления (получится такие же цифры как в нем весьма не просто бывает иногда). Как редактор кода и среда отладки - не удобная, медленная.
Этот же контроллер, по идее при использовании смартфона подключенного к ЗУ (да, наверно так делать не надо, но иногда прям хочется), должен брать ток для питания устройства от сети и оставшимся током заряжать АКБ. Сейчас же, ситуация выглядит так, что ЗУ вливает ток в АКБ, а смарфон в тот же самый момент пытается его разряжать.
Может не все так делают, но из тех что были в руках (xiomi redmi 7 (вздулся АКБ), asus zb500 (перестал держать заряд, вздулся) , sony experia V (вздулся АКБ, отслоил сенсор от экрана) из тех что помню) однозначно убивали батарейку при пользовании смартом на зарядке. сам стараюсь так не делать, супругу убедить сложнее в этом
хотя в целом, что такого дает Qt, без чего трудно будет в микроконтроллере? Code Lite тоже open source, тоже можно подцепить внешний компилятор. Только более легкая по сравнению с тем Qt, особенно если последний используется только как редактор кода.
Интересно, а почему такие книги идут преимущественно за авторством западных программистов? Причина только в сложности/лени/не желании связываться с процессом написания книги?
на шине не заметил балансировку и равномерный отбор ресурсов, для 4 конвейеров схемы весьма простые. Или лесенка делителей (сплитер) имеет приориты выхода на одну сторону?
В контексте архитектуры, это должно иметь значение, ведь первый "жадный" пользователь съест почти все ресурсы, не оставив последнему ничего.
хорошего много не бывает.
поэтому я только по комментариям ;)
p.s. диаграммы в ручном режиме подсвечивали красным или софт есть удобный?
за Ваши статьи спасибо большое, труд не маленький проделан. Прочел обе)
не совсем, это как бы варианты для последующих статей.
ардуино это хорошая платформа для популяризации программирования микроконтроллеров с очень низким порогом входа и большой свободой выбора (наборы библиотек в огромном количестве, аппаратные модули и т.д). И вот тут уже может возникнуть проблема, когда пользователь подключает несколько неоптимизированных модулей и не понимает почему условная метеостанция не работает.
Я не говорю что надо "упарыватся" в оптимизацию, но важно показать возможные слабые места при совмещении с другим кодом.
просто мнение, я могу в чем-то и ошибаться. Вопрос не в платформе как таковой, а в подходе к написанию кода (в том числе и для микроконтроллеров). Вы ведь лучше меня понимаете, что "arduino style" как плашка низкосортного кода появилась из некоторых библиотек. При этом есть и хорошо написанные модули, я вон например у себя на армах использую ArduinoJson. Из коробки прекрасно завелось, документация хорошая.
Поэтому, по моему мнению, важно обозначать возможные проблемные места. Да можно прям в прерывании сделать некое действие, но вызывать блокирующий обмен по I2C все же не стоит. А вот почему, я Вам расскажу в следующей статье, где пойдет речь об обработчиках прерываний. Ведь расскажите?
Значит цикл не окончен)
цикл не крутится непрерывно, он "спит" и ждем событий. Любого. В том же STM (за не ARM контроллеры не скажу, не имел опыта), например, можно сделать что-то вроде:
в таком случае у вас обработка вне прерывания, но максимально близко к нему. Понятно, что наличие чего-то долго выполняющегося ломает данную систему, но тогда стоит посмотреть в сторону ОСРВ.
для этого придумали мьютексы и машину состояний, которая оперативно отработает изменение состояния.
зависит от вида реакции. одно дело просто зажечь лампочку и/или зафиксировать время нажатия, другое запустить какой-нибудь долгий процесс. например, по нажатию на кнопку в зависимости от текущего состояния батарейки (опросить батарейку или менеджер питания), состояния прибора (опросить входы) нужно принять то или иное решение. В таком случае, в прерывании кнопки мы находимся гораздо дольше, что не всегда полезно.
Опять же, а если у вас таких прерываний не одно, а десять? Приоритетами замучаешься разруливать.
Отвечу за себя исходя из личного опыта.
NRF52840 работаем со стеком BLE. Проброс событий из стека (закрытая либа) в основное приложение выполнен через программно генерирующий модуль событий (SWI EGU). Для BLE важны тайминги, реакция на события должна быть мгновенной, любой длительный процесс в обработчике приводит к краху стека. Да такты не считаем (пишем на С++), но обращаем внимание на это.Один из вариантов, проброс текущего ID события стека в высокоприоритетную задачу, где в кратчайшее время производится анализ события.
На stm32l0 (не самый быстрый контроллер на М0+ ядре) делал простой планировщик (с блекджеком, но без куртизанок) на машине состояний в обработчике прерываний systick. в полне себе работоспособное решение получилось. в прерывании находился примерно 150 - 200 мкс при частоте 1кГц. вполне допустимо, но и система была простой.
То есть можно забить на оптимальный код? а если скорости и памяти не хватает, возьми МК пожирнее?
Всему есть предел, писать на ассемблере чтоб получить на 500, ну пусть на 1000 байт меньше кода тоже не стоит. Но и сидеть в обработчике прерывания больше 100 мкс порою слишком расточительно.
HAL от STM32 это весьма спорная штука, его небезосновательно ругают за плохую производительность. На багрепорты они реагируют порою никак. Из крайнего раза (в начале этого года), исправляли с коллегой функцию установки пина в 0. вместо использования регистра GPIOx->BSRR (который они в своем же Reference Manual рекомендуют для этих целей) почему-то использовали GPIOx->ODR. на первый взгляд разница небольшая, но для синхронного переключения нескольких пинов оказалось критичным.
в свое время был сильно шокирован, когда вместо SPL функции GpioPinSet использовал прямую запись в регистр из той же функции и получил разницу между вызовом события и реакцией на пине в десятки раз меньше ...
а потом они придумал HAL с ещё большой структурой
возможно имеется в виду, что в прерывании взводим флаг (или меняем переменную состояния для объекта, если объект глобальный), который уже потом в цикле (или в другом важно месте акромя обработчик прерывания) опрашивается и принимается решение о дальнейших действиях.
студенты медики читая конспект своего однокурсника по латыни случайно вызвали дьявола. тут же наверно можно призвать терракотовую армию во главе с императором драконом, не иначе)
зачем разрабатывать систему, которая упростит жизнь врачу, избавив его от избыточной писанины, если можно разработать ИИ для распознавания почерка? Были же попытки разработки шаблонов форм, под типовые заболевания.
p.s не думал что проблема почерка актуально для всего мира.
МоскваСтатья не сразустроиласьпишется!по отзывам у него лучший компилятор. но смущает несколько стоимость лицензии)
а объем кода какой будет на выходе? Для большого ПК или микрокомпьютера на линуксе вполне себе удобное решение, куда он видимо и заточен.
Но вот для МК (что-то типовое: до 100 МГц, 1 - 2 МБ ПЗУ, 256 - 512 кБ ОЗУ) с учетом что память нужно будет по другие полезные задачи, точно применимо будет?
для чего заморачиваться, если есть универсальная лошадка в виде J-Link(железо + софт)? причем на любой вкус, хочешь полноценно через GUI, хочешь через консоль. я для нашего производства bat файл делал, на входе путь до хранилища с файлами и код изделения, и все)
Iar (на тот момент хороший компилятор - ужасный редактор кода), Keil (прикручивал запуск скриптов до/после компиляции, было удобно, но дорогой зараза), AC6 (тот же эклипс, стшники сначала его предлагали), Attolic пробовал до того, как он кубиком стал. сейчас вот Segger Embedded Studio и Visaul Studio (не код!) для nrf5340. В последней нравится редактор, но процесс сборки не быстрый. в SES есть как плюсы (для нордиков бесплатно), так и минусы (автодополнение работает плохо).
Так что однозначно лучшей среды нет, везде свои плюс\минусы. Но ИМХО по теме статьи, Qt для МК в таком виде слишком уж избыточно. Особенно если использовать только редактор кода.
запуск самой среды, переключение между отладка/написание кода (забыл как в экплисе это называется), по сравнению с Segger Embedded Studio тормозит.
Сам этап компиляции может и быстро происходит, не сравнивал настолько детально.
Это нравится. Cube IDE нет.
Опять же повторюсь, на мой вкус этот фломастер не вкусный). Я не говорю что оно плохое, я говорю что оно не всем нравится. Поэтому я смотрю на альтернативы Cube IDE, тем более что она только под ST, что не есть удобно при работе с другими МК.
личные предпочтения могут быть. на мой вкус, в кубике полезно две вещи: наглядное распределение пинов с возможностью выбора альтернативы и дерево тактирования. Плюс-Минус полезен расчетчик потребления (получится такие же цифры как в нем весьма не просто бывает иногда). Как редактор кода и среда отладки - не удобная, медленная.
А зачем, если есть официальное решение от qt? https://www.qt.io/product/develop-software-microcontrollers-mcu
на youtube можно даже найти ролики, где показывают производительность системы.
те же st предлагают touch gfx, который и дизайнер, и код на с++, и заточек по stm32 более чем. и зачем тогда дизайнер?
Этот же контроллер, по идее при использовании смартфона подключенного к ЗУ (да, наверно так делать не надо, но иногда прям хочется), должен брать ток для питания устройства от сети и оставшимся током заряжать АКБ. Сейчас же, ситуация выглядит так, что ЗУ вливает ток в АКБ, а смарфон в тот же самый момент пытается его разряжать.
Может не все так делают, но из тех что были в руках (xiomi redmi 7 (вздулся АКБ), asus zb500 (перестал держать заряд, вздулся) , sony experia V (вздулся АКБ, отслоил сенсор от экрана) из тех что помню) однозначно убивали батарейку при пользовании смартом на зарядке. сам стараюсь так не делать, супругу убедить сложнее в этом
для тех же STM и "кубик" то бесплатен со средой.
хотя в целом, что такого дает Qt, без чего трудно будет в микроконтроллере? Code Lite тоже open source, тоже можно подцепить внешний компилятор. Только более легкая по сравнению с тем Qt, особенно если последний используется только как редактор кода.
Интересно, а почему такие книги идут преимущественно за авторством западных программистов? Причина только в сложности/лени/не желании связываться с процессом написания книги?
про Эйнштейна тоже говорили "тормоз", так как не говорил в три года. По его словам, он просто не считал нужным озвучивать свои слова в три года.
на шине не заметил балансировку и равномерный отбор ресурсов, для 4 конвейеров схемы весьма простые. Или лесенка делителей (сплитер) имеет приориты выхода на одну сторону?
В контексте архитектуры, это должно иметь значение, ведь первый "жадный" пользователь съест почти все ресурсы, не оставив последнему ничего.
почему вместо привычного термина "запуск" использовано непонятное слово "лонч", которое на самом деле английское launch?