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

Памяти легко может не хватать именно из-за наплевательского к ней отношения

Профессионал на си++ напишет код, который ничем по эффективности не уступит сишному(а по «выразительности», универсальности и «безопасности» скорее даже превзойдёт).
Ну а «новичок» на сишке, оперируя строками, будет ловить рандомные баги из-за выхода за пределы массива.

Лень спорить, вы просто мыслите категориями 15 летней давности. Ардуино уже давно не то, не так, и не такие мощности. Сейчас 2025 на календаре.

Чем именно в 2025 году это удобно.

Тем,что для всякого рода самоделок, изготавливаемых в единичных количествах, можно не заниматься изготовлением печатной платы вообще,а использовать готовую дырчатую макетную плату и соединения тонким проводом МГТФ. Если в схеме всего-то пара десятков деталей то это вполне приемлимый в любительских условиях способ быстро и просто получить работающую конструкцию без возни с разводкой и травлением.

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

Вот с этим полностью согласен. Сам такие китайские модули использую(с Atmega 328p). Но это уже не про корпус собственно контроллера. Но может быть случай когда нужен контроллер с которым таких модулей нет. Не часто,но всё же возможно.

там стандартым g++ это компилируется все.

Я-то знаю что при должном умении возможно так скомпилировать. Но адепты ардуино именно что продвигают свой вариант как «язык ардуино». С нагромождением кучи всего вокруг него.

Не говоря о том,что С++ в микроконтроллерах это само по себе ненужное переусложнение в абсолютном большинстве случаев.

20 лет назад - да, но за 20 лет многие вещи, как бы немного развились и улучшились. И железо, и софт.

Это ответ на вопрос «возможно ли». Да, сейчас С++ в МК технически возможно,нисколько с этим не спорю. Но это не ответ на вопрос ЗАЧЕМ такое избыточное усложнение.

Сам Qt прост, если говорить о задаче построения GUI как отдельной.

Если устраивает кое-как работающий неудобный GUI то да, его сделать не сложно(и кстати не только на QT). А вот как только от гуя требуется что-то определенное,например эффективное управление с клавиатуры без необходимости ежеминутно хвататься за мышь - тут-то и начинаются сложности. И если в библиотеках не столь монстрообразного размера можно разобраться что и как надо сделать чтобы получить нужное поведение,то в таком монстрище как QT копаться придется доолго.

Результат и так и так фиговый.

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

для того чтобы можно было нормально (в понимании любителя не программиста) работать со строками

Я - давно уже любитель,в должности программиста уже пару десятков лет не работаю. Однако я не вижу чего-то плохого в работе с строками на Си если мы всё еще говорим о микроконтроллерах. В МК всегда немного оперативной памяти,поэтому крайне желательно чтобы любые операции с ней были явными. Лезть в микроконтроллеры не зная стандартный Си - на мой взгляд весьма странно. Разного же рода реализации динамических строк(они кстати и для Си есть) - используют динамическое выделение памяти,к тому же оно еще и может быть несколько запрятано внутрь. И в условиях ограниченности памяти - это однозначно плохо. Даже если писать очень аккуратно и утечек памяти не допускать,то с ее фрагментированием ничего сделать не получится. И в один совсем не прекрасный момент может оказаться что очередной malloc получит облом несмотря на то что «вообще» свободная память есть. А вот непрерывного куска нужного размера - уже нет. Причем из-за хаотичности выделения/освобождения памяти повторить эту ситуацию может быть весьма не просто. Соответственно баг может жить долго и портить нервы своими случайными проявлениями.

Бутлоадер ардуино это один из факторов её успеха.

Как-то странно считать лишнее усложнение фактором успеха. Ибо не представляю что может быть проще копеечного китайского программатора usbasp.

Модуль, полностью аналогичный ардуине, даже с USB-гнездом, но без загрузчика

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

что делает USB мертвым грузом

Если там стоит микросхема usb-uart то это готовый порт для отладочной/настроечной консоли например. Немало случаев когда наличие такой консоли позволяет обойтись без собственного индикатора на устройстве. Если же от устройства требуется какое-то взаимодействие с компом - то тем более usb не мертвый груз и его наличие на модуле удобно. Понятно что и usb как и всё прочее можно самому на свою плату припаять. Но если есть готовые дешевые китайские модули то почему бы не воспользоваться? Чисто любительский юзкейс - припаять такой модуль на дырчатую макетку,а вокруг него добавить уже своё схемотехническое творчество. Работающую конструкцию можно получить за один вечер без возни с разводкой и изготовлением кастомной печатной платы.

Если соответствующие ноги не занимать

Ну то «если».

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

Как-то странно считать лишнее усложнение фактором успеха.

В чем усложнение-то? Загрузчик это штатный функционал контроллера. Начинающему на ардуине не нужно ничего кроме самой ардуины и компьютера с usb (до этого com) портом. Даже паять не нужно…

