Pull to refresh

Comments 30

В посте про Qt, на который Вы сослались использовался Qt5, а у Вас Qt4. Все-таки разница существенная, может сделаете 2й заход?

Возможно, они как раз пишут что у них в 5.8 какая-то прям новая система конфигурирования, и вероятно Qt получится еще лучше сконфигурировать. Так что да, надеюсь сделаем 2й заход :)

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

Moveblocks стандартный пример из Qt, так что думаю раз QT запустили, то и виджеты осилим. Виджеты так-то проще чем анимация, на самом деле. Надеюсь, что уже скоро и с виджетами попробуем :)

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

И железо, и софт, в итоге дешевле.

А как так получается, что МК+Малина дешевле чем просто MK.

Если говорить о одиночном изделии или мелкосерийном, вполне возможно Вы правы, ведь разработка займет больше времени. Но если тиражировать тысячами, то экономия в 10 доларов вполне может окупить разработку. В приведенном посте из блога Qt об этом в частности говориться.
Если учесть, что в статье показано, как существенно сократить затраты на разработку, то есть использовать Qt прямо на микроконтроллере без существенных затрат, то выгода еще очевиднее. И например, существует код Qt, которые заказчик уже написал и отладил, ему хочется использовать более дешевое решение в виде МК, оно меньше потребляет имеет лучшие температурные режимы и так далее. Ну и конечно, устройство должно тиражироваться не в количестве 5 штук.

Все равно, в военпром нельзя даже стм32

Речь не о военпроме, но если посмотреть шире, то разрешенные в этом военпроме решения имеют достаточно маленькие ресурсы, например нет даже динамической памяти. Следовательно реально можно использовать системы с несколькими МБ ОЗУ. Ну и аналоги стм-ок в лице миландровких МК все такие есть.
Raspberry pi zero стоит $5. Для реакции на датчики и прочее, можно подключить что попроще, например cm0, ему не надо городить 8Мб ОЗУ и так далее.

Видя скорость прорисовки «анимации» становится не по себе, только и всего.
Не устраивает скорость прорисовки на результирующем видео? то есть тут

Странно, на мой взгляд вполне плавная прорисовка
Извиняюсь, мой косяк. Вчера все было раз в 6 медленее.
Но при этом, кроме отрисовки пружинящих кубиков, система мало что может сделать.
Пример классный, но мне всё же кажется, что есть библиотеки несколько компактнее Qt для задач реализации UI на МК.
но мне всё же кажется, что есть библиотеки несколько компактнее Qt для задач реализации UI на МК.

Абсолютно согласен! про одну nuklear мы даже писали на хабре. Qt же на мой взгляд, сильно больше чем библиотека для рисования GUI-шек. Даже мне кажется что если дело только в GUI то лучше взять другую библиотеку!
Но если речь идет об удобной, привычной и мощьной платформе для разработки, данная задача имеет смысл. Или если уже разработано какое то ПО переписывать которое не хочется, точнее дешевле затащить на МК, чем переписывать ПО.

Но при этом, кроме отрисовки пружинящих кубиков, система мало что может сделать.

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

И да, конечно анимация только демонстрация возможностей. так же можно включить любое ПО на Qt. Embox соберет по файлам проекта (.pro файлам) и будет уже другой функционал.
В том и дело. Я вот не знаю, насколько будут работать модули Qt для работы с сетью (даже если Ethernet есть аппаратно в контроллере) или хотя бы с Serial-портом.

Допустим, у меня есть хорошая годная утилитка, работающая в качестве панели управления станком: github.com/Denvi/Candle — исходный код в несколько сотен КБ, собранное приложение занимает несколько мегабайт, хотя внутри оно не очень сложное, как раз подходит для какого-нибудь M4 — небольшой буфер команд, внутреннее состояние станка, окей, есть визуализация траекторий в 3D.

Мне почему-то кажется, что на сборку форка этой панели уйдёт намного больше времени, чем написание кода с той же функциональностью с Nuklear + Tiny3DEngine.
Мне почему-то кажется, что на сборку форка этой панели уйдёт намного больше времени, чем написание кода с той же функциональностью с Nuklear + Tiny3DEngine.

