Как стать автором
Обновить

Комментарии 87

НЛО прилетело и опубликовало эту надпись здесь

Самое интересное в STL — контейнеры, а вот их я бы неопытному разработчику крайне не советовал применять на микроконтроллерах. Да, их можно "правильно приготовить", но многие ли новички знают, как именно?
Вообще, имхо, при программировании под микроконтроллеры весьма разумно перенять подходы, принятые в линуксовом ядре. Списки, таскание контекста в предвыделенных структурах и жонглирование членством их в списках, структуры данных с использованием container_of для доступа к содержимому, и все такое прочее.

Почему только контейнеры? Алгоритмы тоже ничего, от банальных std::any_of и std::accumulate до всяких std::inner_product.

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

Кроме контейнеров такой сущностью может быть, например, обычный сишный массив — std::begin и std::end возвращают всё как надо.

Ну так-то да. Но потом джуны начинают морщить лоб, рвать волосы и терять самооценку, попытавшись создать std::begin от массива, переданного в параметрах функции — "ну как же, ну ведь с глобальным массивом же работало!", и все это потому, что массив, переданный через параметры, имеет sizeof () равный sizeof-у указателя, а не всего массива, и итератор не создается :)
Не подумайте, что я против итераторов или алгоритмов. Просто лично у меня как-то с ними не складывается. Не особо нужны, поэтому в голове не задерживаются, приходится лазать в книжку, поэтому стараюсь не использовать, поэтому в голове не задерживаются, и так далее, самоподдерживающийся процесс. Да и на плюсах я уже очень давно не пишу… А когда писал, плюсы были совсем не такие, как сейчас.

Ну так-то да. Но потом джуны начинают морщить лоб, рвать волосы и терять самооценку, попытавшись создать std::begin от массива, переданного в параметрах функции — "ну как же, ну ведь с глобальным массивом же работало!", и все это потому, что массив, переданный через параметры, имеет sizeof () равный sizeof-у указателя, а не всего массива, и итератор не создается :)

Щас бы использовать встроенные массивы вместо std::array

Мне не совсем понятно, что значит, научился "программировать микроконтроллеры". С моей точки зрения все 7 пунктов это тот минимум, который нужно знать для того, чтобы научиться "программировать микроконтроллеры". А чтобы понять тонкости и научится оптимально использовать ресурсы микроконтроллера, думаю, времени надо поболе. Так то, чтиво брошюрки на ядро ARM v7 reference manual на 2700 страниц займет достаточно времени. Если перейти на другое ядро, например, RISC V, там таких брошюрок несколько, а еще прибавить к этому брошюрки по С++, там и жизнь пройдет, а не только 3 года.

Увы, имхо, misra c требует вещей, которые после некоторого порога сложности проекта (очень небольшого) приводят не к упрощению и большей контролируемости проекта, а наоборот.

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

Создать на них, наконец, что-то стоящее.

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

И я о том же. Сначала кажется, что для создания чего-то стоящего не хватает квалификации, а потом оказывается, что не хватает фантазии.

Но тут есть и положительный момент — не обязательно дожидаться пока вы станете гуру программирования — шедевры можно создавать прямо сейчас!
Откройте для себя чудесный мир программируемой логики FPGA. Зачем вам этот последовательный мир микроконтроллеров, в нашем параллельном мире process'ов, always'ов и комбинационной логики тоже интересно.

Кстати, на ПЛИС можно собрать свой собственный процессор, со своим набором команд, придумать к нему ассемблеры, компиляторы и тд. Ну или воспользоваться чем-то уже готовым, но сделанным на логике, например, RISC-V, MIPS, Cortex M3/M0, NIOS, MicroBlaze, PicoBlaze.
Действительно, и чего это мы тормозим, когда есть такой волшебный мир FPGA? У этого мира есть только один недостаток — порог входа размером с Эверест, а так, да, FPGA — это круто.