у PIC своя ниша. погляди видео на ючубе с их главнюком вкрации: они летают в космос (понятно что специальные rad-hard серии), они готовы выпустить партию своих любых микроконтроллеров хоть из 80х годов, только деньги плати.

конкурентов у них долгое время не было, до 90х, когда появился AVR. но потом он сдох под натиском дешевых ARM (stm32 и прочих).

если бы не китайские клоны ардуин на AVR, то про AVR бы все давно уже забыли. а так, AVR были долгое время идеальны по всем ттх, относительно пиков (и кратно вразы дешевле их).

по итогу: PIC-и прижились лишь у тех, чье развитие остановилось в начале 90х. Те кто с трудом осилили i8051, и потому с большим трудом перешли на PIC-и, но уже не смогли в AVR и все более новое. не хочу обидеть энтузиастов и всяких diy-щиков, которые что-то делали для себя, речь исключительно про «профессионалов» на зарплате.

так что если кто-то до сих пор использует PIC в своем проекте, обычно это красный флажочек что человек с трудом 2 байта осилил переслать. ну а что поделать, если аж целая промышленная индустрия, только этим и занимается? или думаешь автоматизировать что-то на заводе, требуется какое-то умение чего-то? каждый первый кто этим занимается, не умеет программировать от слова совсем. там чуть менее чем все задачи идеально ложатся в абстрактное «помограть лампой». считать значение с датчика/концевика, включить/выключить какое-то реле и все. вот и весь завод. смотри сам на типичного представителя: до сих пор боится вложенных циклов, не понимает что затраты на циклы несоимеримо малы по сравнению с запуском любой другой програмы, на линуксе аж с 1995 года, но не знает что такое sed, даже до расшифровки первой буквы S не проэволюционировал, не может проделать минималистичные правки простейшей cli программы с открытым кодом. ах да:

Видимо всё-таки профильное образование для этого нужно,а я на электронщика учился

вот так вот, не учили, то поэтому и не научился ничему больше.

Профессионал на си++ напишет код, который ничем по эффективности не уступит сишному(а по «выразительности», универсальности и «безопасности» скорее даже превзойдёт).

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

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

только в сишке - () - это явный вызов функции

А функция может вызвать другие функции.. а эти другие функции могут О УЖАС динамически выделить память. А если это был не вызов функции, а макрос 😱. А? А?
https://qu.ax/lYEso.jpg

Ежу понятно, что реализация подобного, не нужного в 99.99% проектов, кейса в языке с перегрузкой операторов будет выглядеть лаконичнее. Но вопрос состоит в том, так ли необходимо тащить в контроллер классы, менеджеры памяти, и прочую дребедень?

Ты наверное просто не в курсе, всё уже придумано https://www.etlcpp.com/. Можешь иметь прелести плюсов не дрюкая хип.

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

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

Там вместо printf завезли же std::format, который типобезопасен, и кмк удобен.

Форматирование на стримах - да, на любителя. В эмбедах надо только если совсем по-быстрому говнякаешь и все пофик. Да и то не уверен.

Если отбросить вопросы доступности в отдельной взятой стране, я не вижу проблем, если паять молодёжно, а не монстром из хозмага.

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

Т.к. трафаретный станок дома нафик не нужен, просто делаешь реперные отверстия 0.7, и шпилишь плату с трафаретом проволокой AWG22 на силиконовый коврик.

Ну а чтобы с разводкой многоногов не морочиться - заказывается 4-слойка с питанием по внутренним слоям.

Просто берется ETL вместо std, и ни каких динамических аллокаций нет. А удобство есть. Просто не все в курсе, и от этого берутся городские легенды, что С для эмбедов как-то особенно хорош.

Там вместо printf завезли же std::format, который типобезопасен, и кмк удобен.

Там какой-то совсем уж дикий велосипед зачем-то изобрели для указания формата, вместо того, чтобы просто сделать классический printf «типобезопасным».

Ну так-то и монтаж можно заказать, но мы же про домашнее радиогубительство ещё разговариваем?

Профессионал на си++ напишет код, который ничем по эффективности не уступит сишному

Бездоказательно.

Сейчас 2025 на календаре

Ага, и все контроллеры с менее чем 2 MB RAM куда-то испарились. Наверное, мы в разных 2025-х годах живем, как в небезизвестном кино.

Можешь иметь прелести плюсов не дрюкая хип

И как же не дрюкая хип можно иметь прелести типа динамических строк? Там вместо хипа используется статический массив байт? И чем это отличается от обычного хипа без лишних прослоек?

Зачем же такие громкие заголовки? Position Independent Code как был нужен, так и нужен.