Ну если цель запуск то нужно просто собрать данный проект в качестве приложения Embox. правда скорость отрисовки 3д сцен может сильно не обрадовать, но боюсь тоже самое будет и с Tiny3DEngine.

Я вот не знаю, насколько будут работать модули Qt для работы с сетью (даже если Ethernet есть аппаратно в контроллере) или хотя бы с Serial-портом.

По нашему опыту все работает очень прилично, так же как и на хосте. Запускали более серьезное приложение animated tiles (там почти 3д) по vnc (qt плагин из коробки) на большом ARM-е. Все прекрасно, правда памяти требует побольше.
3D там нужно для визуализации сотни линий и положения сверла, вид по умолчанию можно сделать вообще сверху. Пусть тормозит на здоровье. На Raspberry у меня вообще пока не получилось libmesa поднять, вместо сцены чёрный прямоугольник.

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

Мы тоже попробуем портировать https://github.com/Denvi/Candle, но не прямо сейчас.
«Однако до недавних пор, мало кто задумывался о портировании Qt на микроконтроллеры» — Qt на микроконтроллерах уже достаточно давно. В 2018 показывали много демок на Embedded World прямо на девайсах (в основном qml, но виджеты тоже работают). Есть еще Boot2Qt специально для микроконтроллеров.
Но все-таки я бы не сказал, что они там давно, я не видел версию работающую из коробки, они тоже только демки показывают
Совсем не давно я закончил пушить патчи в Qt dev для поддержки RTEMS из коробки. QPA плагин к сожалению останеться commercial only, но в целом можно использовать linuxfb.
Очень круто! :) То есть уже сейчас можно попробовать самому под RTEMS запустить Qt с linuxfb?

И еще такой вопрос, возможно ли добавление также порта Qt под Embox (я имею ввиду QPA части и мб конфигов), если, например, получим показатели не хуже чем на RTEMS? Не вместо RTEMS конечно, а как альтернативу.
Да, в целом можно.

Я думаю что это возможно, но я бы для начало рекомендовал написать в developer mail list.
А почему бы вам не использовать linuxfb плагин? Судя по коду который вы показли, он очень похож на него.

Пока решили упростить qpa плагин, дабы не тащить ничего лишнего. Но вероятно попробуем linuxfb как только начнём добавлять поддержку прерываний от touchscreen'а для примеров с виджетами. Пока не смотрели как там прерывания пробрасываются в qt по-хорошему (какой-то плагин с мышью и клавиатурой у нас есть, но весьма костыльный).

Хотел внести несколько комментариев/предложений.
1. Касательно FPU. Вы используете плату STM32F746. У данной платы FPU c single precision. Этого не достатчно для JIT компиляции в QML engine.
QML engine требует FPU c double precision. Поэтому вы и не увидили никакого прироста (наверно в блоге я не достатчно точно это написал).
2. У STM32F746 есть небольшой графический ускоритель DMA2D, рекомендовал бы добавить его поддержку. Сможете получить небольшой прирост.
3. Ешё STM32F746 есть L1 cache, так же рекомендовал бы поиграться с настройками. Сможете получить еще значительное ускорение. (Может вы уже его используете, извиняюсь, но я не увидел в статье упоминания)
Спасибо! Пока до этих моментов не добрались, оптимизировали исключительно за счет вынесения разных частей в быстрые памяти, но думаю посмотрим.
Пока не попробовали, QML интересная вещь, полагаю что скоро добавим.
STMicroelectronix недавно выпустили новое семейство STM32MP15x, представляющее собой гетерогенный процессор (Cortex-A7 + Cortex-M4).
Для работы с графическими интерфейсами выгоднее ставить его, так как на ядре А7 крутится обычный linux, а реалтайм обеспечит CM4.
А новый фреймворк «QT for MCUs» на основе QML не пробовали? На первый взгляд не плохой вариант для быстрой разработки примитивного интерфейса управления без анимационных плюшек. Но он коммерческий. Вертиться все это под так называемым QT QUL (quick ultralight runtime). И, все-таки, для тяжелых интерфейсов с анимацией лучше будет использовать симбиоз с полноценным RISC процом, на примере как в комментарии выше или поискать под конкретную задачу SoC с необходимым набором интерфейсов.
Sign up to leave a comment.