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

Для радиолюбителей DIP вообще никогда не надо. Инфа 146%. Нет ни одного аргумента.

написание кода на Си для QT

В Qt - язык C++, там нельзя писать на C. Естественно, что другой язык может казаться сложнее, если его не знать.

У ардуино там собственный специфический язык

Который называется C++, ага. Специфический редкий язык, который никто не знает.

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

Я вообще никогда не ковырял именно в дебагере - надобности небыло. Я говорил про полностью программный симулятор. Который (vmalab) вылавливает даже то чего не выловит железный дебагер - например обращения к не инициализированным переменным и некорректную инициализацию периферийных устройств.

на десктопе, без железа вообще.

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

И после этого уже обычно хватает printf в отладочную консоль.

Аналогично, после симулятора и мне хватает.

Для радиолюбителей DIP вообще никогда не надо.

Вы пытаетесь доказать это радиолюбителю со стажем 40+ лет. Так что уж позвольте вам не поверить. Для штучных самоделок без крайне жестких ограничений по массогабаритам dip-корпуса действительно удобны если не предполагается «гнать тираж». Вот почему dip-корпуса регулярно попадаются в серийных изделиях - я действительно не знаю. Вроде как в условиях роботизированного монтажа - корпуса для поверхностного монтажа должны быть удобнее.

У ардуино там собственный специфический язык

Который называется C++, ага.

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

В Qt - язык C++, там нельзя писать на C.

Вообще-то можно много на чем. Даже на Питоне и Аде. На Си тоже можно: https://wiki.qt.io/Language_Bindings#Qt_6_for_C_(libqt6c) Вот только уровень сложности самого QT - весьма далеко за пределами понимания непрофессиональных программистов. Там в QT совершенно дикие объемы что документации что исходников и понять как же этого работает и как этим пользоваться - по всей видимости нужно базовое профильное образование иметь. Иначе даже если что-то и получится написать то будет «как-то оно работает но как именно не знаю». И куча непонятных глюков. Что мы нередко и видим в программах на QT,написанных непрофессионалами.

Вроде бы canny вполне себе успешно развивается и на PICах.

Я никогда не читал столько документации, как при программировании для МК. А на Qt я писал. Там вообще ничего сложного не было.

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

В общем мнение своё сохраняю.

Это под какие контроллеры необходим такой дорогой программатор?

Я писал для GD32 и nRF52. Использую JLink.

Тем не менее логические анализаторы с софтом под линукс существуют. Вот например тут есть https://www.saleae.com/pages/downloads

Его и купил. Два раза. Первый раз выкинул 1500 долларов, т.к. таможня не пропустила. Второй раз заказал из Китая за 2000 долларов, его пропустила.

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

Клонами не пользуюсь, для меня это неприемлемо.

Разное в кучу смешиваешь по-моему. Есть clangtidy, который контролирует coding style и репортит типовые ошибки. На гитхабе можно дополнительных привинтить. Там где тестами покрывается - coverage report генерится.

Именно периферию дебажить - как-то особо не сталкивался с необходимостью.

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

Не, ну в симуляторе можно наверное, но я не вижу регулярных преимуществ.

Если не занимаешься СВЧ (а это уже не дело ембеддера), то полосы 150 МГц достаточно для любой контроллерной периферии.

СВЧ это про гигагерцы. Но да, 100 - 200Мгц полосы, обычно хватает (но лучше 300, чтобы уже наверняка), 2 канала и хотя бы 1 гигасемпл.

Почти во всех моих проектах было бы достаточно игрушки за десятку долларов с алика. 99% времени 99% возможностей дорогого анализатора простаивает.

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

50-долларового xgecu хватает для любого флеша и всех восьмибиток. А 32-битники шьются еще одним 50-долларовым клоном j-link. Итого 100.

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

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

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

В том-то и дело что у них там изобретен свой диалект.

Вы шутите? :)

без крайне жестких ограничений по массогабаритам dip-корпуса действительно удобны

Чем именно в 2025 году это удобно. Зачем сверлить, если можно просто QFP корпус поверхностным монтажом ставить, запаивается оно элементарно любым паяльником в любых условиях. К тому же я выше писал, да и многие тут писали, что есть готовые платы копеечные с шагом ножек гребенки 2.54, как у дипа, и можно запаивать их в более большую плату как вариант. Или просто втыкать в ответную гребенку без пайки, с возможностью замены за секунды (собственно как и DIP, тут просто аналогичный подход). Плюс на них сразу вся базовая обвязка (кварц, стабилизатор, конденсаторы, кнопки сброса и джамперы режимов загрузчика), все это не надо отдельно покупать, разводить, паять.

В том-то и дело что у них там изобретен свой диалект.

Нет, там стандартым g++ это компилируется все. В отличие от Qt, внезапно, у которого используется кодогенератор и диалект C++.

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

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

по всей видимости нужно базовое профильное образование иметь

У меня нету профильного образования программиста, и я не вижу никаких проблем в разработке на Qt, в целом сложность определяется решаемой прикладной задачей, а не сложностью самого Qt. Сам Qt прост, если говорить о задаче построения GUI как отдельной. Другое дело, что написание программы для компа зачастую предполагает какую-то сложную обработку чего-то, что будет куда объемнее и сложнее того что на микроконтроллере.

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