Может совместимость бы поломали. Принтф уже костыляли макросами, чтобы размерность переменных внятно указывать. Это выглядело максимально всрато :).

https://github.com/pdsink/jetlog?tab=readme-ov-file#supported-formats вот тут подмножество format для эмбедов запиливал, мне норм.

Могу в принципе согласиться, что format затащили поздновато.

Мы по-моему о смысле жизни в этом топике :).

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

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

IMHO путаешь динамические строки и операции над строками. Строки с фиксированным буфером. Но например можно аппендить строки как привычно, и не усираться на каждом шаге что память расхреначит.

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

А удобство есть.

Удобство в чем именно? Что такого надо делать со строками на микроконтроллере что неудобно делать на стандартном Си?

городские легенды, что С для эмбедов как-то особенно хорош.

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

хип плох тем, что имеет привычку заканчиваться в рантайме

А еще он имеет привычку фрагментироваться. Что при общем малом количестве ОЗУ в микроконтроллере будет проблемой. Причем вылезет это в абсолютно случайный момент времени в процессе эксплуатации и глюк будет крайне трудноповторяемым и от того сложным в устранении.

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

Люди на ардуине программируют, Как-то все работает.

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

И почему ардуина должна зависнуть? И почему не зависнут другие контроллеры, которые будет программировать новичок?

есть чип 48 ножек. Делаем от каждой ножки дорожку-отвод, разносим дорожки на ваш кошерный шаг 2.54. Получается квадрат со стороной 30 с копейками.

Китайцы делают и продают готовые такие кусочки печатных плат под чипы с разными всякими многоногими корпусами. Первый попавшийся пример,не очень многоногий: https://radiocomplect.ru/uploads/autoupl/products_pictures/prd_6028_01b13183ce3d6f82dcb69ee92020f91c_big.jpg

это точно больше занимает на плате, чем размер чипа в dip 48?

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

а теперь склей строку, int, строку и float.

А зачем их склеивать? Если для вывода в последовательную консоль то там и printf вполне справится с соответствующей форматной строкой и аргументами. А если требуется какой-то гуй на собственном экране то там обычно какая-нибудь библиотека используется которая рисует заданным шрифтом в заданном месте.

Ну и манипуляции со строками не ограничиваются конкатенацией.

Можно посмотреть на это с другой стороны? А откуда вообще в микроконтроллере строки неопределенно-произвольной длины могут взяться? Клавиатуры у него нет,места для хранения текстовых файлов тоже нет. Типичное применение - чтение значений с датчиков и превращение их в сигналы для исполнительных устройств. Для управления - несколько кнопок и экранчик небольшого и фиксированного размера. Строкам взяться не откуда,конкатенировать нечего и незачем.

Да, я немного упростил рассуждения,но в большинстве применений микроконтролеров примерно так и есть. Не путаем МК с одноплатными компами,имеющими на борту аж целый линукс. Вот так конечно уже и строки могут быть.

String a = String(«temp=») + String(36.6f, 3);

А зачем так? Чем это лучше банального printf без всяких сложений строк? Даже головой думать не надо, достаточно было попросить ИИ - это я так выпендрился,изобразив из себя начинающего который не умеет писать форматные строки для printf :)

Ответ железного дровосека GPT-4o mini:

В языке C, чтобы выразить аналогичное выражение с помощью функции printf, можно использовать следующий код:

#include <stdio.h>

int main() {
    float temperature = 36.6f;
    printf("temp=%.3f\n", temperature);
    return 0;
}

В этом примере %.3f указывает на то, что число с плавающей запятой будет выведено с тремя знаками после запятой.

Проверил. Код компилируется, выдает

temp=36.600

к String можно сразу int приплюсовывать

А есть ответ на вопрос ЗАЧЕМ вообще «приплюсовывать»? Да еще на ардуино,которое на мелком AVR работает.

я конкретно в AVR предложил float засовывать? Интересен ход мысли, как пришли к такому выводу?

Контекст разговора был про ардуино. Которое AVR. Впрочем,до этого обсуждали PIC,которые с точки зрения «засовывания float» ничем не лучше.

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

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

Ардуино уже давно не то, не так, и не такие мощности.

Ардуино - это изделия под определенной торговой маркой. А то что китайцы могут сделать нечто совсем другое и обозвать его «ардуино» просто в маркетинговых целях - так на то они и китайцы. Классическое же «настоящее» ардуино - это именно AVR. Впрочем - в китайских клонах тоже весьма мало оперативной памяти.

Сейчас 2025 на календаре.

И это повод плодить монстрообразный неэффективный говнокод где вместо одного printf целый «класс» используется?

заказывается 4-слойка с питанием по внутренним слоям.

Напомню,что обсуждалось радиолюбительство,а не промышленное производство радиоаппаратуры. Да, я знаю что есть например «Резонит», но также и знаю сколько надо потратить усилий чтобы подготовить всю необходимую документацию в том виде в котором возьмут заказ в работу. И сколько будет стоить плата если заказывать в штучных количествах.