Да нет там никакого особенного порога входа. Отладочная плата для "пионерских поделок" стоит $40, софт бесплатный, хороший учебник — бесплатный, чип со вполне приличной для многих задач емкостью — от $6 до $12.
Была бы нормальная задача, а реализовать — несложно.

а реализовать — несложно.

Если всё так просто, то где (буквально миллионы, как в случае с Ардуино) пионеров с платами FPGA в руках?

Так задач для FPGA немного, тем более интересных пионерам.

эээ где где бесплатный софт? Какую ПЛИС не возьми, софт бесплатен только до определённого размера проекта, а дальше всё… плати. Поиграться бесплатно, а что-то сделать — покупай… подписку! Даже для бытовых(современных) нужд ограничений уже слишком много. Итам, в паралельном мире ещё больше вещей взрывающих мозг, таких как БЫСТРОДЕЙСТВИЕ схемы зависящее от её сложности, необходимость продумывать синхронизацию между макроблоками из-за переменной задержки сигнала, зависящей от сложности логической функции блока…
Приличнаая емкость, это 32 макроячейки? На которой элементарный счетчик едва соберёшь…
Приличнаая емкость, это 32 макроячейки?


Сейчас играю: ZYNQ 7010, 2 core 666MHz ,22 KLUT — 256 MB DDR3 128 Mb flash — вполне серьезная игрушка за $13.5 c бесплатной доставкой aliexpress.com/item/1005001500766274.html
Впрочем согласен, что у FPGA не совсем та же область применения как у контроллеров.И порог вхождения немного другой, не скажу, что выше, просто другой. Товарищ вверху habr.com/ru/post/532744/#comment_22416460 немного сам себе противоречит с реализацией микроконтроллеров на FPGA. Их поэтому и делают, что микроконтроллеры иногда удобней чем RTL.
Не противоречит. Типичный представитель таких МК — современные чипсеты на материнских платах компьютеров. Удобно… прошивкой меняешь схемотехнику чипсета, исправляя «аппаратные» косяки и обновляя аппаратное ядро встроенного контроллера, управляющего работой всего чипсета, проводящего самодиагностику и прочее… по сути большой FPGA на сотни тысяч LUT… не хватает таймера контроллеру? добавим… ещё каналов DMA нужно? добавим… в случае с железным МК пришлось бы перепаивать микросхему для апгрейда.
Прочитайте его коммент еще раз:
Зачем вам этот последовательный мир микроконтроллеров, в нашем параллельном мире

"вполне серьезная игрушка за $13.5 c бесплатной доставкой aliexpress.com/item/1005001500766274"
Забавно, они продают плату от кондиционера как девборду. Цинк за копейки. Хорошая основа для разработок.

Это контрольный блок от майнера в целом(ebaz4205) а не только его вентиляторов. Видимо много их разбирают и утилизируют, поэтому за бесценок.
А вот асики видимо выбрасывают.

Тот чип, что имею ввиду — это младший альтеровский Cyclone-IV, стоит меньше $10 в розницу, паябельный вручную корпус, 6 с лишним тысяч триггеров, 30 штук блоков памяти по 9 килобит. Я на нем расширение ввода-вывода для своего нынешнего устройства делал: пачка UART-ов (больше дюжины) через быстрый SPI с удобным для основного процессора протоколом, развязка клоковых доменов, пачка GPIO-шек (у основного процессора со свободными пинами напряженка), софтверно-переключаемые внешние интерфейсы, конфигурируемые пины плат расширения. Все это удовольствие на верилоге написалось с нуля за пару недель без предыдущего опыта работы на verilog, и спасло меня от громадной возни с кучей противоестественных ограничений, которых было бы уйма, если бы я попытался все сделать на основном процессоре.
Кстати, бесплатность софта сохраняется вплоть до очень немаленьких чипов. Вроде бы 4-е циклоны все поддерживаются на бесплатном квартусе. Ну а когда один чип стоит за тысячу баксов — тут уж и софт можно купить.

