Согласен, заглавная картинка бесит. Особенно во время загрузки страницы, когда интернет не очень быстр. Полтора мегабайта бесполезной информации. Фото, сохранённое в png, сжимается плохо. Гораздо лучше использовать jpg. При сравнимом качестве размер файла меньше раз в 15.То же самое касается Безмятежности и инсталляции "Windows Update"
Требования ISO26262 требуют автосборки и DevOps. Из-за этого надо самимписать скрипты сборки. Вот так и приходится самим писать GNU make скрипты. Понимаете?
Вот она истинная причина хейта "Сборки с Помощью Eclipse GCC Плагинов"
Да, volatile так же гарантирует атомарную запись и чтение переменных типа long независимо от разрядности архитектуры процессоры, где он не может атомарно работать с такими размерностями операндов.
Нет, volatile не гарантирует атомарность. Чтение/запись переменной с размером, не превышающим разрядность архитектуры, обычно обеспечивается на аппаратном уровне (это один цикл доступа к памяти). Чтение/запись long на архитектуре например AVR не будет атомарным даже при использовании ключевого слова volatile. Про заблуждения о volatile можно прочитать например здесь http://we.easyelectronics.ru/Soft/skolzkaya-dorozhka-dlya-poklonnikov-volatile.html
J-link V9 это просто подарок для эмбеддеров. Легко ремонтируется. Легко восстанавливается прошивка. Поддерживает кучу популярных ядер. Клон доступный и недорогой. Для гурманов в интернете есть несколько открытых проектов клонов, в том числе под USB Type C и с гальванической развязкой. Есть J-Link Server для линукса, лёгким движением руки при помощи недорогого одноплатника получаем отладчик с гальванической развязкой и подключением через Ethernet. Единственный недостаток - не поддерживается производителем с 2021 года, новых ядер там уже не будет
Второй главный недостаток - это наличие "графических" средств конфигурации и генерации шаблонных проектов. Что существенно снижает порог входа, но не делает микроконтроллер проще, и не отменяет необходимость чтения даташитов. После изучения экосистемы STM32 работа с любым контроллером этого семейства не вызывает особой сложности. А познание RP2040 пригодится только для работы с RP2040
Профессионал одинаково быстро напишет программу в любой среде. Некомпетентный инженер легко спустит разработку под откос независимо от используемого инструмента. Проблема не в инструменте, проблема в людях.
Кажется, аргументы закончились, и обсуждение пошло по второму кругу... Засим откланиваюсь, всем удачного кодинга
Совершенно верно! Если поставлена задача завалить проект, то с этим справится любой (не)специалист. И для этого не обязательно использовать чистый мейк, Eclipse, IAR, KEIL etc. Кстати, в моей практике я не встречал проектов, убитых использованием "GUI-IDE". Обычно причина либо экономическая (изделие не нашло спроса), либо схемотехническая, либо устаревание и снятие с производства важных компонентов.
Если в Вашем проекте тыща вариантов сборок - то make, без вариантов. Если нужна всего пара конфигов, debug + release - то почему бы и нет. Для конкретной задачи выбираем наиболее удобный инструмент
Ошибка сборка с ключом FMT_BUILTIN_TYPES=0 исправлена (коммит от 28 сентября). Сейчас, если не используется форматирование плавучки, либа в моём проекте добавляет всего 6 кб кода. Как я понял, в режиме FMT_BUILTIN_TYPES=0 линкеру разрешается выкинуть код неиспользуемых форматтеров.
Можно подвести предварительные итоги. Библиотека на Кортексе-М работает. Но есть нюансы.
Код fmt в режиме Os+LTO занимает 25кб. Практически половина объёма уходит на форматтер чисел с плавающей запятой. Было бы полезно уметь опционально отключать поддержку плавучки. Ключ FMT_BUILTIN_TYPES=0 также должен уменьшить размер кода. Предположительно он удаляет форматтеры, которые реально не используются в пользовательском коде. Сейчас (на 23.09) сборка кода с параметром FMT_BUILTIN_TYPES=0 завершается ошибкой.
Собственный аллокатор для fmt::basic_memory_buffer конечно полезен, но только если в проекте используется исключительно constexpr-форматирование. Реалтайм-функции массово используют std::basic_string и std::string, которые тянут из стандартной библиотеки std::allocator. И экономия от fmt::allocator сводится к нулю.
Обработка нескольких строк в моём проекте при помощи fmt выполняется в 3 раза дольше, чем printf (не библиотечный, одна из типовых реализаций).
Если микроконтроллер жирный и производительный, а проект сложный с большим количеством форматных строк, то fmt будет вполне уместна. А для небольших проектов используйте обычный printf.
Параметр FMT_BUILTIN_TYPES появился совсем недавно, похоже, что это новая и ещё сырая фича, код на гитхабе обновляется каждый день. Нужно ждать выхода релиза.
Давно хотел натянуть fmt на контроллер STM32. Эта статься простимулировала моё желание.
Итого: простая форматная строка с радостью скушала 30 кБ флэша. И это в сборке с ключами Os+LTO. Читаем содержимое файлов lst и map. Много думаем. Оказалось, что в бинарник попало много лишнего кода из библиотеки stl (обработчики ошибок и бэд-аллокаторы из заголовков <new>, <stdexcept>, <system_error>). Вырезал лишний код (связанный с std::system_error, std::error_code и т.п.) - и вуаля, compile-time форматированная строка прибавила бинарнику всего лишь пару десятков байт. Причём не важно, с какими ключами оптимизации собирается код. Consteval одинаково хорошо работает и с O0, и с Os.
Пока не разобрался с параметром FMT_BUILTIN_TYPES. Если встроенные форматтеры отключить (указать нуль), то код действительно уменьшается. Библиотека пытается вызвать кастомный форматтер для (почти) всех параметров, но в указателе custom.format (см. например метод format_custom класса basic_format_arg) находится мусор, и программа предсказуемо падает. Проблема в том, что код собирается успешно, и компилятор не выдаёт ошибок. Пока не понял, почему это происходит. Может не хватает инстанцирования какого-либо шаблона, может мои кривые руки что-то сломали. Разобраться в фарше из шаблонов, на которых написана fmt, тот ещё квест
Осторожнее с таким кодом. Как было сказано в комментариях к этой статье, __set_MSP() - это зло. Если вдруг переменная Jump_To_Application хранится в стеке, то после set_MSP она превратится в тыкву. И это действительно так, я натыкался на эту проблему. Шаманство с отключением оптимизаций кода помогает, но это некрасиво и ненадёжно. Проверенное решение (GCC) такое:
Компилятор с любыми флагами оптимизациями предварительно загрузит значение в регистр %1, затем загрузит указатель стека, и затем перейдёт по адресу из регистра %1. Ассемблерная вставка не оптимизируется, т.е. в любом случае сначала выполнится команда msr, затем bx. Например, O0:
Мы сравниваем тёплое с мягким, путаем причину и следствие. Профессионал одинаково быстро соберёт прошивку для перекладывания байт в любой IDE (или без неё), но в привычной среде - чуть быстрее. И если потребуется "этот ваш CI/DI настроить", то возьмёт наиболее подходящий для этого инструмент. В стартапах собираются профессионалы, чтобы заработать деньги на какой-либо новой технологии. Слабые специалисты там не задерживаются, иначе стартап благополучно разваливается. А профи часто рождаются в мире линукса. Там знать Make, CMake, etc жизненно необходимо. В типичной же русской компании многое зависит от корпоративной культуры (или её отсутствия). Люди работают за зарплату. Там обычно торопиться некуда, можно не спеша перекладывать байты годами. И в чём это делать - в ИАРе или в командной строке - совсем не важно. Большая проблема всех IDE, как было вскользь отмечено в статье, это снижение необходимой квалификации программиста для выполнения конкретных задач. Прошивки создаются в калокубе как пирожки, а что там внутри, к сожалению мало кого волнует. Если пересадить этих чудо-программистов на чистый мейк - это принципиально ничего не изменит.
Я аппаратный протокол интерфейса SWD (однопроводный и двухпроводный) расковырял, добавил поддержку ch32v003 и 20x/30x серий в свой программатор. Ничего сложного там нет, но много кропотливой работы... Если будут технические вопросы, можно в личку. Но не думаю, что это кому-то нужно. Недорогой WCH-Link нормально решает задачи программирования/отладки.
2) jlink на оригинальных дровах действительно работает шустро. Гораздо шустрее, чем jlink через OpenOCD. Универсальность OpenOCD - это его сила и слабость.
3) Я тоже столкнулся с этой проблемой. Даже обращался в поддержку производителя. На удивление, мне ответили, но как часто бывает - для решения проблемы предлагают обновиться на свежую студию и перезагрузить комп.
Проблема находится в кастомной сборке OpenOCD от WCH. Во-первых, контроллеры CH32 подключаются к отладчику через проприетарный интерфейс SWD. Этот интерфейс поддерживается только отладчиком серии WCH-Link . Во-вторых, протокол управления отладчиком WCH-Link тоже закрытый. Поэтому для работы с контроллерами CH32 нужна доработанная сборка OpenOCD. Программисты из WCH не сильно заморачивались, и реализовали процедуру стирания памяти Flash примерно так:
static int ch32vx_erase(struct flash_bank *bank, int first, int last)
{
if(noloadflag)
return ERROR_OK;
wlink_reset();
int ret = wlink_erase();
target_halt(bank->target);
if (ret)
return ERROR_OK;
else
return ERROR_FAIL;
}
Т.е. адрес и размер секции памяти для стирания игнорируется, и любой старт отладки из OpenOCD полностью сносит память.
Исходники можно подсмотреть например здесь; они явно не последние, но в свежей сборке MounRiver-Студии проблема всё ещё актуальна
Ещё добавлю с копилку достоинств - как средство избавления от ХалоКубо/Кейло/Иаро-зависимости. Перейти на GCC и чистый мейк (при реальной необходимости) с embed-cdt плагина гораздо проще, чем с Иара.
Можно бесконечно спорить, франкенштейн это или нет, F5 или не F5, недостаток аргументов прикрывая бессмысленными картинками. Но суть моего комментария в другом, повторюсь: Каждый инструмент предназначен для своих задач. Нельзя одним инструментом покрыть все потребности любого проекта. Если инструмент не подходит - пожалуйста, используйте другой. Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно. Для других разработчиков там найдётся масса достоинств, - далеко не все в промышленности используют Jenkins/CI/CD. Если бы Вы сказали, "Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь Для Меня" и что "Eclipse c ARM плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
Согласен, заглавная картинка бесит. Особенно во время загрузки страницы, когда интернет не очень быстр. Полтора мегабайта бесполезной информации. Фото, сохранённое в png, сжимается плохо. Гораздо лучше использовать jpg. При сравнимом качестве размер файла меньше раз в 15.То же самое касается Безмятежности и инсталляции "Windows Update"
Вот она истинная причина хейта "Сборки с Помощью Eclipse GCC Плагинов"
Нет, volatile не гарантирует атомарность. Чтение/запись переменной с размером, не превышающим разрядность архитектуры, обычно обеспечивается на аппаратном уровне (это один цикл доступа к памяти). Чтение/запись long на архитектуре например AVR не будет атомарным даже при использовании ключевого слова volatile. Про заблуждения о volatile можно прочитать например здесь http://we.easyelectronics.ru/Soft/skolzkaya-dorozhka-dlya-poklonnikov-volatile.html
J-link V9 это просто подарок для эмбеддеров. Легко ремонтируется. Легко восстанавливается прошивка. Поддерживает кучу популярных ядер. Клон доступный и недорогой. Для гурманов в интернете есть несколько открытых проектов клонов, в том числе под USB Type C и с гальванической развязкой. Есть J-Link Server для линукса, лёгким движением руки при помощи недорогого одноплатника получаем отладчик с гальванической развязкой и подключением через Ethernet. Единственный недостаток - не поддерживается производителем с 2021 года, новых ядер там уже не будет
Только тех, кто любит труд, октябрятами зовут
Второй главный недостаток - это наличие "графических" средств конфигурации и генерации шаблонных проектов. Что существенно снижает порог входа, но не делает микроконтроллер проще, и не отменяет необходимость чтения даташитов. После изучения экосистемы STM32 работа с любым контроллером этого семейства не вызывает особой сложности. А познание RP2040 пригодится только для работы с RP2040
Профессионал одинаково быстро напишет программу в любой среде. Некомпетентный инженер легко спустит разработку под откос независимо от используемого инструмента. Проблема не в инструменте, проблема в людях.
Кажется, аргументы закончились, и обсуждение пошло по второму кругу... Засим откланиваюсь, всем удачного кодинга
Совершенно верно! Если поставлена задача завалить проект, то с этим справится любой (не)специалист. И для этого не обязательно использовать чистый мейк, Eclipse, IAR, KEIL etc. Кстати, в моей практике я не встречал проектов, убитых использованием "GUI-IDE". Обычно причина либо экономическая (изделие не нашло спроса), либо схемотехническая, либо устаревание и снятие с производства важных компонентов.
Если в Вашем проекте тыща вариантов сборок - то make, без вариантов. Если нужна всего пара конфигов, debug + release - то почему бы и нет. Для конкретной задачи выбираем наиболее удобный инструмент
Ошибка сборка с ключом FMT_BUILTIN_TYPES=0 исправлена (коммит от 28 сентября). Сейчас, если не используется форматирование плавучки, либа в моём проекте добавляет всего 6 кб кода. Как я понял, в режиме FMT_BUILTIN_TYPES=0 линкеру разрешается выкинуть код неиспользуемых форматтеров.
Можно подвести предварительные итоги. Библиотека на Кортексе-М работает. Но есть нюансы.
Код fmt в режиме Os+LTO занимает 25кб. Практически половина объёма уходит на форматтер чисел с плавающей запятой. Было бы полезно уметь опционально отключать поддержку плавучки. Ключ FMT_BUILTIN_TYPES=0 также должен уменьшить размер кода. Предположительно он удаляет форматтеры, которые реально не используются в пользовательском коде. Сейчас (на 23.09) сборка кода с параметром FMT_BUILTIN_TYPES=0 завершается ошибкой.
Собственный аллокатор для fmt::basic_memory_buffer конечно полезен, но только если в проекте используется исключительно constexpr-форматирование. Реалтайм-функции массово используют std::basic_string и std::string, которые тянут из стандартной библиотеки std::allocator. И экономия от fmt::allocator сводится к нулю.
Обработка нескольких строк в моём проекте при помощи fmt выполняется в 3 раза дольше, чем printf (не библиотечный, одна из типовых реализаций).
Если микроконтроллер жирный и производительный, а проект сложный с большим количеством форматных строк, то fmt будет вполне уместна. А для небольших проектов используйте обычный printf.
Параметр FMT_BUILTIN_TYPES появился совсем недавно, похоже, что это новая и ещё сырая фича, код на гитхабе обновляется каждый день. Нужно ждать выхода релиза.
Давно хотел натянуть fmt на контроллер STM32. Эта статься простимулировала моё желание.
Итого: простая форматная строка с радостью скушала 30 кБ флэша. И это в сборке с ключами Os+LTO. Читаем содержимое файлов lst и map. Много думаем. Оказалось, что в бинарник попало много лишнего кода из библиотеки stl (обработчики ошибок и бэд-аллокаторы из заголовков <new>, <stdexcept>, <system_error>). Вырезал лишний код (связанный с std::system_error, std::error_code и т.п.) - и вуаля, compile-time форматированная строка прибавила бинарнику всего лишь пару десятков байт. Причём не важно, с какими ключами оптимизации собирается код. Consteval одинаково хорошо работает и с O0, и с Os.
Пока не разобрался с параметром FMT_BUILTIN_TYPES. Если встроенные форматтеры отключить (указать нуль), то код действительно уменьшается. Библиотека пытается вызвать кастомный форматтер для (почти) всех параметров, но в указателе custom.format (см. например метод format_custom класса basic_format_arg) находится мусор, и программа предсказуемо падает. Проблема в том, что код собирается успешно, и компилятор не выдаёт ошибок. Пока не понял, почему это происходит. Может не хватает инстанцирования какого-либо шаблона, может мои кривые руки что-то сломали. Разобраться в фарше из шаблонов, на которых написана fmt, тот ещё квест
Осторожнее с таким кодом. Как было сказано в комментариях к этой статье, __set_MSP() - это зло. Если вдруг переменная Jump_To_Application хранится в стеке, то после set_MSP она превратится в тыкву. И это действительно так, я натыкался на эту проблему. Шаманство с отключением оптимизаций кода помогает, но это некрасиво и ненадёжно. Проверенное решение (GCC) такое:
Компилятор с любыми флагами оптимизациями предварительно загрузит значение в регистр %1, затем загрузит указатель стека, и затем перейдёт по адресу из регистра %1. Ассемблерная вставка не оптимизируется, т.е. в любом случае сначала выполнится команда msr, затем bx.
Например, O0:
Или Os+LTO:
Практически ничего не поменялось, только использованы другие регистры.
Речь вероятно об АЧХ антенны. Чем меньше добротность резонаторной системы, тем более гладкая (без резких скачков) АЧХ, и тем шире полоса пропускания.
Мы сравниваем тёплое с мягким, путаем причину и следствие. Профессионал одинаково быстро соберёт прошивку для перекладывания байт в любой IDE (или без неё), но в привычной среде - чуть быстрее. И если потребуется "этот ваш CI/DI настроить", то возьмёт наиболее подходящий для этого инструмент.
В стартапах собираются профессионалы, чтобы заработать деньги на какой-либо новой технологии. Слабые специалисты там не задерживаются, иначе стартап благополучно разваливается. А профи часто рождаются в мире линукса. Там знать Make, CMake, etc жизненно необходимо.
В типичной же русской компании многое зависит от корпоративной культуры (или её отсутствия). Люди работают за зарплату. Там обычно торопиться некуда, можно не спеша перекладывать байты годами. И в чём это делать - в ИАРе или в командной строке - совсем не важно.
Большая проблема всех IDE, как было вскользь отмечено в статье, это снижение необходимой квалификации программиста для выполнения конкретных задач. Прошивки создаются в калокубе как пирожки, а что там внутри, к сожалению мало кого волнует. Если пересадить этих чудо-программистов на чистый мейк - это принципиально ничего не изменит.
Я аппаратный протокол интерфейса SWD (однопроводный и двухпроводный) расковырял, добавил поддержку ch32v003 и 20x/30x серий в свой программатор. Ничего сложного там нет, но много кропотливой работы... Если будут технические вопросы, можно в личку. Но не думаю, что это кому-то нужно. Недорогой WCH-Link нормально решает задачи программирования/отладки.
2) jlink на оригинальных дровах действительно работает шустро. Гораздо шустрее, чем jlink через OpenOCD. Универсальность OpenOCD - это его сила и слабость.
3) Я тоже столкнулся с этой проблемой. Даже обращался в поддержку производителя. На удивление, мне ответили, но как часто бывает - для решения проблемы предлагают обновиться на свежую студию и перезагрузить комп.
Проблема находится в кастомной сборке OpenOCD от WCH. Во-первых, контроллеры CH32 подключаются к отладчику через проприетарный интерфейс SWD. Этот интерфейс поддерживается только отладчиком серии WCH-Link . Во-вторых, протокол управления отладчиком WCH-Link тоже закрытый. Поэтому для работы с контроллерами CH32 нужна доработанная сборка OpenOCD. Программисты из WCH не сильно заморачивались, и реализовали процедуру стирания памяти Flash примерно так:
Т.е. адрес и размер секции памяти для стирания игнорируется, и любой старт отладки из OpenOCD полностью сносит память.
Исходники можно подсмотреть например здесь; они явно не последние, но в свежей сборке MounRiver-Студии проблема всё ещё актуальна
https://github.com/kprasadvnsi/riscv-openocd-wch
Ещё добавлю с копилку достоинств - как средство избавления от ХалоКубо/Кейло/Иаро-зависимости. Перейти на GCC и чистый мейк (при реальной необходимости) с embed-cdt плагина гораздо проще, чем с Иара.
Можно бесконечно спорить, франкенштейн это или нет, F5 или не F5, недостаток аргументов прикрывая бессмысленными картинками. Но суть моего комментария в другом, повторюсь:
Каждый инструмент предназначен для своих задач. Нельзя одним инструментом покрыть все потребности любого проекта. Если инструмент не подходит - пожалуйста, используйте другой. Но категорично говорить, что "Достоинства сборки из-под Eclipse c ARM плагинами - Отсутствуют.." я считаю неправильно. Для других разработчиков там найдётся масса достоинств, - далеко не все в промышленности используют Jenkins/CI/CD. Если бы Вы сказали, "Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь Для Меня" и что "Eclipse c ARM плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.