Ну так-то и монтаж можно заказать

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

заявления о проблемах cpp в эмбедах давно не соответствуют действительности.

Пихание C++ в микроконтроллеры создает проблемы,а не решает их. Хотя при желании запихать конечно можно - с этим никто и не спорит. Но лучше код от этого не станет,а вот хуже - очень даже может. Именно из-за всяких неявных действий,выполняемых плюсовым кодом. Все эти побочные эффекты надо постоянно держать в голове и учитывать. Зачем такое сомнительное удовольствие - не понятно. Приведенный выше пример с «склеиванием строк» - абсолютно синтетический если мы всё еще говорим о микроконтроллерах,а не одноплатных компах с линуксом на борту.

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

именно новичку надо бы быть «ближе к железу» чтобы понимать

Что нужно новичку я не знаю. Это пусть новички сами думают, пробуют.
Это вы приводили аргумент что С++ неэффективно работает. А я вам ответил, что неэффективен он только в руках новичка. И в руках того же самого новичка и Сишка(как почти подмножество С++) будет неэффективна и опасна.

Фрагментацию можно устранить, если выделять фиксированные куски памяти. К примеру пишешь свой malloc_8, который выделяет 8 байтов памяти. malloc_16 для 16 и тд. И для каждого размера при линковке указываешь статический размер буфера, из которого будет выделяться память. Тут никакой фрагментации не будет. Заодно ещё и выделение/освобождение будет очень быстрое (там просто связный список пустых блоков) и даже можно это сделать lock-free атомарным.

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

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

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

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

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

Кстати, старые паскалевские строки были шикарны в этом плане.

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

Работаю сейчас над имплантом-кардиостимулятором и люто соглашаюсь.

Си проще С++ и потому в руках новичка будет намного безопаснее. Это контринтуитивно, но это так.

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

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

И как определить необходимый размер каждого пула?

Да так же, как определить размер для хипа. Или анализом кода, или тестированием на разных сценариях.

И, главное, расход памяти при таком подходе будет намного выше.

Это не важно. Важен не расход памяти, а чтобы памяти хватило для всех режимов работы устройства. malloc с произвольным размером вообще ничего не гарантирует, как раз из-за проблем с фрагментацией. Какая тебе польза от того, что расход памяти меньше, если у тебя malloc выдал 0 и девайс ушёл в ребут в ненужный момент. К тому же реализация malloc получается сложней и менее детерминированной. Со связными списками malloc это константное число машинных команд. В общем случае это поиск свободного места и тд и тп, не пойми сколько займёт. Где-то - пофиг, а где-то не пойдёт, если у тебя реалтайм, тебе надо знать, за сколько времени операция отработает.

В целом ещё раз напишу - динамический аллокатор это супер-неудобно для небольших встраиваемых приложений. Лучше всё выделять статически. Как раз по выше-описанным причинам. malloc это уже для девайсов, где размеры оперативной памяти хотя бы в сотни килобайтов, а то и в мегабайты. Там и RTOS можно засунуть вроде Зефира, и хитрые структуры данных, и алгоритмы на процессы распилить, всякие там очереди и тд, и маллок туда засунуть такой, в котором сам никогда не разберёшься, в общем когда сложность прошивки высокая, можно за это заплатить ресурсами побольше.

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

Нафиг. Есть ch32v003

STM32 - ширпотребное дерьмо, у которого нет вариантов, сертифицированных под взрослые стандарты военщины и т.п.

Больше слушай этих выдумщиков.

Ну arm-ы и risc-v-ишки имеющих сертификатов для автопрома, космоса, военки до фига и больше. Что на западе, в Китае или у нас.

для ПИКа есть компилятор бейсика

Для других MicroPython

Сишка, кругом сишка сишкой погоняет. Наворотили HAL/LL,

Ну по чему же только «сишка». HAL-ы активно почистили для поддержки новомодных C++ стандартов (например, от неуместных volatile).

Да и HAL-ы нынче генерируют (пример https://github.com/rust-embedded/svd2rust).

Да так же, как определить размер для хипа. Или анализом кода, или тестированием на разных сценариях.

Оптимизм это хорошо, но не всегда. :)

Какая тебе польза от того, что расход памяти меньше, если у тебя malloc выдал 0 и девайс ушёл в ребут в ненужный момент.

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

В целом ещё раз напишу - динамический аллокатор это супер-неудобно для небольших встраиваемых приложений. Лучше всё выделять статически. Как раз по выше-описанным причинам. malloc это уже для девайсов, где размеры оперативной памяти хотя бы в сотни килобайтов, а то и в мегабайты. Там и RTOS можно засунуть…

Тут согласен.