Добавлю еще применение — контроллер дисплея в помощь мелкому микроконтроллеру. От просто кадровой обновлялки с буферной памятью до видеоускорителя с возможностью рисования примитивов, наложений и т.п.
Софт действительно бесплатный, причем для огромного числа емких кристаллов. У Xilinx, например, полностью бесплатна линейка Spartan-7 и Artix-7, а это, на секундочку, кристаллы 100к и 200к логики соответственно, частично Kintex-7, Kintex US, Ускорители Alveo, Zynq-7000 не говоря уже о семействе ZU+ (с огромных количеством плюх). Рекомендую ознакомиться с UG973 таблица 1.
На FPGA можно сделать проект «железа» со своим пониманием системы команд процессора. Как пример Forth computing system

raw.githubusercontent.com/howerj/howerj.github.io/master/h2/107.mp4
Можно, и это круто, но зачем ??? Потратить год и написать никому не нужную фигню ??? Это здорово для обучения (впрочем не факт) и совершенно бесполезно.
И эту фигню можно написать и на PC, раз в десять быстрее(хотя бы за счет более короткого цикла изменение/компиляция/запуск).
Первый процессор Novix появился в июне 1985 года и получил обозначение NC4016. Он работал с тактовой частотой до 7,5 МГц и показывал скорость до 10 миллионов операций в секунду — впечатляющий результат для того времени. Все операции NC4016 исполнялись за один такт.

Чужие: странная архитектура инопланетных компьютеров

P.S. Ардуино шилд c GPU, FPGA, HDMI, и Python поддержкой для игр и аудиовидео Gameduino 3X Dazzler by Excamera Labs. J1 процессор запущен в FPGA.

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

1. FPGA намного дороже и менее энергоэффективны по сравнению с микроконтроллерами.

2. FPGA подходит для выполнения очень быстрого IO на множестве каналов, но таких задач практически не бывает в «обычных» устройствах.
То есть собрать цифровой 64 канальный осциллограф с частотой сэмплирования в сотни мегагерц — тут FPGA подойдет. Написать GUI для этого осциллографа — нужен микроконтроллер.

3.
на ПЛИС можно собрать свой собственный процессор, со своим набором команд, придумать к нему ассемблеры, компиляторы

ЗАЧЕМ?!!! Зачем делать тот пласт работ, что проделал Atmel или ST, если можно просто взять их готовый микроконтроллер, который будет дешевле в 100 раз, в 10 раз экономичнее и в несколько раз быстрее.

Мое мнение — FPGA нужна для очень узкого класса задач, где нужно очень быстро обрабатывать по несложным алгоритмам параллельные данные — головки самонаведения ракет, PCI-Express переходник, осциллографы, сетевое оборудование и т.п.
Сфера применения микроконтроллеров гораздо шире.
С++ и STL отличная вещь, но для контроллеров без нормального MMU очень опасна, из-за фрагментации памяти. Не пользуйтесь ими на МК, если не понимаете в деталях что происходит и не принимаете специальных мер для работы с памятью.
Автору. Не давайте таких советов, сначала разберитесь сами, микроконтроллеры бывают разные.
Это относится только к освобождению динамической памяти, и контейнерам STL, которые его используют. В остальном использование C++ безопасно, может быть не менее эффективно чем использование C, и даёт массу преимуществ, в частности лучшую читаемость кода, и возможность обнаружения большего процента ошибок на этапе компиляции.
Пишу на плюсах для систем с нормальным MMU и на С для систем без него(или с ним но ниже, как в ядре OS). И стараюсь их не смешивать. Наверноге дураки пишут на чистом С ядро линукса?
Очень легко сбиться и использовать STL с аллокациями, особенно когда пишешь сразу на обе стороны (и PC и контроллер ) Я люблю с++, но в контроллерах ему не место (ИМХО), и Вы меня не переубедите, я раньше выйду на пенсию :)
Наверноге дураки пишут на чистом С ядро линукса?