Это философский вопрос. Читайте исходное утверждение с припиской «при прочих равных».

Впрочем - я что-то не очень верю в существование хоть сколько-нибудь серийных девайсов именно с ардуиной внутри.

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

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

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

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

На алике такого валом.

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

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

Если соответствующие ноги не занимать то китайские модули вполне прошиваются китайским же программатором usbasp https://habr.com/ru/articles/252061/

100 - 200Мгц полосы, обычно хватает (но лучше 300, чтобы уже наверняка), 2 канала и хотя бы 1 гигасемпл

Hantek DSO2D15 соответствует при цене 200. Анализатор основных одно-/двух-проводных протоколов тоже есть.

Даже для восьмибиток желательно иметь не только программатор, но и отладчик

Ну ок, за Atmel-ICE я отдал еще 150.

Зачем сверлить, если можно просто QFP корпус поверхностным монтажом ставить, запаивается оно элементарно любым паяльником в любых условиях.

Главная проблема это шаг выводов обычно.

И я не понимаю зачем было в микроконтроллер плюсы пихать

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

Там обычный С++, и компилируется всё штатным g++. Бутлоадер ардуино это один из факторов её успеха.

Не понял в чем проблема, поясни

В плюсах это легко решается, в C нет

А за счет чего это решается? За счет хипа? Так зачем останавливаться, макаки свой js на контроллеры уже притащили, там все еще проще.

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

Давайте уточним терминологию - что именно вы имеете в виду под «ардуину ставят».

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

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

Ну то «если».

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

Что у вас за хипофобия то такая? Аргументы? Реализация realloc половину прошивки занимает?

А сверлить типа просто. Ну если тяжело, ну запаяйте вы блюпил, Господи!

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

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

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

А сверлить типа просто.

Иногда действительно проще и быстрее. Если без сверления, то альтернатива DIP soic с шагом 1.27 или tqfp с шагом 0.8 хотя бы. Хотя второе уже сложнее уже будет.

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

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

Знаем мы, как у них «все работает». Писал с год назад пост на тему, после того как насмотрелся творений ардуинщиков.

класс с интерфейсом «строки», который будет использовать только «статическую» память

char string[100];

Готово.

Допустим, есть чип 48 ножек. Делаем от каждой ножки дорожку-отвод, разносим дорожки на ваш кошерный шаг 2.54. Получается квадрат со стороной 30 с копейками. С шагом 2.54 как у дипа, ну чтобы «дырочную» рассыпуху ставить в отверстия вплотную к этому квадрату. Ну и, это точно больше занимает на плате, чем размер чипа в dip 48?

Отлично, а теперь склей строку, int, строку и float. Сравни реализацию на C и на C++.

Плата будет проще, что тут не понятного?

Чем именно она будет проще?

Шаг дорожек больше.

Сравни реализацию на C и на C++

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

склей строку, int, строку и float

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

Ну да конечно, только моргать диодом нужно.

На С будет короче и намного гибче.

Как в C++ при «склеивании» (имеется ввиду << я так понимаю) отформатировать int и float так как нужно, а не так, как захотелось реализаторам << не превращая строку кода в клоунаду с вызовом бесконечных методов для форматирования на каждую хрень, которая в printf кодируется всего одним символом.

Реализация форматирования вывода разных типов в C++ сделана через жопу. И всё ради того, чтобы не добавлять в стандарт банальный std::printf(), после чего никто этим говном со «склеиванием строк в С++» пользоваться не будет.

Вот даже если бы нужно было придумать самый неудачный пример про удобство C++, то даже сев и подумав, сложно было бы придумать что-то ещё менее удачное чем «склеивание строк».

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

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

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

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

Речь была не про это, а конкретно про класс String в ардуино. Там форматирование

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

Где 3 - число знаков после запятой. Есть более простые дефолтные варианты, где будет просто 2 знака после запятой.

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

Ну вы же хоть в общих чертах представляете себе, во что это превращается после компиляции? А главное зачем это делать?

Ладно ARM-ы, их не жалко, но чтобы в AVR затянуть FPU-рантайм, это нужно быть истинным ардуинщиком.

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

У меня связанный с ардуино только один проект был, там было 2 мегабайта ОЗУ. Для склеивания строк хватало. Собственно, там микроконтроллер формировал json массив на 1000 значений и отсылал на сервер через http post. Все это запрограммировано в среде ардуино.

А теперь вы меня спрашиваете тут, а не жирно ли склеивать строки при помощи memcpy (который внутри String их склеивает).

Ну как сказать. Есть в линуксе команда date, можно выполнить и посмотреть какой она напечатает год. Это не будет 1985 год.

Ну пример синтетический с float, можно с int то же самое, все же еще намного проще станет, там просто к String можно сразу int приплюсовывать.

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

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

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

У меня связанный с ардуино только один проект был, там было 2 мегабайта ОЗУ

Классическая ардуина – это вообще-то 32 килобайта. А 2 метра только на старших ARM-ах в монструозных корпусах найти можно. Не нужно вырожденный частный случай преподносить как средний по больнице.

формировал json массив

И какой злой волшебник может помешать формировать json на лету и отправлять его без полной буферизации?

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

В каком месте тут вообще закралось подозрение, что я конкретно в AVR предложил float засовывать?

Если вы не в курсе, то ардуина по дефолту AVR, а не то что вы думаете.