Комментарии 10
Про C++ вместо C вообще молчу…
На счет виджетов, в принципе согласен, если нужны только виджеты, есть более легкие альтернативы, например LVGL, тоже поддержанный в Embox. Но Qt это очень крутой фреймворк, и используют его не только ради виджетов. И например, если уже есть код на Qt то его переписывание может оказаться сложной задачей. В статье же показана возможность, разработать и отладить ПО на линуксе, а затем запустить на целевой платформе.
Голубчик, про плюсы это вы зря. Если грамотно использовать, то на много интереснее и удобнее выходит.
И не нужно забывать что некоторые вещи недоступны bare-metal
Qt — невменяемая жиробасина с кучей оверхеда.
Немного интересуюсь этой темой. Подскажите, пожалуйста, где именно в QT куча оверхеда? И какие можно взять альтернативы (с соизмеримыми возможностями, конечно)?
Тут, я так понимаю, за основу взят очень старый Qt 4.8. С 5 версии они серьезно переработали потроха и, к тому же, у них есть специальная версия Qt для MCU. Увы, платная, но успешно применяемая.
Про C++ вместо C вообще молчу…
А можете чуть подробнее помолчать? Чем именно C++ не подходит для контроллеров? Только, пожалуйста, не надо про «больший размер бинарников» и «использование динамической памяти».
Первое — чушь, доказательства даже на Хабре были. Например: habr.com/ru/post/347980
Второе — это про STL, а не про C++. Есть реализации STL для контроллеров, а вообще STL использовать и не обязательно. И без нее у «плюсов» остается еще куча плюсов.
Не склонен катить бочку на QT, т.к. считаю, что более удачных, открытых и кроссплатформенных фреймворков нет. По крайней мере не знаю таких, если не брать в стороне стоящую яву.
Но с критикой невозможно не согласиться, она имеет место быть.
где именно в QT куча оверхеда
Первое что пришло в голову — это сети. Нагруженный обмен данными может проигрывать около 20% относительно сокетной реализации (некроссплатформенной). Если обмен делаете в QT малыми датаграммами, то потери выше. Если взять тонкую обвязку над сокетами, типа mongoos-a, то потери пренебрежимо малы.
Как бы это и понятно. Странно было бы считать, что за удобство не платишь. В оправдание QT можно лишь сказать, что если из-за QT провалил обмен на максимум 20%, то из-за среднестатистического программиста провалишь ещё минимум на 20%.
Чем именно C++ не подходит для контроллеров?
А дело не в плюсах. Дело в устоявшемся плюсовом код-стайле. В среднем, число вызовов, число копирований на стеке и число выделений/реаллокаций памяти в плюсах выше, чем в си. Хотите снизить число вызовов — юзайте вместо обилия геттеров (которые далеко не все инлайнятся) меньший набор функций + жертвуйте конструкторами. Хотите минимизировать число выделений? Юзайте статические массивы вместо контейнеров… В конце пути вас ждёт си.
Вообще, это всё не досужие разговорчики. Я встречал стандарты прямо запрещающие использование динамической аллокации памяти в лайф-критикал приложениях. Причин несколько и они, думаю, ясны.
И без нее у «плюсов» остается еще куча плюсов
Безусловно. Но моё личное мнение — повышаются требования к квалификации программиста. Я уверен, что смог бы писать на плюсах код под MCU, который не уступает си, НО! Стиль такого кода — сильно не в тренде, а чтобы его почувствовал на низком уровне специалист нужна квалификация. Предполагаю, что именно поэтому, к примеру, ядро linux, freertos и всевозможные HAL-слои пишутся исключительно на си, стиль кода которого сам по себе не допускает излишеств.
Надеюсь, смог донести мысли.
"Далее, собираем библиотеку Qt как embedded, т.е. С указанием опции -embedded."
А флаг embedded точно нужен? Не до конца понимаю его назначение, в интернетах пишут
"-embedded- Enable support for the embedded options. This includes the QWS window system into the build and enables so other embedded related options."
" -embedded … This will enable the embedded build, you must have a
proper license for this switch to work.
Example values for : arm mips x86 generic"
А флаг embedded точно нужен?
Ну смотря для чего, для нас это был наиболее удобный вариант. Вы пишете про QWS, это штука которая позволяет рисовать без внешних оконных систем, без него нужен например X11, а это уже совсем другие расходы по ресурсам. Кроме того нам хотелось рисовать напрямую во framebuffer, как написано в статье и QWS показался самым удобным вариантом
В Embox мы вообще использовали embedded-lite версию
Хм… Я думал, что в режим киоска — это без использования X11 и т.п.
Хм… Я думал, что в режим киоска — это без использования X11 и т.п.
Если честно не очень большой специалист в настройке Qt. Но мне кажется что нет связи между режимом киоска (не знаю что это такое) и вариантами куда отображается изображение. Нет X11 будет Wayland. Я же говорю, что можно отображать напрямую во фреймбуфер. А возможно в статье вы с помощью списка длинного параметров указали embedded вариант.
Запуск Qt на STM32. Часть 2. Теперь с псевдо 3d и тачскрином