Технически это не "чистый C", а его GNU-тый диалект. Но да, дураки.


Я люблю с++, но в контроллерах ему не место (ИМХО), и Вы меня не переубедите, я раньше выйду на пенсию :)

А, то есть на микроконтроллерах не нужны ни нормальные массивы, ни пространства имён, ни сокрытие данных, ни constexpr, ни более строгая типизация, ни шаблоны, ни целая пачка алгоритмов из std. Деды терпели — и ты потерпи.

На контроллерах с тем же самым gcc какой то другой GNU?
" Да дураки "- нет слов… Все отнять и поделить?
Псс. Да я не против, можете мигать светодиодом и дальше хоть на расте.
НЛО прилетело и опубликовало эту надпись здесь
Это и правда и неправда. Структура и надежность программы в большей степени зависит от продуманности ее архитектуры и квалификации программиста и в гораздо меньшей степени от языка. С++ удобнее чем С, но это далеко не самый важный фактор. В больших проектах архитектор программы важнее программиста( даже если это один и тот же человек). И в одном проекте может быть много языков. И выбор языка не всегда связан с удобством программиста. До осознания отсутствия королевских путей и серебрянных пуль еще надо дорасти, чего Вам и желаю.

НЛО прилетело и опубликовало эту надпись здесь
Вы комменты через один читаете? Причем тут деды и новоделы? Плюсы сильны вместе с динамической аллокацией. Раст вообще постороен на оптимизации(трассировке) времени жизни объектов компилятором. А контроллеры без MMU страдают фрагментацией памяти, поэтому требуют особой заботы при работе с ней. И рекомендовать использовать с++ и STL неопытным программистам на контроллерах — это подсунуть им хорошие грабли. А опытные -обойдутся и без советов программистов с 3 -5 летним стажем.
НЛО прилетело и опубликовало эту надпись здесь
Я согласен, но
1 Дельфистам пофиг и мои и Ваши советы.
2 Закоренелым (закостенелые )железячникам тоже
3 остальным программистам тоже, если они вам непосредственно не подчиняются, впрочем если подчиняются то тоже пофиг.
Остались неопытные. А вот им -вредно.
С++ лучше учить не на микроконтроллерах
а Cи++ в этом смысле как до Луны до Rust и Ada.

Которым, в свою очередь, в этом смысле до Луны как до Coq и Agda.

НЛО прилетело и опубликовало эту надпись здесь

Но на Coq и Agda софт таки не пишут :]

Почему же? Из кока вон экстрагируют, а на агде даже можно что-то успешно запускать.

НЛО прилетело и опубликовало эту надпись здесь
C и libc отличная вещь, но для контроллеров без нормального MMU очень опасна, из-за фрагментации памяти.

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

А по теме — С++ однозначно удобней и безопасней С в любых контекстах.
Во первых STL это не только контейнеры но и алгоритмы.
Во вторых уже давно есть std::array — контейнер без аллокации. И недавно добавили std::span, который на понядок удобней всяких (void*, size_t size).
Ну и как вишенка — все контейнеры, которые аллоцируют память, делают это через аллокатор. И вы вполне можете написать себе такой какой надо.
На мой взгляд — в области микроконтроллеров как раз не хватает людей с пониманием различных протоколов (I2C, SPI, MIPI/CSI) и их «правильных» имплементаций (с прерываниями или DMA вместо опроса). Вторая «болевая точка» — это управление потребляемой мощностью. А имплементация алгоритмов и структур данных действительно не так сильно отличается от десктопно/серверной.
Далеко не у всех микроконтроллеров ядро это ARM. И самое главное в программировании микроконтроллеров, это не 7 пунктов автора. Самое главное это разобраться как работает микроконтроллер, конкретный микроконтроллер. Иначе будет мучительно больно за потраченное время на реализацию той или иной «плюшки» уже имеющейся в базе или обнаружить что стандартная библиотека эмулирует работу UART вместо того, чтобы использовать аппаратный (UART просто пример).
m.habr.com/ru/post/27055 вот этот человек умеет «программировать» микроконтроллеры. Стиль статьи не технический, но очень хорошо передаёт то, что надо изучить в первую очередь, а не С++…
В 2020 году, компиляторы для МК вышли на такой уровень компиляции исходного кода, что выхлоп с Си и С++ не будет отличаться.

