Так основная проблема в текущем виде - цена, даже если не заморачиваться со своей платой, то можно уложиться в сильно меньшую стоимость, чем брать любой одноплатник, заведомо отъедая одно ядро на мало эффективную работу. И как тут люди заметили, при грамотном подходе с DMA вы получите и лучшие показатели по скорости АЦП и ядро будет в простое почти все время, можно его спокойно нагрузить ещё чем-нибудь.
Ну вы же не гигабайтами данные храните + выгрузка на сервер. Обновляться можно так же по сети/UART/microsd. Одноплатник все же дорого для такого детектора. Причем одно ядро которого фуллтайм занято, я бы понял если бы детекции была мало ощутимой фоновой нагрузкой. Для массовости стоит упростить и удешевить решение.
Да имелась ввиду документация, NVIC упомянут естественно в контексте ARM, в других контроллерах контроллер прерываний может иначе именоваться.
В RTOS это разруливается отдельным api работы с примитивами синхронизации и очередями из ISR. Это конечно накладывает определенные затраты на время реакции системы и в каждом случае надо смотреть под конкретную задачу. Грубо говоря сам callback может быть в целом отвязан логикой от RTOS, но в нем все равно придется вернуть например семафор/очередь через api, чтобы дать контекст планировщику. Допустим есть несколько таймеров, callback они могут дергать один и тот же, внутри уже определяем кто конкретно его вызвал и для каждого отдельно дергаем семафоры RTOS. Только держим в уме, что помимо приоритетов самих прерываний нужно учитывать и приоритеты задач. Таким образом можно условно "параллельно" обработать несколько таймеров например, просто на каждом тике прыгая между отдельными задачами туда-обратно, естественно по итогу потратим и на один и на другой больше времени, но один при этом не будет ждать полного выполнения таски другого.
Не путайте callback и сам вызов обработчика прерывания, у STM callback'и это буквально функции вызывающиеся HAL кодом из ISR и они сами читают и сбрасывают флаги в большинстве своем, да по умолчанию они имеют weak атрибут и 0 нагрузки внутри, но логика проверки флагов присутствует всегда, а это те самые ветвления кушающие драгоценные такты. Поэтому при большом объеме прерываний их и невозможно нормально использовать, так как главное правило "обработчик должен быть компактным и достаточным" нарушается. Плюс расходы на перенос контекста в стек и обратно. Такое считается всегда для худшего варианта развития событий когда асинхронных вызовов может прилететь сразу пачкой и у каждого есть жёсткие требования по тайм-ауту. Изначальная ценность callback'ов и самого HAL - простота миграции кода между разными МК.
Все callback вызовы всегда прозрачны, независимо от того работаете вы с голым железом или через ОСРВ. Если требуется ковырять макросы ST, то это явный указатель того, что в данной части кода лучше вообще отказаться от callback'ов и написать обработчик прерывания самостоятельно, благо это не рокетсайнс. И номенклатура прерываний там не такая страшная, открываем описание NVIC и все на ладони.
"будет туча callback, реализовать которые надо самому программисту"
Это далеко не слезы) Как минимум, коллбеки сами обрабатывают флаги большинства периферии (за исключением коллбеков ошибок, там да, надо ручками почитать стейты и обработать их). А, если прямо жмет, то лучше вообще обойтись без них и ручками написать свои, исходя из заложенного функционала, чтобы не тратить время на проверку флагов, которые никогда в данной конфигурации не появятся вовсе.
Количество тактов по-честному все равно нужно считать после трансляции в асм. Либо закладывать везде счетчики тиков и понимать, на чем реально они съедаются (пока опустим даже работу стека в режиме вложенных прерываний). Плюс не забываем про конвейер в АРМ, который с теми же nop ассемблерными вставками может вести себя по разному. А вот барьеры памяти, кеширование - действительно первое время вызывают боль, но это уже касается высокопроизводительных ядер, у того же Cortex-M4 кеш работает предсказуемее и иначе в отличии от М7 и надо понимать как организовать доступ к данным тому же DMA.
Так что жить стало определенно проще. Я начинал с 8051 и его ассемблера, и возвращаться к нему после АРМ и Си вообще не хочется)
Ну с MPU я сам не заморачивайся ещё, не возникало необходимости, но теоретически она как раз для ОСРВ и задумана на первый взгляд.
DMA и часть HAL ответственная за периферию уже сейчас спокойно обслуживается в контексте прерываний как в baremetal так и в ОСРВ. FreeRTOS уже предлагает вполне удобное api аппаратных прерываний. Считать по тактам приходилось наверное всего пару раз, когда с DMA на F3xx серии понадобилось вводить задержки в транзакции DMA: нужно было выжать максимум из внешнего АЦП, а DMA там не даёт настроить задержки между пакетами как в H7 например, время оцифровки никто не отменял и по итогу АЦП просто нон-стопом заваливали транзакциями на запуск, из-за чего бедолага циклически перезапускал процесс и не отдавал прерывание готовности данных в FIFO.
Я не уверен, что сейчас в целом много разработчиков, которые осилят армовый асм.
Эмбедд идёт примерно к тому же на самом деле. Конфиг периферии теперь настраиваются зачастую с помощью какого-нибудь CubeMX или его аналога, библиотеки тоже уже стараются максимально отвязать разработчика от работы с регистрации напрямую. Да и само железо куда приятнее становится, просто сравните 8051, ОЗУ которых измеряется в лучшем случае сотнями байт, и ARM, где речь уже о десятках килобайт, а то и мегабайт. Асинхронная работа отдается на откуп готовых ОСРВ.
Плохо ли это? Скорее нет, чем да. Зрелые решения отлажены годами и вероятность сломать что-то, используя их, куда ниже, чем реализуя свой велосипед, хотя и такое нередко приходится делать. В конце концов это позволяет быстро поднять прототип и уже после пуститься в оптимизацию при необходимости.
Как будто тот же LittleFS поднять все ещё проще, и работать будет одинаково в любом инструментарии. Разве что файл линковщика желательно все же поправить для выделения секции. Я честно не могу себе представить сценария, где-нужно так заморачиваться с хранением констант, разве, что флеша прямо совсем не хватает.
Не лучше выделить пару страниц под простую фс и заливать данные подобного рода уже после прошивки? Таким образом при проверке целостности прошивки у вас будут одинаковые контрольные суммы для каждого экземпляра устройства, что может быть критично в контроле при серийном производстве? И так же можно отдельно контролировать целостность данных в фс, отдельно хранить "слепки" фс для каждого устройства при необходимости восстановления/разбора инцидентов, легче организовать шифрование данных.
Если и говорить о популяризации, то стоило бы выложить в общий доступ портированную библиотеку HAL. Чем больше открытого кода и доступных примеров, тем больше шанс сделать решение привлекательным.
Зарезервируйте кусочек флеша, для хранения конфига устройств на шинах. При запуске МК конфигурируете адресатов на шинах. По крайней мере прочитав документацию, вы бы сразу поняли, как конфигурируются адреса датчиков: модуль вам подходит из коробки / не подходит, а какой подойдёт при правильном прикладывание паяльника. Вы правда в этом проблему видите?
Как сократить время такой "разработки" до пары часов с учётом похода в магазин? Прочитать документацию. Поддерживаю коллегу выше - ардуино головного мозга.
Матрицу диодов все же лучше было бы представить в виде массива структур. Так сразу оградите пользователей либы от необходимости держать в уме порядок цветов для каждого диода в матрице и код станет дружелюбнее для чтения.
Мне особенно нравится, что компания вроде пусть и с сомнительной формулировкой решила, что направление нужное, но при этом человек должен выбивать ресурсы на это направление и снова это же доказывать. Т.е. буквально для начала нужен был аналитик, а не ПМ. Не удивлюсь если был обещан бюджет в 100500 золота и свобода в сборе команды, а по факту вышло, что этот бюджет ещё и выбить надо.
Для этого уже есть куча Nucleo и Discovery плат от самой ST. Nucleo так вообще идут с Ардуино френдли колодками. Да и куб с халом уже вполне дружелюбны к новичкам.
Конкретно у этих лидаров была проблема с надёжностью лазера. По мощности настроены на максимум и в таком режиме живут обычно не больше года (в формате использования робота пылесоса). Ремонтировать их тоже тот ещё квест: лазер и приемник имеют поляризацию и всю эту оптическую систему нужно настраивать вместе. В противном случае вместо нормальной карты получаем заваленные стены и сходяшую с ума следом навигацию.
В контексте данного примера, не очень понимаю отличие от того же HAL, он точно так же цепляется за systick? и соответственно абстракция таймкипера работает в блокирующие режиме или нет? Не использовал раст, поэтому поправьте, если не правильно понял.
А чем лучше то? Один фиг важно обеспечить правильную последовательность обращений к памяти (атомарность) в коде работающем в прерываниях или асинхронных тасках в контексте ОСРВ, что зависит от архитектуры железа (DMB и т.п. в ARM например), что и в Си спокойно реализуется.
Так основная проблема в текущем виде - цена, даже если не заморачиваться со своей платой, то можно уложиться в сильно меньшую стоимость, чем брать любой одноплатник, заведомо отъедая одно ядро на мало эффективную работу. И как тут люди заметили, при грамотном подходе с DMA вы получите и лучшие показатели по скорости АЦП и ядро будет в простое почти все время, можно его спокойно нагрузить ещё чем-нибудь.
Ну вы же не гигабайтами данные храните + выгрузка на сервер. Обновляться можно так же по сети/UART/microsd. Одноплатник все же дорого для такого детектора. Причем одно ядро которого фуллтайм занято, я бы понял если бы детекции была мало ощутимой фоновой нагрузкой. Для массовости стоит упростить и удешевить решение.
Да имелась ввиду документация, NVIC упомянут естественно в контексте ARM, в других контроллерах контроллер прерываний может иначе именоваться.
В RTOS это разруливается отдельным api работы с примитивами синхронизации и очередями из ISR. Это конечно накладывает определенные затраты на время реакции системы и в каждом случае надо смотреть под конкретную задачу. Грубо говоря сам callback может быть в целом отвязан логикой от RTOS, но в нем все равно придется вернуть например семафор/очередь через api, чтобы дать контекст планировщику. Допустим есть несколько таймеров, callback они могут дергать один и тот же, внутри уже определяем кто конкретно его вызвал и для каждого отдельно дергаем семафоры RTOS. Только держим в уме, что помимо приоритетов самих прерываний нужно учитывать и приоритеты задач. Таким образом можно условно "параллельно" обработать несколько таймеров например, просто на каждом тике прыгая между отдельными задачами туда-обратно, естественно по итогу потратим и на один и на другой больше времени, но один при этом не будет ждать полного выполнения таски другого.
Не путайте callback и сам вызов обработчика прерывания, у STM callback'и это буквально функции вызывающиеся HAL кодом из ISR и они сами читают и сбрасывают флаги в большинстве своем, да по умолчанию они имеют weak атрибут и 0 нагрузки внутри, но логика проверки флагов присутствует всегда, а это те самые ветвления кушающие драгоценные такты. Поэтому при большом объеме прерываний их и невозможно нормально использовать, так как главное правило "обработчик должен быть компактным и достаточным" нарушается. Плюс расходы на перенос контекста в стек и обратно. Такое считается всегда для худшего варианта развития событий когда асинхронных вызовов может прилететь сразу пачкой и у каждого есть жёсткие требования по тайм-ауту. Изначальная ценность callback'ов и самого HAL - простота миграции кода между разными МК.
Все callback вызовы всегда прозрачны, независимо от того работаете вы с голым железом или через ОСРВ. Если требуется ковырять макросы ST, то это явный указатель того, что в данной части кода лучше вообще отказаться от callback'ов и написать обработчик прерывания самостоятельно, благо это не рокетсайнс. И номенклатура прерываний там не такая страшная, открываем описание NVIC и все на ладони.
"будет туча callback, реализовать которые надо самому программисту"
Это далеко не слезы) Как минимум, коллбеки сами обрабатывают флаги большинства периферии (за исключением коллбеков ошибок, там да, надо ручками почитать стейты и обработать их). А, если прямо жмет, то лучше вообще обойтись без них и ручками написать свои, исходя из заложенного функционала, чтобы не тратить время на проверку флагов, которые никогда в данной конфигурации не появятся вовсе.
Количество тактов по-честному все равно нужно считать после трансляции в асм. Либо закладывать везде счетчики тиков и понимать, на чем реально они съедаются (пока опустим даже работу стека в режиме вложенных прерываний). Плюс не забываем про конвейер в АРМ, который с теми же nop ассемблерными вставками может вести себя по разному. А вот барьеры памяти, кеширование - действительно первое время вызывают боль, но это уже касается высокопроизводительных ядер, у того же Cortex-M4 кеш работает предсказуемее и иначе в отличии от М7 и надо понимать как организовать доступ к данным тому же DMA.
Так что жить стало определенно проще. Я начинал с 8051 и его ассемблера, и возвращаться к нему после АРМ и Си вообще не хочется)
Ну с MPU я сам не заморачивайся ещё, не возникало необходимости, но теоретически она как раз для ОСРВ и задумана на первый взгляд.
DMA и часть HAL ответственная за периферию уже сейчас спокойно обслуживается в контексте прерываний как в baremetal так и в ОСРВ. FreeRTOS уже предлагает вполне удобное api аппаратных прерываний. Считать по тактам приходилось наверное всего пару раз, когда с DMA на F3xx серии понадобилось вводить задержки в транзакции DMA: нужно было выжать максимум из внешнего АЦП, а DMA там не даёт настроить задержки между пакетами как в H7 например, время оцифровки никто не отменял и по итогу АЦП просто нон-стопом заваливали транзакциями на запуск, из-за чего бедолага циклически перезапускал процесс и не отдавал прерывание готовности данных в FIFO.
Я не уверен, что сейчас в целом много разработчиков, которые осилят армовый асм.
Эмбедд идёт примерно к тому же на самом деле. Конфиг периферии теперь настраиваются зачастую с помощью какого-нибудь CubeMX или его аналога, библиотеки тоже уже стараются максимально отвязать разработчика от работы с регистрации напрямую. Да и само железо куда приятнее становится, просто сравните 8051, ОЗУ которых измеряется в лучшем случае сотнями байт, и ARM, где речь уже о десятках килобайт, а то и мегабайт. Асинхронная работа отдается на откуп готовых ОСРВ.
Плохо ли это? Скорее нет, чем да. Зрелые решения отлажены годами и вероятность сломать что-то, используя их, куда ниже, чем реализуя свой велосипед, хотя и такое нередко приходится делать. В конце концов это позволяет быстро поднять прототип и уже после пуститься в оптимизацию при необходимости.
А в чем практическая необходимость такого решения?
Как будто тот же LittleFS поднять все ещё проще, и работать будет одинаково в любом инструментарии. Разве что файл линковщика желательно все же поправить для выделения секции. Я честно не могу себе представить сценария, где-нужно так заморачиваться с хранением констант, разве, что флеша прямо совсем не хватает.
Не лучше выделить пару страниц под простую фс и заливать данные подобного рода уже после прошивки? Таким образом при проверке целостности прошивки у вас будут одинаковые контрольные суммы для каждого экземпляра устройства, что может быть критично в контроле при серийном производстве? И так же можно отдельно контролировать целостность данных в фс, отдельно хранить "слепки" фс для каждого устройства при необходимости восстановления/разбора инцидентов, легче организовать шифрование данных.
Если и говорить о популяризации, то стоило бы выложить в общий доступ портированную библиотеку HAL. Чем больше открытого кода и доступных примеров, тем больше шанс сделать решение привлекательным.
Зарезервируйте кусочек флеша, для хранения конфига устройств на шинах. При запуске МК конфигурируете адресатов на шинах. По крайней мере прочитав документацию, вы бы сразу поняли, как конфигурируются адреса датчиков: модуль вам подходит из коробки / не подходит, а какой подойдёт при правильном прикладывание паяльника. Вы правда в этом проблему видите?
Ну напишет с CMSIS и выиграет что? Я понимаю когда в память сильно упираемся или надо пик производительности выжать.
Как сократить время такой "разработки" до пары часов с учётом похода в магазин? Прочитать документацию. Поддерживаю коллегу выше - ардуино головного мозга.
Матрицу диодов все же лучше было бы представить в виде массива структур. Так сразу оградите пользователей либы от необходимости держать в уме порядок цветов для каждого диода в матрице и код станет дружелюбнее для чтения.
При желании можно сюда же добавить поле для управления яркостью.
Мне особенно нравится, что компания вроде пусть и с сомнительной формулировкой решила, что направление нужное, но при этом человек должен выбивать ресурсы на это направление и снова это же доказывать. Т.е. буквально для начала нужен был аналитик, а не ПМ. Не удивлюсь если был обещан бюджет в 100500 золота и свобода в сборе команды, а по факту вышло, что этот бюджет ещё и выбить надо.
Для этого уже есть куча Nucleo и Discovery плат от самой ST. Nucleo так вообще идут с Ардуино френдли колодками. Да и куб с халом уже вполне дружелюбны к новичкам.
Конкретно у этих лидаров была проблема с надёжностью лазера. По мощности настроены на максимум и в таком режиме живут обычно не больше года (в формате использования робота пылесоса). Ремонтировать их тоже тот ещё квест: лазер и приемник имеют поляризацию и всю эту оптическую систему нужно настраивать вместе. В противном случае вместо нормальной карты получаем заваленные стены и сходяшую с ума следом навигацию.
В контексте данного примера, не очень понимаю отличие от того же HAL, он точно так же цепляется за systick? и соответственно абстракция таймкипера работает в блокирующие режиме или нет? Не использовал раст, поэтому поправьте, если не правильно понял.
А чем лучше то? Один фиг важно обеспечить правильную последовательность обращений к памяти (атомарность) в коде работающем в прерываниях или асинхронных тасках в контексте ОСРВ, что зависит от архитектуры железа (DMB и т.п. в ARM например), что и в Си спокойно реализуется.