ARV писал(а): Ср июл 01, 2026 14:54:48
я ровно то же самое слышал, когда агитировал в темах AVR использовать printf и sprintf для вывода хоть куда - от ЖКИ до 7-сегментников. дескать, оверхед - ужас! а я применял, и буду применять. и сейчас второе, что я сделал на STM32, так это скрыл низ USARTа за вызовами printf-a (с небольшим линейным буфером и DMA). и ваши страшилки меня не пугают, в МК 64К флеша.
и микроскопом можно гвозди забивать, что тут поделаешь...
JackSmith писал(а): Ср июл 01, 2026 15:46:36
и микроскопом можно гвозди забивать
гвоздь, забитый микроскопом дуржится лучше, чем закрученный отверткой
а если по смыслу написанного, то вы любите код и МК, когда пишите программы, а я люблю себя и заказчика. поэтому для меня printf - это отлично, а для вас - ужос
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
я ничего не имею против printf(), но предпочитаю пользоваться собственной реализаций, из-за предсказуемости. и да, я тоже ее использую ее для печати на дисплеях. а фразу про эту функцию отнес в "хвалебному примитивизму". поэтому и ответил микроскопом. кого вы хотели удивить? вызвать восхищение? жалость? (нужное подчернуть)
JackSmith писал(а): Ср июл 01, 2026 16:15:55
но предпочитаю пользоваться собственной реализаций, из-за предсказуемости
но это же неразумно! автомобилем-то вы пользуетесь готовым, а не самодельным. и телек смотрите готовый, и даже смартфон не сами сделали. почему такое недоверие к printf на фоне доверия к куда большим и опасным системам?!
такое ощущение, что большинство "умных и правильных" просто категорически не допускают мысли, что их решения - не единственные приемлемые! иначе говоря, есть только два варианта кода: сделанный ими и неправильный.
но это не так на самом-то деле.
и printf был мной упомянут не в контексте самопохвалы, а в контексте отсутствия паники из-за оверхеда и овер-чего-то там из-за "лишних" тактов. следите за контекстом, однако
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
КРАМ писал(а): Ср июл 01, 2026 12:50:57
Вы не о том. Речь шла про периферию, а не про какой нибудь копроцессор реализующий дополнительный набор команд ядра.
Компилятор ничего не знает про периферию.
Оно смежное. Я вот подключал либу плавающей точки к проектам. Ничего дополнительно не настраивал. Так вот, код на МК с наличием FPU сильно компактнее, чем на МК без FPU. Т.е., либа через ключи либо использует аппаратный блок, либо добавляет программную эмуляцию. То же самое происходит и с другим оборудованием. Несомненно, и у этого есть свой предел, который в том числе закладывается самим писателем либы.
ARV писал(а): Ср июл 01, 2026 16:20:40
почему такое недоверие к printf
много букв. но есть и другие аргументы. размер. что бы срочно не пришлось переписывать printf() на собственную реализацию, когда крошечных 64 КБ перестанет хватать. потому-то когда начинаешь делать что-то "срочняком", времени на отлов багов и вылизывания кода уже не остается.
ARV писал(а): Ср июл 01, 2026 14:49:14
существует огромное колчество задач, где схема вообще на последнем месте, а первична - логика управления ею.
А я это и не отрицал. Я утверждаю, что ваши методы работы с МК являются тупиковыми в смысле развития компетенций. Но если вам оно и не надо, то это ваш выбор и он соответствует вашим амбициям. Будете писать код за еду. Для выхода на следующий уровень придется учиться с самого начала.
ARV писал(а): Ср июл 01, 2026 14:49:14вы каждое высказывание трактуете без контекста, предшествующего ему. к оверхеду условная компиляция не относится, она относится к единому уинтерфейсу верхнего уровня для РАЗНЫХ перифериных устройств сходного назначения. именно универсальность такого интерфейса даёт мне основание утверждать, что глубоко вникать в тонкости "нижней" реализации необходимо далеко не всегда.
И тут я не утверждал про "всегда". Читайте предыдущий коммент - важна готовность усложнить задачи, если вы претендуете на рост. Привычка работать с готовыми кубиками противоречит росту. Люди получают высшее образование для того, чтобы была перспектива. А так - подавляющий объем работы любого инженера не требует высшего образования. Но дьявол в мелочах...
ARV писал(а): Ср июл 01, 2026 14:49:14тот факт, что вы не изобрели собственный DSP, а тупо взяли готовое, вы, конечно, в качестве возражения не примите? и язык Си тоже не мной изобретен, и даже stdlib! ужас! я вообще ничего нового не могу сделать - ведь оно состоит из уже сделанного кем-то когда-то!!! возвращаясь к теме УНИВЕРСАЛЬНЫХ методов - вы занимаетесь плагиатом, т.к.вся теория DSP-обработки не вами придумана!!!
Феноменальная глупость.
Теория сигналов - это инструмент позволяющий синтезировать ЛЮБОЙ ФИЗИЧЕСКИ РЕАЛИЗУЕМЫЙ ПРОЕКТ по обработке сигналов. Из теории прямо не следует эта реализуемость. Поэтому проект - это творчество инженерной квалификации.
Русский язык доступен всем русскоговорящим. Но лишь подготовленные люди способны создать интересующее массу людей литературное произведение.
Поэтому, когда вы используете библиотеки, задайте себе вопрос в чем состоит созданная лично вами новизна. И тогда вы перестанет нести такие глупости.
Вообще, грамотный и опытный программист никогда не пишет прогу напрямую "на регистрах". Те, кто с СТМ знаком более 12-13 лет (в то время Cube HAL-а еще не существовало), они уже давно имеют собственные функциональные обертки, реализующие работу с регистрами. Фактически, это и есть HAL, поскольку HAL - это аббревиатура Hardware Abstraction Layer (Level) - слой аппаратной абстракции. И это - нормально и правильно.
Кто недавно познакомился с СТМ, те конечно используют предлагаемую производителем версию - Cube HAL - проприетарная универсальная обертка от ST. В этом нет ничего плохого, тоже имеющий место быть подход. Однако, большинство пользователей Cube HAL почему-то считают, что раз есть Cube HAL, то изучать железо вообще не нужно. В наше время ИИ-ботов наверно вообще не нужно ничего изучать, всё за тебя напишет ИИ-бот. Классно конечно, но это "путь в никуда". Убери ИИ-бот, отключи такого юзера от инета (что сейчас запросто) - и всё, приехали, он и шагу шагнуть не сможет самостоятельно.
Кароче, Hardware Abstraction Layer - штука правильная и нужная. Это - самая нижняя часть программной абстракции. Следующим над ней звеном стоит абстракция работы с внешним по отношению к микроконтроллеру устройством через инструментарий HAL. По терминологии ST - это Board Support Package (BSP) - пакет поддержки наплатного окружения. И уже через инструментарий BSP работает верхний слой приложения. С некоторых случаях может еще добавляться прослойка Middleware - обычно это библиотеки, реализующие протоколы обмена, кодеки или иные функциональные единицы.
Таким образом, опытные программисты не держат в уме названия регистров и битов, они пользуются написанными ранее слоями абстракции. И чем более опытный программист, тем больше у него имеется наработок на разных уровнях абстракции, а значит и шире возможности по миграции на разные микроконтроллеры. А неопытные кодописатели о такой организации работы даже и не догадываются. Для неопытных каждый новый проект начинается с нуля. Даже если есть Cube HAL и ИИ-бот, это все равно новое генерирование низкого уровня и новые теребонькания ИИ-бота.
Rapra писал(а): Ср июл 01, 2026 17:56:36
Вообще, грамотный и опытный программист никогда не пишет прогу напрямую "на регистрах".
Разговор шел не о "напрямую на регистрах".
Разговор шел о конкретных библиотеках созданных вендором. Поэтому под HAL подразумевался не общий, а частный смысл.
А так - да, код нужно писать сверху вниз. И регистры всплывут в самом нижнем уровне. Причем без лишних сущностей типа передачи в функцию указателя на домен периферии, где простейшая единственная строка кода раздувается раз в пять и более. В результате нужно включать o3 с неизбежными проблемами при отладке. И естественно, что драйверы периферии кочуют из проекта в проект и не важно написаны они на регистрах или на библиотеках вендора.
И еще одно замечание про "грамотного и опытного программиста" есть множество задач где он отсутствует за ненадобностью и деструктивностью. Это те самые радиотехнические задачи. Код для них пишет радиоинженер-разработчик. А у него несколько иные взгляды на написание кода.
O3 - можно и иногда нужно. Я ещё и -flto подключаю. Да, поначалу странно было: "в отладке работает, а в релизе - нет", но сейчас все ОК. Вот, что мне непонятно: почему чем выше версия gcc, тем "жирнее" бинарник...
P.S. калокубера, абдуринщика и т.п. шваль никогда бы не взял на работу. Это как "повар", который готовит из "бомж-пакетов".