Боюсь вас удивить, но в выборе C vs C++ наиболее важным критерием является не «выхлоп» компилятора, а то, сколько у вас памяти, и как она распределяется.
Если у вас есть безразмерный heap — можете хоть на питоне писать (модное, кстати, направление для микроконтроллеров).
А вот если памяти лишней нет, да еще и распределять ее некому (кроме себя самого), то на плюсах писать конечно можно… но это уже искусство ради искусства.

Приведу достаточно продвинутый пример использования современного C++. Допустим есть класс для работы с LTDC и в функцию инициализации одной строкой передаются требуемые пины, пусть это будут 14 пинов для RGB444. Эта функция пробрасывает пины в более общую initRgb666(), а в качестве недостающих передаются PinDummy<>. Далее все пины передаются в функцию которая добавляет им правильные AF одновременно проверяя допустимость использования конкретных ног и если что выдается сообщение об ошибке с именами ошибочных пинов. И пины одним списком возвращаются обратно, уже с AF, затем этот список вместе с режимом, а можно использовать и список разных режимов, передается функции инициализации пинов из класса портов. Там к пинам подмешиваются режимы, удаляются PinDummy<> и вызывается конструктор очередного класса который сначала распаковывает все пины в обычный массив структур, затем сортирует его по трем параметрам при помощи std::ranges::sort() и далее идет код примерно на страницу который в цикле берет отсортированные данные и этого массива и после некоторых преобразований сохраняет их в другом массиве. Наконец есть еще небольшой класс который забирает массив у предыдущего и копирует, в такой-же массив, но меньшего размера. В самом конце вызывается функция, которая получает на вход массив с информацией о пинах/AF/режимах и выполняет их инициализацию. Итак, что же получится на выходе, если на входе было:


ltdc.initRgb444<PC6, PA4, PE15, PB1, PC0, PA11, PD3, PC7, PB11, PB10, PB9, PB8, PA3, PA10>();

Думаю даже многие из тех кто давно пишет на C++ удивились бы узнав, что получим мы следующее, даже при отключенной оптимизации:


ldr r0, [pc, #668]
bl 0x24000454

В R0 грузится адрес массива и этот массив расположен во флеше(!), а размер его 29 байт. Насколько это мало должно быть понятно из того, что 14 переданных пинов были с 5-ти портов с тремя разными AF. Фактически, поскольку в С++20 можно на этапе компиляции динамически выделять память, использовать виртуальные функции или std::vector, это все тоже могло там быть с нулевым оверхедом в рантайме. Использую С или ассм и близко ничего похожего не получишь, пора уже смириться с тем, что при правильном подходе С++ — это самый эффективный язык для эмбедда :)

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

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

В дизассемблер лезть не придется, получим или массив во флеше или программа не скомпилируется(для чего она должна быть написана с ошибками), а все потому, что от C++ можно явно это потребовать. Не случайно же настолько впечатляющий результат получается даже при отключенной оптимизации, когда один sort() занял бы в рантайме 3КБ флеша.
Добавили для простого массива const и он пойдет по флеш, добавили для класса constexpr/consteval и компилятор будет обязан его разместить там же, но константным класс стал только после создания, за которое отвечает конструктор, а в нем можно делать практически что угодно и совершенно бесплатно. Многие пишущие на C++ удивятся просто потому, что не знают о таких возможностях языка, на ПК они, например, не особо востребованы. Что уж говорить про тех, кто на С++ не пишет...

