Возможно, но тогда какой смысл их вводить и описывать для простых ядер типа М3 и М4? Я согласен с тем что надо понимать когда они действительно работают, а когда нет.
В моем понимании, если у переменной (64 бита например) обращается кто-то из кода и в этот же момент приходит прерывание в котором эта же переменная обновляется, то очень с большой долей вероятности можно получить некорректное значение переменной. Отсюда и возникает необходимость в DMB, которая заставит конвейер выполнить все операции с памятью до этой инструкции:
Команда DМВ используется в качестве барьера памяти данных. Она rарантирует, что все обращения к памяти) явно указанные до вызова команды DMB будут выполнены до Toro, как начнут выполняться явные обращения к памяти) появляющиеся после команды DМВ. Команда DМВ не влияет на порядок или выполнение
Причем в тестах, DMB именно что следовало располагать в прерывании таймера. (Я делал составной таймер, правда на nrf52840, но в данном случае речь по то же самое ядро М4. Сложность была в том, что мастер периодически делал коррекцию тика через алгоритм синхронизации. Поэтому в прерывании нужно было считать как целые, так и доли секунд. Проблема была именно в атомарном доступе к переменной, которая средствами языка не решилась. Неделя ушла на то, чтобы научиться получать эту Ситуацию стабильно и примерно месяц тестов чтобы убедится в полноценном решении.
Dsb в этом плане для аппаратных регистров подходит. Она нужна чтобы предыдущая команда была исполнена сразу. В применении к таймера - когда нужно забрать значение и тут же обнулить таймер. Проблемная ситуация: кто-то влезает между этими действиями. Вендор рекомендует после записи делать "volatile void" чтение. Документация на ядро - DSB.
Поэтому польза не только для многоядерных, но и для одиночных контроллер есть.
Edit: да, если параноить дальше, то ещё REX (исклюзианый доступ) надо пользовать. Эти инструкции позволят оценить что при обращении к ячейке памяти никто больше туда не влезал. Но это уже отдельная тема, которую я совсем поверхностно смотрел
По дизассемблеру - нет. Компилятор использовал от segger, который явно сделан на основе arm clang.
На том же stackoverflow есть несколько тем посвященных dsb и dmb.
А ещё книжка хорошая есть по ядру М3 и М4 от (имя забыл, Янг кажется). Плюс спеку на ядро полезно посмотреть. Там как раз описывается зачем эти инструкции нужны и область их применения.
контроллер 32 бита, переменная 64 -> запись за один такт не возможна. нужно либо ставить критическую секцию, что чревато блокировкой чего-то важного достаточно часто.
и да, на ARM Cortex M критическая секция не гарантирует что инструкции внутри нее будут выполнены в правильном порядке, поэтому нужны ещё барьерные инструкции.
tim3Tick64 ++;
вот этот инкремент так же может быть выполнен уже после выхода из прерывания, если конвейер ядра решит что так быстрее. то есть сначала выйдет из IRQ, затем инкремент.
это не только в документации на ядро описано, но и реальный баг который я неделю отлавливал у себя.
А что на русский язык слово task, никак не переводится?
Переводиться, но я бы предпочел оставить так. При использовании инструментов без локализации есть огромное преимущество в лице сообщества, которое часто общается на буржуйском английском языке, и очень часто возникает ситуация. когда надо что-то изменить в настройках и ... ты не можешь их найти, потому что переводчик решил что правильнее так, а не иначе.
По итогу настройка ищется просто методом "тыка". Исхожу из опыта работы с "русским" сервером гитлаб, блендером и те же VS Code.
если для Vim частый запрос "как выйти", то для VS Code достаточно популярный запрос "как вернуть английский язык"
программист-микроконтроллеров обязан уметь работать с тестером и осциллографом, тогда вот такие аппаратные баги не будут на 2 дня выводить из строя программиста. элементарные вещи: убедись что нет КЗ, убедись что сигнал имеет тот уровень, которые ты выставил и так далее. да можно не знать всех тонкостей работы электроники и проектировать аналоговые фильтры на рассыпухе, но элементарные вещи уметь обязательно. не для схемотехников же придуманы логические анализаторы и прочее.
только сейчас осознал, что линейный вход для наушников на телефоне, расположенный снизу как раз таки призван для обеспечения наклона аппарата на нужные 22 с хвостиком градуса вправо. всего лишь нужно найти угловой штекер, чтобы лишний раз не ломать кабель и вот оно счастье!!
При этом не открывая скрипт сборки не узнаешь, какой модуль идет в сборку, а какой нет. Дерево проекта в этом плане имеет хотя бы подсветку активных файлов, которые попадают в данную сборку.
Можно буквально одной строчкой в скриптах сборки добавлять или исключать один конкретный программный компонент (десятки файлов)
Клик ПКМ в выпадающем меню выбрать "исключить из сборки". При необходимости повторить для нескольких конфигураций.
я не ставлю цель убедить вас в неправильности использования скриптов сборки, пишите и собирайте как вам удобно. вы же упорно ставите цель убедить меня в том, что я неправильно работаю.
Это только ваше мнение и я с ним имею право быть не согласным. Я согласен что скрипты в сборке полезны и более того, без них часто бывает сложно, но ведь скрипты умеют вызывать наверно все IDE как перед компиляций, так и после. Что в принципе я и использую. У меня есть несколько batch файлов, которые делают разные полезные вещи (например, формируют файл для "обновления по воздуху", правильно его именуют, помещают в правильную директорию на сервере и рядом бонусом кладут файл с описанием изменений). Были даже bash-скрипты которые тянули из гита описание тэгов и формировали историю версий.
И мне кажется, вы смешиваете сущности. Есть скрипты окружения (формирование номера версии, перекладывание результатов сборки куда-либо), а есть система сборки (компиляция + линковка). Для общего понимания наверно да, надо уметь собирать с помощью своего скрипта, но в большинстве случае: зачем? Какое преимущество это дает? Если Вася собирает проект в IDE, получает ровно тот же самый hex файл прошивки и тратит на него меньше времени, то зачем руководителю платить Пете, который умеет собирать из makefile, но тратит на весь процесс больше времени? Если при этом Васе ещё и IDE помогает в отладке, то почему бы и не купить ему лицензию, ведь это сэкономит много времени.
Я думаю есть отрасль, где существуют требования по использованию именно makefile (или его аналогов). Но это же не повод обобщать на всех и на все?
Раз уж спросили, отвечу: я использую IDE, Segger Embedded Studio (SES) - так как для Nordic у них свободная лицензия, а последнее время я работаю только с ними. Есть как плюсы, так и минусы. Главный плюс - оно работает из коробки. Опять же, из него запускается Ozone весьма интересный, хоть и специфичный отладчик-профилировщик.
Пробовал Visual Studio с плагином VisualGDB (для зефира, в целом весьма удобно, так как смог прикрутить запуск RTT логгера, что позволило видеть логи сразу в консоле студии), в планах попробовать освоить Visual Studio Code.
Пару раз файлы открывались в Qt Creator, когда надо было строчно поправить по результатам тестов и отдать на повторный прогон устройство.
часто заготовки классов пишу в Notepad++ просто потому что привык к нему.
По итогу могу подтвердить что, все фломастеры разные как на цвет, так и на вкус. Где-то удобно сделано автодополнение кода, где-то подсветка лучше, а где-то есть "странный" статический анализатор кода, который может выдать сообщение "данный код не используется в файлах. Есть вызов функции в файлах ... "
Разве это имеет большое значение в чем писать код сейчас или чем его собирать? Писать в текстовом редакторе и руками вызывать make ? Можно, но для чего, если придумали более удобный инструмент?
Этот глюченный J-Link только с 10й попытки пошаговую отладку запускает
сколько лет с ним работаю, проблема возникла только один раз с китайским клоном, в котором слетела прошивка. в остальных случаях проблем не возникло ни разу. Правда я с эклипсом особо не работаю, не понравилось на заре танцы с бубном устраивать для его настройки так сильно, что до сих пор и не пользуюсь. Но это чисто вкусовщина, на мой взгляд эти фломастеры не вкусные.
зато для производство получилось сделать несколько простых скриптов, которые через J-Link автоматически шьют прошивку, серийные номера и калибровочные данные в память. можно ли это сделать другими средствами? наверно можно. Но будет ли проще?
В то время как OpenOCD безотказный как автомат Калашникова
Он может выводить RTT поток с микроконтроллера? это режим трассировки причем двунаправленный, аналог SWO и semihosting, только немного быстрее. J-Link умеет.
хреновый тогда сеньор, ибо сеггер это ещё и J-Link, наиболее часто встречаемый в последнее время программатор-отладчик, который умеет как в ARM, так и в RISC-V.
Так получается в идеале по стандарту минимум 7.5мс, не считая время опроса и обработки нажатия самой мышью?
Вы не учитываете неидеальность доставки. Это просто период времени, с которым устройства могут выйти в эфир. Далеко не факт что в данный момент данные будут готовы для передачи, либо хост может быть не готов обслуживать именно это соединение. В случае ошибки доставки, следующая передача только в следующий интервал подключения (если стек строго по спецификации работает). Так что 7.5мс это очень сильно оптимистично и дорого по потреблению (да, несмотря на LE это будет в сумму прилично). Хотя с потреблением как раз можно через Max_Latency решить вопрос: это грубо говоря разрешение не выходить указанное число интервалов в эфир для обмена данными, если этих данных нет.
Различие задержки аудиокодеков
аудио через BLE помимо кодека, использует ещё и кэширование на стороне устройства. Кэш в данном случае решает процедуру задержки сигналов при передаче.
Для справки: реакция человека на внешний раздражитель примерно 200 мс.
Реакцию среднестатистического человека оценивают от 100мс (я участвовал в разработке устройств для фиксации времени реакции на раздражение, в составлении ТЗ принимали участия в том числе и доктора).
для беспроводного МК антенны не хватает, но рядом явно флешка с QUAD-SPI интерфейсом.
Раз есть интрига, то предположил бы что-нибудь редкое. Возможно на Cortex M-33, что-то типа stm32u5 серии. Либо STM32G4/G0 серия, в которых удобно питание разводить
ну как появилась, лет 6 назад судя по шиту появились первые версии этого кабеля. Насчет размеров, несколько спорный момент. Требуется порядка 12-15 мм "чистого" края платы для размещения 6-пиновой версии. Но оно явно меньше версии, которая на подпружинных контактах.
вообще забавно, когда они пишут о "нулевой" стоимости такого "разъема", ведь размещение по краю платы металлизированных полуотверстий все же вносит вклад в общую стоимость изготовления печатной платы.
Но в целом да, идея интересная и вполне себе жизнеспособная, главное понять где её стоит применять, а где лучше обойтись чем-то другим.
у себя заметил, что не зависимого от того какой экран главный, приложение будет запущено на том экране, где находится курсор мыши. Что в десятке, что в одиннадцатой.
из отдельных багов/особенностей:
не всегда убиваются сетевые соединения. Был неприятно удивлен когда VPN вдруг перестал работать из-за занятого порта. Оказалось что все свободные порты ... кончились из-за не убитых процессов. Спасение оказалось в сбросе всех сетевых подключений. Перезагрузка не помогла.
для направляющих места нет, как я вижу. Без них плата не пытается "убежать"? в принципе можно сделать небольшой тюнинг и вклеить их в нижнюю часть прищепки.
Не совсем понял как китайский аналог работает. Он по сути простая прищепка с пого-пинами? Целевая плата просто вставляется в него? По ссылке на Али пока не понятно, вижу версии с разной длиной штырей, но принципа работы не нашел (пока что). Можно немного подробнее?
Разве Segger виноват в том, что программист задает нулевой размер кучи а потом создает экземпляр класса при помощи new, причем там, где это совершенно не нужно?
проблема в другом. Программист явно указал не использовать кучу, но зачем-то решил это делать (забыл например или не знал что нельзя использовать кучу). Segger в данном случае создал кучу сам в некой области памяти. По map файлу это видно было, но нет данных о размере этой кучи.
Но если бы он дал по рукам за такое, сказав что не будет компилировать с динамической памятью при отсутствии явного выделения кучи, цены б ему не было.
Классический ленивый Singleton может так выглядеть
есть много разных вариантов, тот что в моем комментарии выше приведен для примера кода. При желании можно даже такое написать:
Возможно, но тогда какой смысл их вводить и описывать для простых ядер типа М3 и М4? Я согласен с тем что надо понимать когда они действительно работают, а когда нет.
В моем понимании, если у переменной (64 бита например) обращается кто-то из кода и в этот же момент приходит прерывание в котором эта же переменная обновляется, то очень с большой долей вероятности можно получить некорректное значение переменной. Отсюда и возникает необходимость в DMB, которая заставит конвейер выполнить все операции с памятью до этой инструкции:
Причем в тестах, DMB именно что следовало располагать в прерывании таймера. (Я делал составной таймер, правда на nrf52840, но в данном случае речь по то же самое ядро М4. Сложность была в том, что мастер периодически делал коррекцию тика через алгоритм синхронизации. Поэтому в прерывании нужно было считать как целые, так и доли секунд. Проблема была именно в атомарном доступе к переменной, которая средствами языка не решилась. Неделя ушла на то, чтобы научиться получать эту Ситуацию стабильно и примерно месяц тестов чтобы убедится в полноценном решении.
Dsb в этом плане для аппаратных регистров подходит. Она нужна чтобы предыдущая команда была исполнена сразу. В применении к таймера - когда нужно забрать значение и тут же обнулить таймер. Проблемная ситуация: кто-то влезает между этими действиями. Вендор рекомендует после записи делать "volatile void" чтение. Документация на ядро - DSB.
Поэтому польза не только для многоядерных, но и для одиночных контроллер есть.
Edit: да, если параноить дальше, то ещё REX (исклюзианый доступ) надо пользовать. Эти инструкции позволят оценить что при обращении к ячейке памяти никто больше туда не влезал. Но это уже отдельная тема, которую я совсем поверхностно смотрел
Конечно. И статик и volatile вешал.
Я делал свой таймер, с коррекцией типа под мастера. Спасение было в расстановке барьеров.
Вот тут нюанс описывается
https://stackoverflow.com/questions/51029330/dsb-on-arm-cortex-m4-processors
По дизассемблеру - нет. Компилятор использовал от segger, который явно сделан на основе arm clang.
На том же stackoverflow есть несколько тем посвященных dsb и dmb.
А ещё книжка хорошая есть по ядру М3 и М4 от (имя забыл, Янг кажется). Плюс спеку на ядро полезно посмотреть. Там как раз описывается зачем эти инструкции нужны и область их применения.
Проблемы навскидку данного примера кода:
слишком частые прерывания будут в системе;
нарушение атомарности
контроллер 32 бита, переменная 64 -> запись за один такт не возможна. нужно либо ставить критическую секцию, что чревато блокировкой чего-то важного достаточно часто.
и да, на ARM Cortex M критическая секция не гарантирует что инструкции внутри нее будут выполнены в правильном порядке, поэтому нужны ещё барьерные инструкции.
вот этот инкремент так же может быть выполнен уже после выхода из прерывания, если конвейер ядра решит что так быстрее. то есть сначала выйдет из IRQ, затем инкремент.
это не только в документации на ядро описано, но и реальный баг который я неделю отлавливал у себя.
Переводиться, но я бы предпочел оставить так. При использовании инструментов без локализации есть огромное преимущество в лице сообщества, которое часто общается на
буржуйскоманглийском языке, и очень часто возникает ситуация. когда надо что-то изменить в настройках и ... ты не можешь их найти, потому что переводчик решил что правильнее так, а не иначе.По итогу настройка ищется просто методом "тыка". Исхожу из опыта работы с "русским" сервером гитлаб, блендером и те же VS Code.
если для Vim частый запрос "как выйти", то для VS Code достаточно популярный запрос "как вернуть английский язык"
программист-микроконтроллеров обязан уметь работать с тестером и осциллографом, тогда вот такие аппаратные баги не будут на 2 дня выводить из строя программиста. элементарные вещи: убедись что нет КЗ, убедись что сигнал имеет тот уровень, которые ты выставил и так далее. да можно не знать всех тонкостей работы электроники и проектировать аналоговые фильтры на рассыпухе, но элементарные вещи уметь обязательно. не для схемотехников же придуманы логические анализаторы и прочее.
только сейчас осознал, что линейный вход для наушников на телефоне, расположенный снизу как раз таки призван для обеспечения наклона аппарата на нужные 22 с хвостиком градуса вправо. всего лишь нужно найти угловой штекер, чтобы лишний раз не ломать кабель и вот оно счастье!!
При этом не открывая скрипт сборки не узнаешь, какой модуль идет в сборку, а какой нет. Дерево проекта в этом плане имеет хотя бы подсветку активных файлов, которые попадают в данную сборку.
Клик ПКМ в выпадающем меню выбрать "исключить из сборки". При необходимости повторить для нескольких конфигураций.
я не ставлю цель убедить вас в неправильности использования скриптов сборки, пишите и собирайте как вам удобно. вы же упорно ставите цель убедить меня в том, что я неправильно работаю.
p.s. ещё и джуниором обозвали)
Это только ваше мнение и я с ним имею право быть не согласным. Я согласен что скрипты в сборке полезны и более того, без них часто бывает сложно, но ведь скрипты умеют вызывать наверно все IDE как перед компиляций, так и после. Что в принципе я и использую. У меня есть несколько batch файлов, которые делают разные полезные вещи (например, формируют файл для "обновления по воздуху", правильно его именуют, помещают в правильную директорию на сервере и рядом бонусом кладут файл с описанием изменений). Были даже bash-скрипты которые тянули из гита описание тэгов и формировали историю версий.
И мне кажется, вы смешиваете сущности. Есть скрипты окружения (формирование номера версии, перекладывание результатов сборки куда-либо), а есть система сборки (компиляция + линковка). Для общего понимания наверно да, надо уметь собирать с помощью своего скрипта, но в большинстве случае: зачем? Какое преимущество это дает? Если Вася собирает проект в IDE, получает ровно тот же самый hex файл прошивки и тратит на него меньше времени, то зачем руководителю платить Пете, который умеет собирать из makefile, но тратит на весь процесс больше времени? Если при этом Васе ещё и IDE помогает в отладке, то почему бы и не купить ему лицензию, ведь это сэкономит много времени.
Я думаю есть отрасль, где существуют требования по использованию именно makefile (или его аналогов). Но это же не повод обобщать на всех и на все?
Раз уж спросили, отвечу: я использую IDE, Segger Embedded Studio (SES) - так как для Nordic у них свободная лицензия, а последнее время я работаю только с ними. Есть как плюсы, так и минусы. Главный плюс - оно работает из коробки. Опять же, из него запускается Ozone весьма интересный, хоть и специфичный отладчик-профилировщик.
Пробовал Visual Studio с плагином VisualGDB (для зефира, в целом весьма удобно, так как смог прикрутить запуск RTT логгера, что позволило видеть логи сразу в консоле студии), в планах попробовать освоить Visual Studio Code.
Пару раз файлы открывались в Qt Creator, когда надо было строчно поправить по результатам тестов и отдать на повторный прогон устройство.
часто заготовки классов пишу в Notepad++ просто потому что привык к нему.
По итогу могу подтвердить что, все фломастеры разные как на цвет, так и на вкус. Где-то удобно сделано автодополнение кода, где-то подсветка лучше, а где-то есть "странный" статический анализатор кода, который может выдать сообщение "данный код не используется в файлах. Есть вызов функции в файлах ... "
Разве это имеет большое значение в чем писать код сейчас или чем его собирать? Писать в текстовом редакторе и руками вызывать make ? Можно, но для чего, если придумали более удобный инструмент?
сколько лет с ним работаю, проблема возникла только один раз с китайским клоном, в котором слетела прошивка. в остальных случаях проблем не возникло ни разу. Правда я с эклипсом особо не работаю, не понравилось на заре танцы с бубном устраивать для его настройки так сильно, что до сих пор и не пользуюсь. Но это чисто вкусовщина, на мой взгляд эти фломастеры не вкусные.
зато для производство получилось сделать несколько простых скриптов, которые через J-Link автоматически шьют прошивку, серийные номера и калибровочные данные в память. можно ли это сделать другими средствами? наверно можно. Но будет ли проще?
Он может выводить RTT поток с микроконтроллера? это режим трассировки причем двунаправленный, аналог SWO и semihosting, только немного быстрее. J-Link умеет.
хреновый тогда сеньор, ибо сеггер это ещё и J-Link, наиболее часто встречаемый в последнее время программатор-отладчик, который умеет как в ARM, так и в RISC-V.
Вы не учитываете неидеальность доставки. Это просто период времени, с которым устройства могут выйти в эфир. Далеко не факт что в данный момент данные будут готовы для передачи, либо хост может быть не готов обслуживать именно это соединение. В случае ошибки доставки, следующая передача только в следующий интервал подключения (если стек строго по спецификации работает). Так что 7.5мс это очень сильно оптимистично и дорого по потреблению (да, несмотря на LE это будет в сумму прилично). Хотя с потреблением как раз можно через Max_Latency решить вопрос: это грубо говоря разрешение не выходить указанное число интервалов в эфир для обмена данными, если этих данных нет.
аудио через BLE помимо кодека, использует ещё и кэширование на стороне устройства. Кэш в данном случае решает процедуру задержки сигналов при передаче.
Реакцию среднестатистического человека оценивают от 100мс (я участвовал в разработке устройств для фиксации времени реакции на раздражение, в составлении ТЗ принимали участия в том числе и доктора).
для беспроводного МК антенны не хватает, но рядом явно флешка с QUAD-SPI интерфейсом.
Раз есть интрига, то предположил бы что-нибудь редкое. Возможно на Cortex M-33, что-то типа stm32u5 серии. Либо STM32G4/G0 серия, в которых удобно питание разводить
ну как появилась, лет 6 назад судя по шиту появились первые версии этого кабеля. Насчет размеров, несколько спорный момент. Требуется порядка 12-15 мм "чистого" края платы для размещения 6-пиновой версии. Но оно явно меньше версии, которая на подпружинных контактах.
вообще забавно, когда они пишут о "нулевой" стоимости такого "разъема", ведь размещение по краю платы металлизированных полуотверстий все же вносит вклад в общую стоимость изготовления печатной платы.
Но в целом да, идея интересная и вполне себе жизнеспособная, главное понять где её стоит применять, а где лучше обойтись чем-то другим.
Ждем теперь "Bad Apple" на основе этой пасты
у себя заметил, что не зависимого от того какой экран главный, приложение будет запущено на том экране, где находится курсор мыши. Что в десятке, что в одиннадцатой.
из отдельных багов/особенностей:
не всегда убиваются сетевые соединения. Был неприятно удивлен когда VPN вдруг перестал работать из-за занятого порта. Оказалось что все свободные порты ... кончились из-за не убитых процессов. Спасение оказалось в сбросе всех сетевых подключений. Перезагрузка не помогла.
для направляющих места нет, как я вижу. Без них плата не пытается "убежать"? в принципе можно сделать небольшой тюнинг и вклеить их в нижнюю часть прищепки.
пойду тоже закажу парочку))
Не совсем понял как китайский аналог работает. Он по сути простая прищепка с пого-пинами? Целевая плата просто вставляется в него? По ссылке на Али пока не понятно, вижу версии с разной длиной штырей, но принципа работы не нашел (пока что). Можно немного подробнее?
проблема в другом. Программист явно указал не использовать кучу, но зачем-то решил это делать (забыл например или не знал что нельзя использовать кучу). Segger в данном случае создал кучу сам в некой области памяти. По map файлу это видно было, но нет данных о размере этой кучи.
Но если бы он дал по рукам за такое, сказав что не будет компилировать с динамической памятью при отсутствии явного выделения кучи, цены б ему не было.
есть много разных вариантов, тот что в моем комментарии выше приведен для примера кода. При желании можно даже такое написать: