PIC никому не нужен теперь?

Я полностью согласен насчет переизбытка, и что стримы какая-то странная штука. Речь о том, чтобы выбрать достаточное подмножество под свои задачи, и попутно обучиться, фокусируясь на реальной задаче а не на липапединге.

На раст сам хотел бы перелезть, но пока звезды не сходятся. Слишком радикальные перемены, сроки моих поделок улетят в голубые дали, и так уже затянул. Может потом перепишу.

Ну я в радикально другую страну свалил. В том числе потому, что хочется ковыряться в молодежных ништяках, а не тратить нервы на эти грёбаные превозмогания. По железу критично работать с современными технологиями. Иначе приобретаемый опыт будет для роста не полезен. Кроилово и превозмогания пипец как засасывают в свои пучины.

Тут иногда действительно проще на что-то другое переключиться. Тот же софт менее требователен. Там кроме чистого разума ничего особо не надо.

Но с точки зрения продукта (конечного результата) особого смысла нет.

Вы путаете хобби с профессией, похоже.

Под промышленную печатку сразу берутся другие компоненты (мельче)

С чего бы?

А свободное время можно потратить например чтобы порисовать корпуса в опенскаде и фрикаде (которые китайцы там же напечатают за копейки).

За две недели я звездолёт нарисую. :)

Чтобы на выходе иметь не «йа сделаль» а именно продукт.

И всё таки Вы путаете коммерцию и хобби.

ЛУТ имел смысл раньше, когда вообще ни хрена не было. Лучше чем ничего. Но сейчас IMHO это тупик.

Макетки, ЛУТ и т.п. всегда будут актуальны когда нужно быстро и сейчас (при условии реализуемости, разумеется).

Тем более, что это практически «ничего не стоит».

Время это самый ценный ресурс!

Вы путаете хобби с профессией, похоже.

Не, я лет 20 или больше не занимался разработкой за деньги. У меня сто пудово хобби. Просто отношение основательное.

С чего бы?

Ну а чего с дипами и млт париться?

Там просто другие эффекты проявляются. Детальки на поверхностном натяжении сами выравниваются. Результат выглядит как промышленная пайка, причем без усилий. За счет размера больше вариков с конструктивм играться. Ну и выше уже писал - с четырехслойкой питание по внутренним слоям, автоматически уходят практически все косяки, и упрощается топология.

Набивать на таком руку - IMHO полезный опыт.

И всё таки Вы путаете коммерцию и хобби.

Не, это менеджерские термины могут вводить в заблуждение :). Я опенсорсы леплю, ни какой коммерции.

Это просто серьезное отношение к результату. Ведь если думать на уровне «продукта», то его жизненный цикл начинается с заказа платы и компонентов. Надо об этом позаботиться. Если простому любителю дать в зубы BOM, большинство в местном магазине закупку не осилит.

Когда о подобных вещах не задумываются, то на ровном месте херят повторяемость проекта, который сам по себе может быть очень хорошим. И это называется «йа сделаль» - проект есть, а продукта нет. Если хочется чтобы поделка взлетела, имеет смысл чтобы ее мог повторить не просто радиолюбитель, а даже не сильно бухой школьник.

Поэтому я очень ценю jlcpcb. Там и рисовалка, и платы, и компоненты, и 3D-печать, и CNC. Суперски покрывает то что может радиогубителю дома понадобится.

Макетки, ЛУТ и т.п. всегда будут актуальны когда нужно быстро и сейчас (при условии реализуемости, разумеется).

Будут конечно. Но я о том, чему есть смысл учиться в первую очередь. Мне интересно, чтобы люди росли в профессиональном плане, и делали это максимально быстро. От лутов с макетками эффект сильно пожиже.

Просто отношение основательное.

Эта болезнь называется перфекционизм.:)

Ну а чего с дипами и млт париться?

Не обязательно. Можно не парится с 1206 или париться с 0402.

Когда о подобных вещах не задумываются, то на ровном месте херят повторяемость проекта

Зачем повторяемость в хобби?

Эта болезнь называется перфекционизм.:)

И такое тоже есть :)

Не обязательно. Можно не парится с 1206 или париться с 0402.

Чем компактнее, тем больше возможностей по конструктиву. https://oshwlab.com/puzrin/pd-trigger тут с 1206 уже не так клево получится. Дома без напрягов паяется 0603 (на пасте, не паялом). 0402 уже такое себе, не для всех.

Зачем повторяемость в хобби?

Ну мне вот прикольно, чтобы мои проекты становились популярными. Такое вот хобби, делать клевые популярные проекты. Для этого нужна хорошая повторяемость.

Ну мне вот прикольно, чтобы мои проекты становились популярными. Такое вот хобби, делать клевые популярные проекты.

«Определенно, тщеславие – мой самый любимый из грехов. Он так фундаментален, самолюбие – это естественный наркотик»

:)

Короче? — Да. Проще? — Нет!

Плюсы с каждым новым стандартом все больше напоминают brainfuck.

Может не распробовали просто :). А может такие задачи где и обычного С хватает. Я где-то год с cpp ковыряюсь с помощью ИИ. Без ИИ усрался бы разобраться на таком уровне как сейчас. А так выходит задорно и ненапряжно.

Рисуется в БРАУЗЕРЕ за 15 минут

Что именно? Мигалка светодиодом? Могу даже согласиться. Правда непонятно зачем под «изделия» такого уровня сложности вообще плату изготавливать. А для изготовления платы под что-то более серьезное - надо немало всяких требований фабрики соблюсти. Иначе или вообще в работу не возьмут или сроки будут большие или цена конская или то и другое сразу.

спорить с дедами бесполезно

Вы пытаетесь спорить с человеком который принимал участие в процессе доводки опытного образца до [мелко]серийного изделия. И лично наблюдал работу специалиста-технолога который утрясал вопросы с фабрикой. Потому и говорю что для чего-то сложнее мигалки светодиодами это вовсе не так просто как вы пытаетесь утверждать начитавшись РЕКЛАМЫ. Особенно если как выше предлагали заказывать не только изготовление платы но и монтаж деталей.

Какая нахрен к чертовой матери документация

Технологическая, внезапно. Предмет есть такой «Технология производства РЭА». Его в институте изучают. Там много совершенно не очевидных для любителя тонкостей технологического процесса.

Может еще разрешение от обкома партии на постройку мигалки светодиодами получить надо?

Если ваша мигалка будет что-нибудь излучать в эфир - то получать разрешение таки придется. Если вы не знали, мобильным телефоном или wifi-роутером вы можете пользоваться только потому что необходимые для этого документы уже были оформлены производителем или импортёром. Без разрешительных документов таможня радиопередающее средство не пропустит. Понятно,что бардака хватает и бывает что пропускают всякое. Но сейчас уже не 90е годы,с бардаком борются, и рисковать не рекомендуется. Именно потому что 2025 год, а не 2005 какой-нибудь.

В частности, объяснял авторам, как на С сделать подобие ООП

Вот именно! Когда мне требовалось ООП то я его на Си делал. И не я один - видел даже библиотеки для пользовательского интерфейса,в таком стиле написанные. Просто,удобно,и без лишних абстракций. А самое главное,что вещи типа вышеупомянутого кольцевого буфера на Си - сейчас можно самому не писать а найти готовые. Как и многие другие уже написанные типовые вещи.

Вагон типовых кейзов решен типобезопасно и качественно.

Если важен безопасный и качественный код то это в сторону например Ada смотреть нужно. А никак не в сторону С и С++.

Потому и говорю что какой-то критической надобности в плюсах на микроконтроллерах нет. Хотя понятно что если кому-то плюсы сильно нравятся то пользоваться можно. Некоторые вон даже на Питоне под МК что-то писать ухитряются,хотя казалось бы совсем мало подходящий для такого применения язык.

есть некоторые классы задач, вроде GUI, которые без классов совсем через одно место делаются.

Авторы GTK с вами не согласны. Хотя это конечно уже не про микроконтроллеры.

реальные люди, которые рисуют транзистор вверх ногами. Такие вот нынче радиогубители.

Взять полностью готовый проект,сделаный профессиональным разработчиком электроники аж общемирового уровня. Заплатить денег за его изготовление на фабрике. Об электронике знать настолько мало что даже не уметь правильно нарисовать транзистор. Зато обладать знаниями и навыками в области внешнеэкономических торгово-закупочных операций. Ну и где тут собственно РАДИОЛЮБИТЕЛЬСТВО? Это не радиолюбители,а профессиональные покупатели.

Делать самому платы и покупать детали в местных магазинах больше не имеет особого смысла.

А вот тут я с вами согласен - КОММЕРЧЕСКОГО смысла в этом нет. Сэкономить ничего не получится. Радиолюбительство нынче это хобби, а не способ самообеспечения электронными устройствами как было в СССР,когда собрать магнитофон(или усилитель, или синклер) было дешевле чем его купить. Тоже самое кстати и со всяким моделизмом. Если не интересен сам процесс изготовления то готовую модель дешевле купить. Судя по тому что вы в каждом своем сообщении упоминаете цены - вы смотрите на электронику как на бизнес. Ничего плохого в этом не вижу - это полностью ваше право. Но вот к радиолюбительству это отношения не имеет. Но есть и другой тип людей - которым просто нравится мастерить что-то собственными руками. Удовольствие они от этого получают точно также как профессиональные покупатели от удачной покупки. Соответственно и прокачаны у них технические навыки,а не коммерческие. Они могут и умеют изготовить печатную плату в домашних условиях но не обладают достаточным уровнем знаний чтобы заказать ее изготовление на фабрике. Еще раз специально отмечу то ни те ни другие люди не «хуже» и не «лучше» других - они просто разные. Поэтому для вас непонятно как это можно не уметь заказать плату на фабрике,а для меня непонятно как можно называться радиолюбителем не умея сделать ее дома и уж тем более не умея правильно нарисовать транзистор.

Потому, что велосипедить это интересно. А пара строк это не интересно.

Вот кстати полностью согласен! Написать что-то самому и после нередко довольно длительных трудов обнаружить что оно хорого работает - это удовольствие. И если проект некоммерческий и сроки не поджимают - то почему бы это удовольствие не получить? Тоже самое я в предидущем сообщении и про изготовление печатных плат написал. Сделать своими руками - интересно. Купить готовое у китайской фабрики - нет.

ООП не нужен.

Я выскажусь менее категорично. Случаи где реально нужен не только ООП но еще и специальный синтаксис для него - встречаются куда реже чем многие думают. Особенно при программировании микроконтроллеров. И таки да - ООП-стиль вполне возможен и на обычном Си. Более того, адепты программирования МК на ассемблере утверждают что и на нем тоже! Если же кому-то просто нравится писать на плюсах - так это его личные предпочтения, имеет полное право таковые иметь.

хз где печатать платы. Доставка затягивается на месяцы. В итоге у меня это отбило всё желание заниматься электроникой.

Это кстати тоже аргумент в пользу «технологического самообеспечения» именно в радиолюбительстве. При необходимости нужные детали можно легко и быстро добыть из обломков всякой бытовой и не очень электроники,благо их нынче горы. Плату изготовить ЛУТом. Код для микроконтроллера написать в свободном линуксовом софте.Корпус нарисовать в свободном FreeCAD и напечатать у коллеги который сильно увлекся 3д печатью и методом последовательных усовершенствований собрал весьма крутой принтер.

И пофиг на любые ограничения и изменения международной обстановки.

Ну я в радикально другую страну свалил.

А меня жаба задушит бросать собственный дом с оборудованной радиолабораторией, приборы,инструменты, запасы тех же радиодеталей. В другую страну через две таможни протащить всё это практически не реально. На новом месте придется опять начинать с нуля и потратить годы жизни чтобы снова обзавестись тем что у меня тут уже есть. Впрочем, на обзаведение домом с отдельным помещением под занятия своим хобби - моей оставшейся жизни может уже и не хватить.

не тратить нервы на эти грёбаные превозмогания.

Так это лично вы воспринимаете занятия хобби как превозмогания. С этой точки зрения проще всего будет купить готовое. Или если вдруг готового нет,что в современном мире крайне маловероятно, то нанять того кто сделает.

я лет 20 или больше не занимался разработкой за деньги.

Я опенсорсы леплю, ни какой коммерции.

Репутация и известность в опенсорсе - это тоже актив,который вполне можно оценить в деньгах. И у вас именно коммерческий подход,а не хоббийный.

Ну а чего с дипами и млт париться?

А чего тайваньцы и китайцы парятся аж в серийных изделиях? Это я про их инверторы DC/AC 12->220в. Там и микросхемы в дипах и резисторы один-в-один как наши млт. И это не одна какая-нибудь модель,это их большинство таких. В том числе довольно известные бренды типа MeanWell. Сам удивляюсь почему в этих изделиях поверхностный монтаж это скорее исключение чем правило. В силу моих занятий автономной энергетикой видел я разных инверторов немало.

Впрочем - использовать smd-компоненты на собственноручно сделаных платах и паять их пастой никто ведь не запрещает. Любительская технология вовсе не означает обязательности использования дип-корпусов и резисторов млт. У меня запасы выводных компонентов измеряются килограммами - потому мне проще взять их из шкафа и использовать чем где-то что-то заказывать и ждать неделями. Ограничений по массогабаритам у меня обычно нет,поэтому по этому поводу и не переживаю. Были бы такие же запасы smd - использовал бы их. А так - только если вдруг потребуется что-то особо мелкое сделать.

Если хочется чтобы поделка взлетела,

Что в вашем понимании значит «взлетела» применительно к радиолюбительству? В абсолютном большинстве случаев поделка изготавливается в количестве одна штука и используется дома у автора. Нередко еще и много раз доделывается-переделывается по ходу скажем так «уточнения техзадания».

Поэтому я очень ценю jlcpcb. Там и рисовалка, и платы, и компоненты, и 3D-печать, и CNC.

Да,только к радиолюбительству как хобби это отношения не имеет. Хобби - это про умение сделать своими руками,а не заказать готовое на фабрике. Да еще по чужому готовому проекту с полным комплектом документации.

люди росли в профессиональном плане

От заказа изделия на фабрике по готовой документации они если и вырастут то только как коммерсанты,а не как специалисты в электронике.

имеет смысл чтобы ее мог повторить не просто радиолюбитель, а даже не сильно бухой школьник.

У другого любителя и уж тем более у школьника - будут другие возможности и технические и финансово-коммерческие. У вас вот есть возможности и умения,позволяющие заказать плату на фабрике. Но это - редкое исключение. Вон выше коллега из Казахстана отметился - ему это недоступно. Мне тоже. Причем в обоих случаях именно по причине отсутствия коммерческих навыков,а вовсе не технических.

Зачем повторяемость в хобби?

Более того,в хобби она вредна ибо убивает элемент творчества,ради которого люди обычно хобби и занимаются. К примеру у художников-любителей распространено копирование произведений великих мастеров. Вручную, кисточкой и красками. Хотя казалось бы можно взять файл из интернета и распечатать на цветном принтере. С точки зрения качества результата - в абсолютном большинстве случаев будет лучше и уж точно быстрее. И музыканты-любители зачем-то вручную на инструментах играют,хотя можно запись включить и «не заниматься превозмоганием»(С).

А может такие задачи где и обычного С хватает.

Так и я о том же говорю. Большинство применений микроконтроллеров,и уж тем более применений любительских, не имеют такого уровня сложности где использование плюсов дало бы сколько-нибудь заметные преимущества. Вы выше приводили в пример вполне полезную поделку - стабилизатор оборотов для электроинструмента. Ну и зачем там плюсы? Ну кроме того что если они просто нравятся. Более того, я так думаю что такую штуку можно вообще без микроконтроллера сделать если повозиться. Во всяком случае стабилизаторы оборотов для маломощных коллекторных электродвигателей я видел в переносных кассетных магнитофонах и они без микроконтроллеров обходились. Вполне может быть что те решения получится масштабировать для применения в не особо мощных электроинструментах.

Кстати, STmicroelectronics, крупнейшая европейская компания подобного рода, объявила, что в ближайшее время сократит 2800 сотрудников, а в общем и целом планирует сократить 5000 за 3 года.

По гуглил. Капитализация за год упала на четверть. Сокращают, примерно 10% персонала. Не то что бы катастрофа.

вещи типа вышеупомянутого кольцевого буфера на Си - сейчас можно самому не писать а найти готовые

Я, кстати, не нашёл. Есть какие-то поделки, которые использовать не нужно. Или куски из больших библиотек. А вот простой минимальный ring buffer с нужными API, с атомарным доступом, на простом стандартном C - нет. Всё хочу сам написать, осчастливить мир… Но пока запала недостаточно.

Многие компании набрали кучу людей за предыдущие годы, когда экономика пухла. Сейчас избавляются от них, сейчас кризис. 10% это ещё немного.

А вот простой минимальный ring buffer

Я находил пример простой терминальной программы под DOS,работающей с ком-портом. И там был кольцевой буфер,который я и позаимствовал.

Ну мне такое не пойдёт. Мне нужен проект на гитхабе, отдельно оформленный, с тестами, со звёздочками, с недавним коммитом, с активными Issues, откуда я могу скопипастить ringbuffer.c и ringbuffer.h себе в проект.

Плюс проект под DOS это 100% устаревший код. Мне нужен стандартный C с <stdatomic.h>, а не не пойми что. Думаю, что в твоём примере никаких атомиков даже и нет. А мне ringbuffer нужен для взаимодействия между прерываниями в том числе, а тут почти многопоточность. Плюс интерфейс нужен для того, чтобы можно было работать без лишнего копирования памяти. В общем задача не такая тривиальная, на самом деле, хотя ничего сложного в ней тоже нет, но это надо сесть, очень аккуратно закодировать и потом ещё продумать хороший набор тестов, в том числе для обнаружения проблем с многопоточностью.

с недавним коммитом

Кхм… Например, первая реализация была в 2010г. Потом в течение 2 лет оно использовалось, фиксилось, т.е. уже 2012г. Какой коммит ты там хочешь увидеть в 2025г.?

Если коммитов нет, значит проект умер. Какой угодно, хоть copyright 2025, главное - чтобы коммиты были и на Issues была реакция. А так - даже hello world можно развивать до бесконечности. Документацию переписывать туда-сюда, какие-нибудь там новые стандарты C адаптировать, мало ли что ещё.

Желание атомиков при необходимости взаимодействия между прерываниям - понять могу. Желание обязательности гитхаба - нет. Как говориться - кому шашечки,а кому ехать. Я как раз для микроконтроллерных применений не стесняюсь искать код среди всяких библиотек и примеров под dos. Идея кстати не моя - мне ее подкинул один израильский программист эдак четверть века назад. Он еще и Turbo C использовал для визуальной отладки алгоритмов на компе перед переносом их в контроллер. И успешно делал силовую электронику,где ошибка в коде чревата выгоранием весьма дорогостоящих деталей. Я сейчас для визуальной отладки использую симулятор VMLAB. Жаль что такого нет под arm-контроллеры.

мне ringbuffer нужен для взаимодействия между прерываниями

Да, мой код был расчитан на одно прерывание от одного ком-порта. Мне этого было достаточно. Портов было два,но взаимодействовали они не напрямую своими прерываниями,а через главную программу которая перекладывала данные из одного буфера в другой,попутно их переделывая несложным образом.

По всей видимости большинству этого тоже хватает,потому особо продвинутых реализаций кольцевого буфера и не лежит на каждом углу. Так что да - при таких требованиях уже самому писать придется.

потом ещё продумать хороший набор тестов, в том числе для обнаружения проблем с многопоточностью.

Не очень представляю себе как это вообще тестировать учитывая асинхронность прерываний. Даже если запустить тест на несколько часов - тоже не факт что все возможные проблемы выловятся.

Не очень представляю себе как это вообще тестировать учитывая асинхронность прерываний. Даже если запустить тест на несколько часов - тоже не факт что все возможные проблемы выловятся.

Честно говоря, я сам не очень представляю. Но вроде способы есть. Первое, что мне самому в голову приходит - обозначить интересующие точки разрыва в исходном коде с помощью макроса, который в специальном отладочном билде будет компилироваться в вызов функции. И этот вызов функции может либо ничего не делать, либо блокироваться. Этим поведением управляет тест из другого потока. Т.е. ты настраиваешь в тесте интересующее тебя поведение во всех точках разрыва, запускаешь два потока и из третьего потока отслеживаешь - когда какая-то точка выполнения заблокировалась - разблокируешь, например, другую точку в другом потоке. Описал сумбурно, но смысл в том, чтобы писать тест, который с одной стороны многопоточный, а с другой стороны все переключения контекста детерминированные.

Вместо макросов можно использовать отладчик, который будет вставлять break в нужных местах, но это выглядит довольно сложно в реализации.

интересующие точки разрыва

Вот как раз главный вопрос в том как их найти. Согласен,что некоторые достаточно очевидны. Но ведь прерывания могут вызывать в абсолютно любой момент,и где именно может вылезти конфликт - умозрительно предсказать не так-то просто если не быть крутым теоретиком от программирования.

А так - даже hello world можно развивать до бесконечности.

вопрос в том, нужно ли. Новые стандарты С каждый год не появляются, как и багов ограниченное количество, и для такой небольшой кодовой базы, и при условии, что код вообще кто-то использует, что там фиксить каждый год?

Вот как раз главный вопрос в том как их найти. Согласен,что некоторые достаточно очевидны. Но ведь прерывания могут вызывать в абсолютно любой момент,и где именно может вылезти конфликт - умозрительно предсказать не так-то просто если не быть крутым теоретиком от программирования.

Ну это сама натура юнит-тестов. Ты тестируешь некоторые сценарии. Набор входных параметров. И проверяешь, что при этом наборе входных параметров твой код работает корректно. Задачи покрыть все возможные сочетания параметров не стоит, это едва ли возможно даже для a + b. И найти все баги при этом тоже невозможно, это не формальная верификация кода.

Поэтому вопрос - как найти интересные точки разрыва это примерно то же, как найти интересные входные параметры, которые могут проверить что-то существенное. Используя свой опыт, знание тестируемого кода и тд.

Запустить код на два часа в 1000 потоков это тоже хорошая идея. Но это уже не юнит-тестирование, это отдельная дисциплина.

У меня высокие стандарты для используемых библиотек. Поэтому я их редко использую. Есть признаки, которые показывают на то, что библиотека, вероятно, качественная. Если этих признаков нет, придётся проводить очень полный аудит кода. Учитывая, что с большой вероятностью этот код делает не вполне то, что мне нужно, часто проще просто написать его самому, решив интересующую подзадачу.

Если задача сложная, которую я сам решать буду слишком долго, значит выпендриваться не буду. Но такие задачи встречаются не так часто и там обычно вопрос выбора не стоит.

А так - вот, как выглядит живой проект: FreeRTOS/queue.c

Вроде сам файл концептуально похож на кольцевой список, где изобретать особо нечего, но вот десяток-другой коммитов в год там набирается.

А так - вот, как выглядит живой проект: FreeRTOS/queue.c

так это часть ОС

Ну ringbuffer.c мог бы быть частью некоей библиотеки реюзабельных алгоритмов и структур данных, в общем-то. Это не единственная структура, которой не хватает в стандартной библиотеке C.

Нет и не может быть никакой стандартной реализации кольцевого буфера. Можно только предложить некий стандартный api, но не реализацию.