«Ядро Cortex-M3 компании ARM. Полное руководство Джозеф Ю».
Спасибо! есть на одном известн-… серв.... читаю!
Вчера встретил упоминание про специальные регистры отладки и таймер, а в pdf stm32 только скупая сноска, что мол читайте об этом у ARM
НЛО прилетело и опубликовало эту надпись здесь
Под каждую систему (задачу) — свой подход.
Ну, например, невозможно впихнуть ARM везде, где только можно.

1. Во-первых, когда есть требования по потреблению — например, 80uA в спящем режиме, почти постоянным сном, просыпаешься только по внешним прерываниям или прерыванию от таймера, в остальное время ядро спит.

2. Планируется крупный тираж, и надо, чтобы было дёшево. Экономишь на железе на каждой копейке. Сравнивается твоё время на работу, «впихнуть в невпихуемое», и выбор компонентов на тираже.

3. В этом случае C++ — чисто для удобства, C — норма, ASM — круто, но долго. Пишешь код на C так, что в голове понимаешь, как оно будет компилиться. Ограничения по RAM и ROM.

Но это крайний случай, конечно. Но для дешёвых и энергоэффективных устройств распространён, в случае крупной партии.

(Начинал с PIC 16C622 N-дцать лет назад. Было очень критично. Архитектуру контроллера, ASM надо было знать на 200%, про схемотехнику не говорю. Запихнуть всё сложное в 2kW RAM, 128 bytes SRAM, 2kB EEPROM, эх… По 100_000 строк не было, каюсь)
Ну, например, невозможно впихнуть ARM везде, где только можно.

1. Во-первых, когда есть требования по потреблению — например, 80uA

Возможно. Есть режимы с часами ~ 3uA.
проект, в котором более 100000 строк (что не является большим количеством), становится практически не поддерживаемым на Си

Проект в более чем 100000 строк говорит о неумении писать код для контроллеров)
НЛО прилетело и опубликовало эту надпись здесь
Такой выход и предлагаю — писать более оптимальный код. У меня ни разу не было нехватки ресурсов в AVR-ках, хотя писал на них достаточно многофункциональные распределенные АСУ.
Ну или берите Raspberry, а не контроллер, там вас ничто не ограничивает)

То, что у вас лично не было таких проектов и вам звало avr ничего не говорит о потребностях рынка. Вот у нас в задачах часто не хватает и 512 КБ флеша, хотя библиотек лишних нет, только голый cmsis и код достаточно оптимален. И да, 100к строк в большом проекте это не очень то и много.


Малина не ограничивает? Ну ну)) Огромное потребление и невозможность применения там, где нужен real-time.

НЛО прилетело и опубликовало эту надпись здесь
Например, у нас на работе было время, когда пришло новое начальство, которое раньше для контроллеров код не писало. И начало писать его в своем привычном ООП-стиле «как для компьютеров». Число строк выросло на порядок, бинарник разросся, скорость работы тоже упала.
Я о том, что опытный алгоритмист в большинстве случаев сведет эти 100к строк к 10к.
НЛО прилетело и опубликовало эту надпись здесь
Я рассуждал о принципах, а не о конкретных проектах.

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

Двольно смешно читать про превращение 100к строк в 10, да ещё и от "начальника". Есть огромный пласт проектов, где даже в условиях отличной архитектуры и хорошего кода без лишних библиотек объем все равно больше 100к.


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

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


