Абсолютно согласен. Для одного проекта взял штук 20 датчиков что-то типа DTH11. Треть показывала нулевую влажность, треть выдавала левые цифры, и только оставшиеся работали более-менее адекватно. Причём по показаниям температуры проблем не было
Использую J-Link. Скорость работы уверенно побеждает более высокую стоимость (речь естественно про клон). Быстрее загружает, быстрее шагает по сравнению с ST-Link, и тем более, по сравнению с ST-Link через OpenOCD. ST-Link, перепрошитый в J-Link, тоже заметно шустрее
Наверное вопрос про T90P? Он мощнее, однако вся эта мощность используется только на старте. Плюс цветной дисплей. А вот T80/T80P слегка тоньше, в руке лежит удобнее. Если паять паз в пять лет, то без разницы
Ещё один неочевидный момент. Входы ОУ иногда защищаются встречно-параллельными диодами. В таком случае максимально допустимое дифференциальное напряжение между входами не должно превышать 0,7В (что указывается в даташите). Если напряжение больше - открывается диод, ток источника сигнала втекает/вытекает через второй вход. Компараторы же рассчитаны на работу с большим дифференциальным напряжением, достигающим напряжение питания.
Согласен, заглавная картинка бесит. Особенно во время загрузки страницы, когда интернет не очень быстр. Полтора мегабайта бесполезной информации. Фото, сохранённое в 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, как было вскользь отмечено в статье, это снижение необходимой квалификации программиста для выполнения конкретных задач. Прошивки создаются в калокубе как пирожки, а что там внутри, к сожалению мало кого волнует. Если пересадить этих чудо-программистов на чистый мейк - это принципиально ничего не изменит.
Абсолютно согласен. Для одного проекта взял штук 20 датчиков что-то типа DTH11. Треть показывала нулевую влажность, треть выдавала левые цифры, и только оставшиеся работали более-менее адекватно. Причём по показаниям температуры проблем не было
Использую J-Link. Скорость работы уверенно побеждает более высокую стоимость (речь естественно про клон). Быстрее загружает, быстрее шагает по сравнению с ST-Link, и тем более, по сравнению с ST-Link через OpenOCD. ST-Link, перепрошитый в J-Link, тоже заметно шустрее
Наверное вопрос про T90P? Он мощнее, однако вся эта мощность используется только на старте. Плюс цветной дисплей. А вот T80/T80P слегка тоньше, в руке лежит удобнее. Если паять паз в пять лет, то без разницы
Ещё один неочевидный момент. Входы ОУ иногда защищаются встречно-параллельными диодами. В таком случае максимально допустимое дифференциальное напряжение между входами не должно превышать 0,7В (что указывается в даташите). Если напряжение больше - открывается диод, ток источника сигнала втекает/вытекает через второй вход. Компараторы же рассчитаны на работу с большим дифференциальным напряжением, достигающим напряжение питания.
Согласен, заглавная картинка бесит. Особенно во время загрузки страницы, когда интернет не очень быстр. Полтора мегабайта бесполезной информации. Фото, сохранённое в 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, как было вскользь отмечено в статье, это снижение необходимой квалификации программиста для выполнения конкретных задач. Прошивки создаются в калокубе как пирожки, а что там внутри, к сожалению мало кого волнует. Если пересадить этих чудо-программистов на чистый мейк - это принципиально ничего не изменит.