Comments 30
Молодцы ребята, респект Вам
В посте про Qt, на который Вы сослались использовался Qt5, а у Вас Qt4. Все-таки разница существенная, может сделаете 2й заход?
А другие, более жизненные примеры есть, с виджетами, например? Ведь чтобы квадраты рисовать таких тяжёлых фреймворков не нужно
По-моему, дешевле и эффективней подключить МК к малине.
Мк берет на себя реакцию на события и обработку датчиков. Малина — помогает с велосипедами.
И железо, и софт, в итоге дешевле. А запас возможностей — сильно выше.
Все равно, в военпром нельзя даже стм32
И железо, и софт, в итоге дешевле.
А как так получается, что МК+Малина дешевле чем просто MK.
Если говорить о одиночном изделии или мелкосерийном, вполне возможно Вы правы, ведь разработка займет больше времени. Но если тиражировать тысячами, то экономия в 10 доларов вполне может окупить разработку. В приведенном посте из блога Qt об этом в частности говориться.
Если учесть, что в статье показано, как существенно сократить затраты на разработку, то есть использовать Qt прямо на микроконтроллере без существенных затрат, то выгода еще очевиднее. И например, существует код Qt, которые заказчик уже написал и отладил, ему хочется использовать более дешевое решение в виде МК, оно меньше потребляет имеет лучшие температурные режимы и так далее. Ну и конечно, устройство должно тиражироваться не в количестве 5 штук.
Все равно, в военпром нельзя даже стм32
Речь не о военпроме, но если посмотреть шире, то разрешенные в этом военпроме решения имеют достаточно маленькие ресурсы, например нет даже динамической памяти. Следовательно реально можно использовать системы с несколькими МБ ОЗУ. Ну и аналоги стм-ок в лице миландровких МК все такие есть.
Видя скорость прорисовки «анимации» становится не по себе, только и всего.
Странно, на мой взгляд вполне плавная прорисовка
Пример классный, но мне всё же кажется, что есть библиотеки несколько компактнее Qt для задач реализации UI на МК.
но мне всё же кажется, что есть библиотеки несколько компактнее Qt для задач реализации UI на МК.
Абсолютно согласен! про одну nuklear мы даже писали на хабре. Qt же на мой взгляд, сильно больше чем библиотека для рисования GUI-шек. Даже мне кажется что если дело только в GUI то лучше взять другую библиотеку!
Но если речь идет об удобной, привычной и мощьной платформе для разработки, данная задача имеет смысл. Или если уже разработано какое то ПО переписывать которое не хочется, точнее дешевле затащить на МК, чем переписывать ПО.
Но при этом, кроме отрисовки пружинящих кубиков, система мало что может сделать.
Так она и должна делать только то что ей сказано. В данном классе устройств вся функциональность определяется на этапе проектирования. То есть статическая конфигурация, чтобы лишний софт не лез на плату.
И да, конечно анимация только демонстрация возможностей. так же можно включить любое ПО на Qt. Embox соберет по файлам проекта (.pro файлам) и будет уже другой функционал.
Допустим, у меня есть хорошая годная утилитка, работающая в качестве панели управления станком: github.com/Denvi/Candle — исходный код в несколько сотен КБ, собранное приложение занимает несколько мегабайт, хотя внутри оно не очень сложное, как раз подходит для какого-нибудь M4 — небольшой буфер команд, внутреннее состояние станка, окей, есть визуализация траекторий в 3D.
Мне почему-то кажется, что на сборку форка этой панели уйдёт намного больше времени, чем написание кода с той же функциональностью с Nuklear + Tiny3DEngine.
Мне почему-то кажется, что на сборку форка этой панели уйдёт намного больше времени, чем написание кода с той же функциональностью с Nuklear + Tiny3DEngine.
Ну если цель запуск то нужно просто собрать данный проект в качестве приложения Embox. правда скорость отрисовки 3д сцен может сильно не обрадовать, но боюсь тоже самое будет и с Tiny3DEngine.
Я вот не знаю, насколько будут работать модули Qt для работы с сетью (даже если Ethernet есть аппаратно в контроллере) или хотя бы с Serial-портом.
По нашему опыту все работает очень прилично, так же как и на хосте. Запускали более серьезное приложение animated tiles (там почти 3д) по vnc (qt плагин из коробки) на большом ARM-е. Все прекрасно, правда памяти требует побольше.
Хм, спасибо, когда окажется в руках плата с экраном и внешней RAM — попробую, убедили :)
Мы тоже попробуем портировать https://github.com/Denvi/Candle, но не прямо сейчас.
И еще такой вопрос, возможно ли добавление также порта 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, так же рекомендовал бы поиграться с настройками. Сможете получить еще значительное ускорение. (Может вы уже его используете, извиняюсь, но я не увидел в статье упоминания)
Для работы с графическими интерфейсами выгоднее ставить его, так как на ядре А7 крутится обычный linux, а реалтайм обеспечит CM4.
Портирование Qt на STM32