Pull to refresh

Comments 28

UFO landed and left these words here

Присоединюсь к предыдущему оратору. Автор показал применимость инструмента, но не показал его преимуществ в сравнении с другими. Даже ожиданий не сформулировал. Таковыми были бы, например,

"А вот если сравнивать с 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 городов в системе.

Так зачем теперь в подобные проекты тащить ОС?

Уважаемые, хотел бы увидеть реальные проекты на МК тех, кто ставит минус. И если у вас нет опыта в разработке - то лучше пройти мимо и промолчать.

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

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

Спасибо за внимание и комментарий!

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

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

UFO landed and left these words here

Для описанной Вами ситуации, абсолютно справедливо, у меня задачи попроще и опять же данные опроса трех каналов одного АЦП и небольших расчетов из правил Кирхгофа я отправляю по CAN, где его при прототипировании читает P-CAN с виндовым пакетом CAN Explorer (сиреч настоящая полноценная операционка), а в конечном продукте стоит пром.ПК с виндой и софтом, которым я не занимаюсь, который кроме данных с моей платы берёт ещё кучу разных параметров и также везде передаёт и собирает на центральный сервер логи. Так что да, SoC и Lynux минимум (тем более, что всякие "рокчипы" вроде не так уж и дороги) :))))

Спасиибо за внимание к моей статье и поддержку)

Разве WinCE уже не официально мертва в плане поддержки?

Спасибо за отзыв!

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

Это раньше такой ход мысли был - поэтому разработка и занимала годы - а это просто нерентабельно. Если иметь готовые кубики "embedded размера" то можно в разы быстрее решать конкретную задачу.

И каково оно, юзать С++ в задачах эмбедед? Я может быть отстал от жизни, но, как мне кажется, С++ (именно подход ООП со всеми вытекающими) в мире встраиваемых систем не очень уж подходит. Я к тому, что на С++ гораздо легче себе в ногу пальнуть, нежели с чистым Си.

К чему вопрос. Бытует мнение что работа с динамическими сущнастями, в мире embedded, это очень опасное занятие и нужно всё делать статическими единицами. Речь, конечно же, про память и объекты. Ну и есть вопросы к объему кода. Хотя, вроде бы говорят (говорят. Я не проверял) сейчас компиляторы все так хорошо ужимают, что разницы практически нет: на сях или на плюсах код написан.

Короче, вопрос для меня остается открытым. Где и когда выгодно применять С++ в проектах, или всё колбасить по-старинке на сях и в плюсах выгоды нет?

С++ вполне себе подходит для встраиваемых систем, так как "динамические сущности" не равно С++ и решается это однократным выделением динамической памяти, если в дальнейшем перераспределения памяти не происходит.

С++ выгодно применять, когда приходится оперировать большим количеством сущностей и/или требуется одновременно вести разработку еще и "ответной" части на кода, который будет крутится на PC.

главный минус C++ — слабопредсказуемое количество необходимой памяти в ОЗУ. То есть для мелких проектов ломается экономика — нужна внешняя память или жирный контроллер.

Вторая проблема 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 и прочие фишки плюсов?

Наверно, основоположником (по крайней мере в рунете) можно считать упомянутого выше Чижова, ВОТ его проект на github.

И каково оно, юзать С++ в задачах эмбедед? Я может быть отстал от жизни, но, как мне кажется, С++ (именно подход ООП со всеми вытекающими) в мире встраиваемых систем не очень уж подходит.

смотря какой эмбеддед . Возьмем например одноплатник, допустим dragon 410c (я с ним немного работал), ставим на него линукс и qt, используем С++ в разработке. И это будет эмбеддед. И тут гораздо проще работать на С++ и даже можно в динамическую память.

Где и когда выгодно применять С++ в проектах, или всё колбасить по-старинке на сях и в плюсах выгоды нет?

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

Хотя, вроде бы говорят (говорят. Я не проверял) сейчас компиляторы все так хорошо ужимают, что разницы практически нет: на сях или на плюсах код написан

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

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

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

Only those users with full accounts are able to leave comments. Log in, please.