Профессионал одинаково быстро напишет программу в любой среде. Некомпетентный инженер легко спустит разработку под откос независимо от используемого инструмента. Проблема не в инструменте, проблема в людях.
Кажется, аргументы закончились, и обсуждение пошло по второму кругу... Засим откланиваюсь, всем удачного кодинга
Совершенно верно! Если поставлена задача завалить проект, то с этим справится любой (не)специалист. И для этого не обязательно использовать чистый мейк, 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 плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован cproject, и чем это мешает? Он не предназначен для диффа и ручного редактирования. Ленивые юзеры получают франкенштейнов. Но это их проблемы, а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение. Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает. Если этого инструмента недостаточно - пожалуйста, пользуйтесь make-файлом. На make/cmake действительно можно организовать любую монструозную сборку, см. например ESP32. Да, и докажите ещё любителям ХалоКуба, почему мышиная возня это плохо. Мы то понимаем, почему. Но миллионы людей тыкают мышкой, и вполне довольны, задачи решаются, программы работают.
Ох уж эти картинки... На 100 с небольшим килобайт текста - картинок на 18 мегабайт. Формат png хорошо жмёт однотонные картинки, не если есть градиент - беда. Если перевести картинки из статьи в обычный jpeg, страница похудеет в два раза (на 10 Мб) без заметной потери качества. Или - формат webp - вообще показывает чудеса, размер файла ещё раза в 2-3 меньше. Уважаемые авторы! Не у всех есть быстрый интернет. Пожалуйста, берегите наш трафик, время и нервы. А за интересные статьи - всем спасибо.
Нет такого понятия "чувствительность антенны". Говорят про чувствительность приёмника, а по сути - это способность демодулировать сигнал с заданным выходным BER при заданном входном S/N. Плохая антенна (т.е. с низким Ку) будет одинаково плохо и принимать, и передавать сигнал. "Односторонняя" связь в первую очередь обусловлена схемотехникой приёмопередатчика базовой станции. Там обычно нет проблем с электричеством, поэтому можно использовать мощный передатчик и высококачественный (высокодинамичный высокоизбирательный) приёмник. Например, GSM: у мобильного аппарата излучаемая мощность 1-2 Вт, а базовая станция передаёт десятки ватт. Вот и получаем "однонаправленность". Если взять две антенны, одна хорошая, другая плохая, то при прочих равных условиях бюджет линии что в одну, что в другую сторону будет одинаков. "Хорошая дорогая" [направленная] антенна действительно может улучшить приём, но только за счёт подавления помех с побочных направлений.
Было дело, писал загрузчик. Собственный протокол, интерфейс USB, память под загрузчик 16 кб. С оптимизацией Os + LTO в указанную память загрузчик не влезал, не хватало буквально сотни байт. Изучая ассемблерный листинг обнаружил функции 64-битной арифметики. Сюрприз был спрятан в хал-библиотеке stm32f4xx_hal_rcc.c:
Небольшая доработка кода, и вуаля - полкилобайта памяти свободно. В моём случае функция вызывается однократно, просадки производительности нет, но память - ценный ресурс. Поэтому читать и понимать map/asm/lst файлы действительно бывает очень полезно.
Этот прикол связан с оптимизацией производства и маркетингом, уже неоднократно обсуждалось. В соседних моделях микроконтроллера STM32 часто используются одинаковые кристаллы. У младших чипов тестируется только часть FLASH-памяти. Что существенно экономит время производства, и поэтому чипы получаются дешевле. Например, в STM32F103C8T6, что массово устанавливаются в голубую таблетку, вполне можно записать 128 кБ. Без гарантий, естественно. И наоборот, в китайских клонах, например в CKS32F103C8T6, честные 64 кБ.
Профессионал одинаково быстро напишет программу в любой среде. Некомпетентный инженер легко спустит разработку под откос независимо от используемого инструмента. Проблема не в инструменте, проблема в людях.
Кажется, аргументы закончились, и обсуждение пошло по второму кругу... Засим откланиваюсь, всем удачного кодинга
Совершенно верно! Если поставлена задача завалить проект, то с этим справится любой (не)специалист. И для этого не обязательно использовать чистый мейк, 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 плагинами не подходит под мои задачи потому что ..." - пожалуйста, это Ваше мнение, мы бы поняли.
Абсолютно не согласен. Вот все эти минусы как-то притянуты за уши. Ну не отсортирован cproject, и чем это мешает? Он не предназначен для диффа и ручного редактирования. Ленивые юзеры получают франкенштейнов. Но это их проблемы, а если они начнут писать make вручную, их проекты вообще перестанут собираться. Папки и отдельные файлы вполне можно исключить из билда (да, через контекстное меню). И нажать F5 (refresh) ну ни разу не проблема. А передавать пути к проекту в IDE через bat-скрипт - так это очень странное решение.
Каждый инструмент предназначен для своих задач. И Eclipse + embedcdt многие задачи по сборке проекта хорошо решает. Если этого инструмента недостаточно - пожалуйста, пользуйтесь make-файлом. На make/cmake действительно можно организовать любую монструозную сборку, см. например ESP32.
Да, и докажите ещё любителям ХалоКуба, почему мышиная возня это плохо. Мы то понимаем, почему. Но миллионы людей тыкают мышкой, и вполне довольны, задачи решаются, программы работают.
Ох уж эти картинки... На 100 с небольшим килобайт текста - картинок на 18 мегабайт. Формат png хорошо жмёт однотонные картинки, не если есть градиент - беда. Если перевести картинки из статьи в обычный jpeg, страница похудеет в два раза (на 10 Мб) без заметной потери качества. Или - формат webp - вообще показывает чудеса, размер файла ещё раза в 2-3 меньше. Уважаемые авторы! Не у всех есть быстрый интернет. Пожалуйста, берегите наш трафик, время и нервы. А за интересные статьи - всем спасибо.
Нет такого понятия "чувствительность антенны". Говорят про чувствительность приёмника, а по сути - это способность демодулировать сигнал с заданным выходным BER при заданном входном S/N. Плохая антенна (т.е. с низким Ку) будет одинаково плохо и принимать, и передавать сигнал. "Односторонняя" связь в первую очередь обусловлена схемотехникой приёмопередатчика базовой станции. Там обычно нет проблем с электричеством, поэтому можно использовать мощный передатчик и высококачественный (высокодинамичный высокоизбирательный) приёмник. Например, GSM: у мобильного аппарата излучаемая мощность 1-2 Вт, а базовая станция передаёт десятки ватт. Вот и получаем "однонаправленность". Если взять две антенны, одна хорошая, другая плохая, то при прочих равных условиях бюджет линии что в одну, что в другую сторону будет одинаков.
"Хорошая дорогая" [направленная] антенна действительно может улучшить приём, но только за счёт подавления помех с побочных направлений.
Было дело, писал загрузчик. Собственный протокол, интерфейс USB, память под загрузчик 16 кб. С оптимизацией Os + LTO в указанную память загрузчик не влезал, не хватало буквально сотни байт. Изучая ассемблерный листинг обнаружил функции 64-битной арифметики. Сюрприз был спрятан в хал-библиотеке stm32f4xx_hal_rcc.c:
Небольшая доработка кода, и вуаля - полкилобайта памяти свободно. В моём случае функция вызывается однократно, просадки производительности нет, но память - ценный ресурс. Поэтому читать и понимать map/asm/lst файлы действительно бывает очень полезно.
Этот прикол связан с оптимизацией производства и маркетингом, уже неоднократно обсуждалось. В соседних моделях микроконтроллера STM32 часто используются одинаковые кристаллы. У младших чипов тестируется только часть FLASH-памяти. Что существенно экономит время производства, и поэтому чипы получаются дешевле. Например, в STM32F103C8T6, что массово устанавливаются в голубую таблетку, вполне можно записать 128 кБ. Без гарантий, естественно. И наоборот, в китайских клонах, например в CKS32F103C8T6, честные 64 кБ.