Я об этом и говорил. Речь о моем начальнике, а не обо мне.
«какие ещё пути развития могут быть у Embedded программистов»
Вот сидит Embed программист на горе со своим знанием IDE, микроконтроллера, С++,
а что запрограммировать ( «сделать что-то стоящее»(с) ) не знает :) Этому вопросу тоже стоит уделять внимание — куда приложить ваши знания и умения. Не моргать же всю жизнь светодиодами :)
С проблемами которые вы описываете OEM производители embedded софта столкнулись 20 лет назад — да все верно проект на N строк на M языке не поддерживаемый. Так же они прекрасно знали, что объем кода (собственно число строк близкий показатель) удваивается за полгода-год. И они не перешли на язык M++ — потому, что переход на язык М++ просто отодвигал эту проблему на момент когда число строк = N++ — т.е. максимум на пару лет. а следовательно — проблему не решал…

Они просто отказались от писания кода на С руками!
НЛО прилетело и опубликовало эту надпись здесь
А это не важно.
Важно что С++ нет и не будет — ибо не нужен. Потому, что это не развивало индустрию а притягивало в нее лишний велосипед, раздувающий штат программистов. Развитие же наоборот сократило штат, увеличив объемы код на порядок.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А Сколько Dragon построено в SpaceX?! Если Dragon рухнет из за ошибки ПО — то ЧТО?!
Если ваш истребитель через 0-ю высоту перелетит — то ЧТО!?
5G это уже что то серьезное из вашего примера. — но все равно — откажет и ЧТО!?

В любом проекте ГДЕ-ТО всегда используется С++ — какая нибудь унылая прикладуха всегда на нем написана. Только вот, когда от кода начинают зависеть жизни миллионов людей — то C++ резко там не наблюдается, потому, что все его преимущества вдруг резко превращаются в недостатки.

То с чем ваш преподаватель игрался — стандарт индустрии. embedded софт давно уже пишется в связке Matlab-Simulink-Ascet а не в VS и тп… И программирование руками осталось лишь как трюково-кроильное (когда надо сэкономить ресурсы)…

Space-X кстати LabView как минимум использует. (9 слайд) А он тоже сам генерит код на С.
НЛО прилетело и опубликовало эту надпись здесь
Вы пишете софт для единичных игрушек смешного объема — ну и какая разница что вы там используете!? да хоть в ардуиноиде пишите — никому не интересно.

А Я вам пишу о проектах с 10млн юнитов и в 2 млн строк кода в каждом. Да чтоб их руками написать — вас таких 2 непрокормимых армии нужны…

НЛО прилетело и опубликовало эту надпись здесь
Когда эти квалифицированные специалисты фантазируют о замене таксистов автопилотами в их ближайшем светлом будущем — это нормально и всячески приветствуется. Когда же им намекают, что их самих уже давным давно заменили, причем технологиями, куда как более примитивным чем автопилот — у них возникает батхерт просто невообразимого масштаба. Как так?! А нас за что?! Мы же любимые — «всегда стоим денег» а таксисты они бесплатные.
НЛО прилетело и опубликовало эту надпись здесь
Вождение авто, в большинстве случаев, есть ни что иное как однообразная механическая работа,


Бу го га. Вождение авто — это не однообразная механическая работа. Это решение задачи распознавания на дороге ребенка, включая случай, когда он едет на велосипеде задом наперед, сидя задницей на руле и вращая педали руками и размахивая ногами в воздухе — естественно с вероятностью в 100%. И эта задача решения не имеет ни в настоящий момент, ни через 10 лет иметь не будет.

Про с++ там где этот скачок произошел — он уже давно произошел. А там где нет — уже вряд ли не произойдет. Просто большинство embedded систем обладают конечной сложностью которая не растет исходя из самой задачи которую они выполняют и в лучшем случае там за 20лет раздуют С код на 10-20% — да и черт с ним.
Зачем на дороге распознавать именно ребёнка, когда задача стоит проще — распознать надо препятствие независимо от того человек это, животное или механизм.

Перед полиэтиленовым пакетом будете оттормаживаться так же, как перед человеком?

Ну и классика — кирпич в пакете. тормозить или нет?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.