Комментарии 28
Присоединюсь к предыдущему оратору. Автор показал применимость инструмента, но не показал его преимуществ в сравнении с другими. Даже ожиданий не сформулировал. Таковыми были бы, например,
"А вот если сравнивать с RTOS, то компилятор дает на 11% меньше бинарник"
или
"Новый инструмент дает возможность писать примерно на 25% меньше кода, проще в отладке потому и потому"
Впрочем, опробовать новый инструментарий - это тоже достойная задача. Но хочется каких-то заключений о выигрыше в практическом применении. Ведь именно они сподвигнут что-то менять в своей работе.
Спасибо за внимание к моей статье и комментарий.
Действительно, писал статью по ощущением моряка на мачте: "Земля! Земля!"
Захватила сама идея: воспроизвести базовый функционал ОС на новейшем стандартном инструменте С++20 - корутинах. Ранее аналогичных материалов не встречал, торопился первым ступить на новые земли... Тщеславен немного, каюсь)
Оценка преимуществ моего подхода (и есть ли таковые по факту) - чуть позже или отдельным материалом, или дополнением к этой статье.
В нашем случае, мы сначала придумываем задачу, а уже потом разрабатываем программно-аппаратный алгоритм ее оптимального решения.
Так ОС не разработать... Либо под каждую железку будет отдельная ОС, с соответствующими затратами.
Не силён в embedded, но видел WinCE как в тахеометрах, так и в автомагнитолах. Это ли не embedded с применением относительно универсальной ОС? Назначение устройств разное - ОС одна. Вряд ли разработчики этой ОС подозревали о конкретных устройствах.
В первую очередь надо задать себе вопрос "А нужна ли вообще ОСРВ?"
Если у нас есть куча асинхронных задач, общий HAL который используется различной бизнес-логикой, или большой проект который делается различными субподрядчиками - ОСРВ может быть полезной.
Если мы делаем промышленный термометр с интерфейсом RS-485, то ось только усложнит задачу. Если же мы хотим чтобы такой термометр писал данные в облако, то вполне разумно взять ту же самую Амазоновскую FreeRTOS с готовым сетевым стеком.
Статья больше о фичах С++20, чем о ОСРВ. Действительно, не хватает сравнения по скорости переключения, размеру контекста потока и т.д.
Если мы делаем промышленный термометр с интерфейсом RS-485, то ось только усложнит задачу
Понимание того нужна ли ОСРВ или нет - зависит от задачи. Во многих подобных приборах, до того момента как память МК стала значительно больше и тактовая частота достигла 50МГц и выше, не применяли ОС при разработке. И эта тенденция массово появилась после 2010г. (это мое наблюдение). Сложность , функционал подобных приборов остался на том же уровне. Задание нужных параметров с кнопок , контроль на индикаторе, неспешное выполнение нескольких алгоритмов регулирования и передача на мастер по сети RS485, CAN , LAN. Сетевой стек передачи на сервер работает без ОС на восьмибитном МК без проблем. Чтобы не быть голословным, вот контроллер http://kvest-led.ru/asuno АСУНО на PIC18F97J60 управление уличным освещением и передача телеметрии на сервер. Информация передается через модем SIM900 или по ЛАН, если есть возможность подключения. Более 20 городов в системе.
Так зачем теперь в подобные проекты тащить ОС?
Уважаемые, хотел бы увидеть реальные проекты на МК тех, кто ставит минус. И если у вас нет опыта в разработке - то лучше пройти мимо и промолчать.
Так зачем теперь в подобные проекты тащить ОС?Необходимость в ОС обычно появляется с момента, когда нужно реализовать длительно выполняющийся алгоритм в конкуренции с основным потоком и прерываниями. Например, если мы непрерывно рисуем что-то на графическом индикаторе и параллельно должны вести расчеты и отправлять результаты, то использование ОС сильно упрощает по крайней мере один из процессов.
В более простых случаях многопоточность не нужна, но могут быть полезны примитивы, предоставляемые ОС. Кроме того, если ОС многоплатформенная, то несколько упрощается задача портирования как внутри семейства МК, так и при более радикальных изменениях. В случае автора статьи, я бы не стал изобретать велосипед, а просто бы попробовал написать обертку, скажем, для ChibiOS.
Спасибо за внимание и комментарий!
Вы верно указали на пробелы в статье. Концепт ОС - ну совсем новорожденный. Торопился в публикации поделиться самой идеей "корутины + примитивы синхронизации с универсальным интерфейсом на базе co_await + переключение контекста". Вопросы сравнения с существующими ОС интересуют не меньше вашего, обязательно потестирую, главное чтобы работа оставила время...
Ну термометр опрашивать через шедулер, не загоняя в прерывания ничего кроме тиков, никаких обработок сигналов, измерений, расчетов и т.п. очень по промышленному даже, по "мисровскому" точно. А шедулер это уже пол операционки. Очередь, семафоры и т.п. это да навороты уже. Но прямо отрицать ось я бы не стал, чисто моё мнение. В своих промышленных проектах применяю шедулер, таски, ну и ватчдог внешний (железный, аппаратный)...
Для описанной Вами ситуации, абсолютно справедливо, у меня задачи попроще и опять же данные опроса трех каналов одного АЦП и небольших расчетов из правил Кирхгофа я отправляю по CAN, где его при прототипировании читает P-CAN с виндовым пакетом CAN Explorer (сиреч настоящая полноценная операционка), а в конечном продукте стоит пром.ПК с виндой и софтом, которым я не занимаюсь, который кроме данных с моей платы берёт ещё кучу разных параметров и также везде передаёт и собирает на центральный сервер логи. Так что да, SoC и Lynux минимум (тем более, что всякие "рокчипы" вроде не так уж и дороги) :))))
Спасиибо за внимание к моей статье и поддержку)
Разве WinCE уже не официально мертва в плане поддержки?
Спасибо за отзыв!
После планируемых тестов и доработок, послесловием к статье, добавлю более приближенный к реальному применению пример.
Это раньше такой ход мысли был - поэтому разработка и занимала годы - а это просто нерентабельно. Если иметь готовые кубики "embedded размера" то можно в разы быстрее решать конкретную задачу.
И каково оно, юзать С++ в задачах эмбедед? Я может быть отстал от жизни, но, как мне кажется, С++ (именно подход ООП со всеми вытекающими) в мире встраиваемых систем не очень уж подходит. Я к тому, что на С++ гораздо легче себе в ногу пальнуть, нежели с чистым Си.
К чему вопрос. Бытует мнение что работа с динамическими сущнастями, в мире embedded, это очень опасное занятие и нужно всё делать статическими единицами. Речь, конечно же, про память и объекты. Ну и есть вопросы к объему кода. Хотя, вроде бы говорят (говорят. Я не проверял) сейчас компиляторы все так хорошо ужимают, что разницы практически нет: на сях или на плюсах код написан.
Короче, вопрос для меня остается открытым. Где и когда выгодно применять С++ в проектах, или всё колбасить по-старинке на сях и в плюсах выгоды нет?
С++ вполне себе подходит для встраиваемых систем, так как "динамические сущности" не равно С++ и решается это однократным выделением динамической памяти, если в дальнейшем перераспределения памяти не происходит.
С++ выгодно применять, когда приходится оперировать большим количеством сущностей и/или требуется одновременно вести разработку еще и "ответной" части на кода, который будет крутится на PC.
Вторая проблема C++ — этот язык не знает никто до конца. Разработчики такие также дороже. Исходя из этого — на С++ легко написать плохо. Так что когда «отец» увольняется, то у последователей возникает непреодолимое желание выкинуть его работу в помойку. Была история из жизни, когда крупный международный проект развалился, с официальной формулировкой «надо было писать на Java, а не на C++» проект просто не мог масштабироваться, быстро развиваться в силу того что команда не смогла быстро реагировать на потребности бизнеса.
Третья проблема — низкая детерминированность во времени. Конечно и про аппаратную детерминированность Cortex-M также сложно говорить, так как суперскаляр, два АЛУ, могут быть кэши и прочее. Но даже если использовать MISRA C++, а также не использовать STL, boost то от C++ мало что остается. В моём представлении C++ это все же про создание и разрушение объектов во времени.
Итого, на мой взгляд, и по опыту откастрированный C++ вполне годен как верхний уровень для бизнес-логики, для графики в эмбеддед, для некритичного по времени. Когда железка некритична по цене, а такие программисты есть в наличии. Ну или когда железка настолько серьезная что и так используются внешние тяжелые библиотеки, типа Тензорфлоу, OpenCV и прочее.
Нижний слой хардверной абстракции стоит оставить на Сях.
В далеком уже 2010 г. на плюсах для AVR-ок(!) писали так:
// создаем произвольный список пинов с разных(!) портов
PinList<Pa1, Pa2, Pa3, Pb3, Pb4> MyPins;
// записываем значение в этот список
MyPins::Write(0x55);
// смотрим ассемблерный выхлоп:
//вывод в PORTA
in r24, 0x1b
andi r24, 0xF1
ori r24, 0x0A
out 0x1b, r24
//вывод в PORTB
in r24, 0x18
andi r24, 0xE7
ori r24, 0x10
out 0x18, r24Компилятор в компайл тайм сам рассчитал все битовые маски и логические значения, не оставив ничего лишнего на рантайм. Никаких динамических аллокаций, предельная детерминированность и нулевой оверхед. И это при возможностях языка и компиляторов 10-ти летней давности. Источник здесь.
Возможно этот простой пример подтолкнет Вас провести ревизию предубеждений касаемо обоснованности С++ во встроенных решениях.
Вторая проблема C++ — этот язык не знает никто до конца.
О! Спешу вас обрадовать! Стараниями разработчиков компиляторов у C++ теперь паритет с C — ибо C, как его понимают современные компиляторы, тоже никто не знает до конца!
В моём представлении C++ это все же про создание и разрушение объектов во времени.
C++ (и Rust) — это про создание абстракций. Если у вас в проекте людей, способных это грамотно сделать, нету (или то, что вы пишите, слишком просто, чтобы требовать абстракций), то ни C++, ни Rust , действительно, не нужны.
Нижний слой хардверной абстракции стоит оставить на Сях.
Если это абстрации (любые), то C++ (или Rust) там уместен почти наверняка.
В принципе C++ и Rust идут в одну точку, но с разных сторон: C++ позволяет создавать удобные, красивые, но небезопасные абстракции — и, со временем, старается сделать их использование безопасным, а Rust — сразу говорит, что все абстракции должны быть безопасными или их не должно быть — но это приводит к тому, что некоторые вещи там вообще сделать нельзя ибо никто пока не придумал как их сделать безопасными.
Я может быть отстал от жизни, но, как мне кажется, С++ (именно подход ООП со всеми вытекающими) в мире встраиваемых систем не очень уж подходит.
Вы не просто отстали от жизни, а очень сильно отстали.
Потому что C++ это уже очень давно не “OOP с наследованием и виртуальными функциями” это уже давным-давно очень малоиспользуемая часть C++ (хотя иногда оно бывает и нужно, но чаще нужны совсем другие вещи: RAII, метапрограммирование и т.д. и т.п.)
Где и когда выгодно применять С++ в проектах, или всё колбасить по-старинке на сях и в плюсах выгоды нет?
Существует ровно одна причина не использовать C++: у вас нет людей, которые его хорошо знают.
Хотя если вы всё ещё пользуетесь C, то я бы рекомендовал на Rust глянуть: пользы будет больше, а самая типичная причина продолжать использовать C++ (у нас куча библиотек на C++ и мы не хотим их переписывать) к вам не относится.
Спасибо за ответ! Если есть под рукой, можете дать ссылку на гит какого-либо проекта на плюсах для контроллера (любого), где используется мета программирование, RAII и прочие фишки плюсов?
вот тут можно посмотреть, https://habr.com/ru/post/540064/. У автора и свой гит есть, весьма интересный.
И каково оно, юзать С++ в задачах эмбедед? Я может быть отстал от жизни, но, как мне кажется, С++ (именно подход ООП со всеми вытекающими) в мире встраиваемых систем не очень уж подходит.
смотря какой эмбеддед . Возьмем например одноплатник, допустим dragon 410c (я с ним немного работал), ставим на него линукс и qt, используем С++ в разработке. И это будет эмбеддед. И тут гораздо проще работать на С++ и даже можно в динамическую память.
Где и когда выгодно применять С++ в проектах, или всё колбасить по-старинке на сях и в плюсах выгоды нет?
Выгода есть хотя бы в том, что при переносе кода на плюсы ещё раз придется посмотреть на код, что в свою очередь может показать некоторые ошибки. у себя я так пару мест поправил, не критичные ошибки, но приятного и в них мало.
Хотя, вроде бы говорят (говорят. Я не проверял) сейчас компиляторы все так хорошо ужимают, что разницы практически нет: на сях или на плюсах код написан
для себя проводил тесты, разница все же есть: за счет использования шаблонов можно большую часть кода в компил-тайм перенести, а это уже повышение скорости выполнения и уменьшение расхода ресурсов. Ниже приводили примеры как раз этого.
Я к тому, что на С++ гораздо легче себе в ногу пальнуть, нежели с чистым Си.
Да ладно. Тут скорее так надо говорить "На плюсах сложнее попасть себе в ногу. Но если попал, то отстреливаешь ногу целиком". Разве чистый Си делает строгую проверку на соответствие типов? Вполне можно вместо указателя дать число и отгрести по полной.
CoroOS: концепт операционной системы для микроконтролеров на корутинах С++20