Последнее обновление:
June 1, 2019

Есть мысль... Жми, напиши!
Что имеем: Постов : 179 Авторов: 1 Категорий: 38

Qt, QEventLoop and connect/disconnect lambda function

Приветствую!

Кому некогда, можно сразу прыгнуть в конец к итогу.

Бывают ситуации, когда нужно синхронно дождаться завершения асинхронного действия, при этом не подвешивая основной поток (например, не продолжать выполнение функции, пока ответ в QTCPSocket onReadyRead от сервера не придёт).   

В нашем случае для примера давайте подождём с выполнением функции, пока таймер не досчитает до 5. 

Делаем основу:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QGuiApplication>
#include <QDebug>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз

    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";
        _timer->start(5000); //-- 5 секунд в миллисекундах


        qDebug()<<"Timer END";
    }

signals:

public slots:

private:
    QTimer * _timer;
};

#endif // APPCORE_H

Но если мы запустим так, то вывод  «Timer END» произойдёт без какой-либо задержки, т.к. таймер ведёт отсчёт асинхронно в другом потоке.

Решением в «лоб» было бы подписаться на событие срабатывания таймера, объявить флаг срабатывания и в бесконечном цикле отслеживать его, как-то так, например:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
        connect(_timer, &QTimer::timeout, this, &AppCore::onTimeOut);

    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";
        _timer->start(5000); //-- 5 секунд в миллисекундах

        while (true) {
            if (_timeOut) {
                break;
            }
            QGuiApplication::processEvents();
        }

        qDebug()<<"Timer END";
    }

public slots:
    void onTimeOut()
    {
        _timeOut = true;
    }

private:
    QTimer * _timer;
    bool _timeOut=false;
};

#endif // APPCORE_H

Кстати, если бы мы не указали «QGuiApplication::processEvents();«, то слот «onTimeOut()» не вызвался бы никогда, т.к. цикл у нас бесконечный, а так мы заставляем всё таки обработать события, а заодно и не подвешивать сильно интерфейс. 

Но решение это слишком топорное и не красивое. Что бы не использовать бесконечные циклы у Qt есть QEventLoop.  Выполнение функции приостанавливается методом «exec()» и QEventLoop ждёт, пока не будет вызван метод «exit()» и лишь потом продолжается.

Делаем:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>
#include <QEventLoop>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
        connect(_timer, &QTimer::timeout, this, &AppCore::onTimeOut);

    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";

        _timer->start(5000); //-- 5 секунд в миллисекундах
        _loop.exec(); //-- Ждём, пока будет вызван exit();

        qDebug()<<"Timer END";
    }

public slots:
    void onTimeOut()
    {
        _loop.exit();
    }

private:
    QTimer * _timer;
    QEventLoop _loop;
};

#endif // APPCORE_H

Стало чуть-чуть красивее, но у нас всё ещё висит одноразовый слот «onTimeOut()» и одноразовая переменная «_loop«.  Это сейчас она одна, а если в нашем классе нужно в 5 разных местах дожидаться ответов? Как-то по 5 одноразовых слотов и переменных иметь некрасиво…

Благо в Qt начиная с 5 версии появилась возможность при соединении сигнал-слота вместо слота использовать лямбда-функцию, этой фишкой мы и воспользуемся, что бы избавиться он объявления глобального слота «onTimeOut()» и переменной «_loop»

Делаем: 

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>
#include <QEventLoop>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
    }

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";

        QEventLoop _loop;

        connect(_timer, &QTimer::timeout, [&](){
            _loop.exit();
        });

        _timer->start(5000); //-- 5 секунд в миллисекундах
        _loop.exec(); //-- Ждём, пока будет вызван exit();

        qDebug()<<"Timer END";
    }

private:
    QTimer * _timer;

};

#endif // APPCORE_H

Запускаем и ровно через 5 секунд после «Timer BEGIN» у нас выведется «Timer END»  и вроде бы добились чего хотели, но тут есть одна тонкость. Для наглядности я в лямбду добавлю вывод информации о срабатывании, вот так теперь она выглядит::

connect(_timer, &QTimer::timeout, [&_loop](){
    qDebug()<<"TIME OUT!";
    _loop.exit();
});

Допустим нам нужно в нескольких местах ждать ответа, и мы два раза вызываем функцию:

    ....
    waitFunction();
    waitFunction();
    ....

Вывод будет такой:

Timer BEGIN
TIME OUT!
Timer END
<br>Timer BEGIN
TIME OUT!
TIME OUT!
Timer END

Как видите, «TIME OUT» после второго вызова вывелось два раза! А если бы мы функцию «waitFunction()» вызвали 10 раз, то соответственно «TIME OUT» вывелось бы то же 10 раз подряд.  Так явно не должно быть! В чём дело?  А дело в том, что лямбда функция автоматически не отключается! Если забыть про эту фишку можно нарваться в том числе и на «SIGSEGV Segmentation fault», сегфолт короче. 

Решение — это не забывать отключать (disconnect signal lambda) сигнал от лямбды, но просто так это сделать не получится, т.к. это всё таки лямбда, нужно запоминать информацию, которую возвращает метод «QMetaObject::Connection conn = connet(….)«, а по ней отключать «disconnect(conn)«. 

Делаем:

void waitFunction()
{
    qDebug()<<"Timer BEGIN";

    QEventLoop _loop;

    QMetaObject::Connection conn = connect(_timer, &QTimer::timeout, [&_loop](){
        qDebug()<<"TIME OUT!";
        _loop.exit();
    });

    _timer->start(5000); //-- 5 секунд в миллисекундах
    _loop.exec(); //-- Ждём, пока будет вызван exit();

    disconnect(conn);

    qDebug()<<"Timer END";
}

Срабатывать будет  один раз и отключаться, вывод придёт в норму:

Timer BEGIN
TIME OUT!
Timer END

Timer BEGIN
TIME OUT!
Timer END

Но об  «disconnect(….)»  можно забыть, поэтому предлагаю использовать умные указатели, а именно QSharedPointer, но у него нужно не забыть реализовать отключение, т.к. сам по себе он это делать не умеет, а так как писанины получается многовато, поэтому предлагаю запилить макрос.

Итоговый код:

#ifndef APPCORE_H
#define APPCORE_H

#include <QObject>
#include <QTimer>
#include <QDebug>
#include <QGuiApplication>
#include <QEventLoop>
#include <QSharedPointer>

class AppCore : public QObject
{
    Q_OBJECT
public:
    explicit AppCore(QObject *parent = nullptr): QObject(parent)
    {
        _timer = new QTimer(this);
        _timer->setSingleShot(true); //-- Срабатывать только один раз
    }

    #define AutoDisconnect(l) \
        QSharedPointer<QMetaObject::Connection> l = QSharedPointer<QMetaObject::Connection>(\
            new QMetaObject::Connection(), \
            [](QMetaObject::Connection * conn) { /*QSharedPointer сам по себе не производит отключения при удалении*/ \
                QObject::disconnect(*conn);\
            }\
        ); *l //-- Use AutoDisconnect(conn1) = connect(....);

    void waitFunction()
    {
        qDebug()<<"Timer BEGIN";

        QEventLoop _loop;

        AutoDisconnect(conn) = connect(_timer, &QTimer::timeout, [&_loop](){
            qDebug()<<"TIME OUT!";
            _loop.exit();
        });

        _timer->start(5000); //-- 5 секунд в миллисекундах
        _loop.exec(); //-- Ждём, пока будет вызван exit();

        qDebug()<<"Timer END";
    }

private:
    QTimer * _timer;

};

#endif // APPCORE_H

Вот как-то так =)

P.S. Макросы не зло, нужно просто уметь их готовить 😉

Views :

419

Layout.fillWidth: true и Layout.preferredWidth/Layout.minimumWidth зависимость (очередная хитрость)

Сталкиваюсь иногда с некоторыми хитростями в QML, о которых, по всей видимости, приходится только догадываться, ибо то ли я проглядел это в документации, то ли этого действительно в ней не указано.

Так вот, задача: нужно три колонки одинаковой ширины.

Делаем:

import QtQuick 2.9
import QtQuick.Window 2.2
import QtQuick.Layouts 1.3

Window {
    visible: true
    width: 640
    height: 480
    title: qsTr("QMLTips&Tricks24")

    RowLayout {
        anchors.fill: parent
        spacing: 0

        Rectangle {
            color: "blue"
            Layout.fillHeight: true
            Layout.fillWidth: true            
        }

        Rectangle {
            color: "orange"
            Layout.fillHeight: true
            Layout.fillWidth: true
        }


        Rectangle{
            color: "green"
            Layout.fillHeight: true
            Layout.fillWidth: true            
        }

    }
}

Соответственно на выходе получаем:

Получилось как и задумывали.

Обновим задачу:  Оранжевая колонка должна иметь предпочтительную ширину 200 пикселей.
Делаем:

Rectangle {
    color: "orange"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Получаем:

Что-то не то, да..? 

Вот тут начинается самое интересное.

Дело в том, что Layout.prefferedWidth (а так же Layout.minimumWidth) управляет пропорционально шириной относительно соседей, когда задано Layout.fillWidth: true

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

Делаем:

Rectangle {
    color: "blue"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Rectangle {
    color: "orange"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Rectangle{
    color: "green"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Получаем:

То есть как и задумывали, три одинаковые колонки.

Теперь наглядный пример насчёт пропорционально соседям изменяемости размеров. Если мы у синего прямоугольника зададим желаемую ширину в 50, а у зелёного 100, то соответственно синий будет в 4 раза меньше оранжевого (200/50=4), а зелёный буде в два раза меньше оранжевого (200/100=2). 

То есть родитель Layout (RowLayout/ColumnLayout/GridLayout) берёт от потомков наибольший желаемый размер и относительно него пропорционально выставляет ширину всем потомкам.
Повторюсь, что так QML себя ведёт, только когда задано Layout.fillWidth: true

Делаем:

Rectangle {
    color: "blue"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 50
}

Rectangle {
    color: "orange"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 200
}

Rectangle{
    color: "green"
    Layout.fillHeight: true
    Layout.fillWidth: true
    Layout.preferredWidth: 100
}

Получаем:

Короче, считаем, что при указании preferredWidth, minimumWidth мы работаем с пропорциями относительно остальных в одном контейнере и всё. 

Почему именно так, а не иначе?  

По-моему как раз для того, что бы можно было задать поведение при растягивании/сжимании…

 

Аналогичная ситуация произойдёт, если мы оранжевой колонке захотим указать minimumWidth: 100 при fillWidth:true

Что делать, если нужно, что бы все колонки имели одинаковую ширину и заполняли всё пространство (т.е. fillWidth: true), но при этом у них (у всех или у некоторых) должна быть задана разная минимальная ширина? 

Я в таком случае прописываю у всех:  preferredWidth: 1000;  что бы желательная ширина у всех была одинаковая и обязательно больше, чем минимальная, иначе учитываться не будет (логично, да?)

Надеюсь, теперь больше с этим проблем не возникнет.

Кстати, такое же поведение будет если у компонента задано свойство implicitWidth или implicitHeight, потому что если мы не задали явно Layout.preferredWidth или  Layout.fillHeight, то берутся как раз они. Наверное вы спрашиваете: как быть, если это не просто прямоугольник, а какой-то компонент? То всё просто — оберните его в Item или Rectangle или задайте явно Layout.preferredWidth

Кстати, вот документация на лэйауты: тынц.

Вот как-то так =)

Views :

187

Конвертер картинок для Arduino LCD OLED 128×64 I2C дисплея

Пришёл вот такой дисплейчик:

Но вот нигде не нашёл для него генератора, что бы модно было конвертировать jpg/png/bmp картинку в код. 
Неспешно накалякал, выбираете любой jpg/bmp файл и получаете на выходе код:

Тестовый скетч:

#include <OLED_I2C.h>  

OLED  myOLED(A4, A5, A4); 

extern uint8_t SmallFont[];

//--PASTE GENERATED CODE HERE

void setup()
{
    myOLED.begin();
    myOLED.setFont(SmallFont);    
}

void loop() 
{
    myOLED.clrScr(); 
    myOLED.drawBitmap(0, 0, icon1, 21, 21); //-- X, Y, IMG, Width, Height 
    myOLED.update();
    delay(150);
}

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

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

Библиотека OLED_I2C.

 

Views :

3061

Компиляций libusb из исходников на Windows

Тут особо нечего рассказывать, всё не так трудно, поэтому минимум комментов.

Качаем MSYS2, ставим, запускаем  C:\msys32\mingw32.exe

pacman -Syu
pacman -Su
pacman -S git
pacman -S base-devel 
pacman -S libtool
pacman -S mingw-w64-i686-toolchain

touch /e/LibUSB2
cd /e/LibUSB2/
git clone https://github.com/libusb/libusb .
./autogen.sh
touch build-Win32
cd build-Win32
touch bin
../configure --prefix=/e/LibUSB2/build-Win32/bin --build=i686-w64-mingw32 --host=i686-w64-mingw32
make -j4
make install

Вся либа будет в /e/LibUSB2/build-Win32/bin.

Вот как-то так =)

Views :

280

Кросскомпиляция Qt 5.12 для Raspberry Pi 1,2,3 B+ под Windows

В общем на Ubuntu скомпилили, открываем пост и компилим теперь под Windows.

UPDT1: Обновлено для Qt 5.12.2 и Raspbian 2018-11-13 Stretch для Raspberry PI3 Model B+

1. Качаем актуальную версию Raspbian и с помощью WinFLASHTool  пишем её на сд карточку.

2. Так же.

3.

В дальнейшем везде будет подразумеваться х86 версия.

Качаем msys2, ставим в папку C:\SysGCC\msys2\

Качаем MinGW (у меня 730), распаковываем  в папку C:\SysGCC\mingw32 с соблюдением структуры.

Качаем Perl.

Запускаем C:\SysGCC\mingw32.exe,

pacman -Syu #попросит закрыть - закрываем, запускаем вновь и прописываем далее: 
pacman -Su 
pacman -S openssh 
pacman -S rsync
pacman -S make 
pacman -S python
pacman -S python2
pacman -S wget
pacman -S patch
pacman -S pkg-config 
pacman -S diffutils
pacman -S git

и остальное прописываем так же

4.  Качаем тулчейн и ставим в C:\SysGCC\Raspberry

5. Запускаем C:\SysGCC\Raspberry\TOOLS\UpdateSysroot.bat, нажимаем select, подключаемся к малине (пользователь «pi» пароль «raspberry») и в список синхронизации дописываем

/opt/vc/

6. Пропускаем, за нас это сделал шаг 5.

7.

cd /c/SysGCC/Raspberry
git clone git://code.qt.io/qt/qt5.git QtSources
cd QtSources
PATH=/c/Strawberry/perl/bin:$PATH
perl init-repository
git checkout 5.12 # Если нужно 5.9, то проверял с 5.9.1
git submodule update --recursive

BASEPATH=/c/SysGCC/Raspberry
PATH=$PATH:/c/SysGCC/Raspberry/bin
PATH=$PATH:/c/SysGCC/mingw32/bin
./configure -skip wayland -skip script -skip webengine -no-pch -no-kms -no-xcb -no-use-gold-linker -nomake tests -nomake examples -reduce-exports -eglfs  -release -opengl es2 -device linux-rasp-pi3-vc4-g++ -device-option CROSS_COMPILE=$BASEPATH/bin/arm-linux-gnueabihf- -sysroot $BASEPATH/arm-linux-gnueabihf/sysroot -opensource -confirm-license -platform win32-g++ -make libs -prefix $BASEPATH/qt5pi -extprefix $BASEPATH/qt5pi -hostprefix $BASEPATH/qt5 -v
make -j 4
make install

Здесь компилится для Raspberry Pi 3B+, для 1 и 2 в посте под Linux.

Если будет проблема с путями, к примеру «../../../../../../../../../../../../Raspberry/»  , то Perl должен быть скачан именно по ссылке выше и в PATH идти первее всех. Ну и очищаем и заново запускаем конфигурацию.

8. так же

9. так же

10. так же

11. так же

12. так же

12.1. так же

12.2. Путь: C:\SysGCC\Raspberry\bin\arm-linux-gnueabihf-g++
ABI: arm-linux-generic-elf-32bit

12.3. Путь C:\SysGCC\Raspberry\bin\arm-linux-gnueabihf-gdb          

12.4.  Для qmake путь C:\SysGCC\Raspberry\qt5\bin\qmake.exe

12.5. так же

14. так же

15. ????

16. PROFIT!

Views :

2626

Кросскомпиляция Qt 5.9 и Qt 5.12 для Raspberry Pi 1, Raspberry Pi 3 (B+)

Пока в разгаре новогодние праздники захотелось попробовать в действии Raspberry Pi (Здесь для модели 3 B+, но так же подходит и для 1,2), а именно чего-нибудь для неё написать, хотя бы Hello World с помощью Qt. Ставить весь Qt на саму малинку как-то долго, да и пока на ней компилируется простейшая программа можно упиться в усмерть, поэтому будем настраивать кроссс-компиляцию, что бы всю разработку вести на своём пк (Ubuntu 16.10  x64).

Приступаем.

Обновлено для Qt 5.9.1 и Raspbian 2017-09-08 Stretch для Raspberry PI3 Model B
Обновлено для Qt 5.12.2 и Raspbian 2018-11-13 Stretch для Raspberry PI3 Model B+

1. Первым делом необходимо скачать образ ОС для малинки, это будет raspbian (можно и Lite (без X), тогда получится сделать «kiosk mode») и залить её на SD карточку, которая уже должна быть воткнута.

mkdir ~/Projects/RaspberryPI 
cd ~/Projects/RaspberryPI 
wget https://downloads.raspberrypi.org/raspbian_latest # Обычный
#Если нужен облёгчённый, бек иксов: wget https://downloads.raspberrypi.org/raspbian_lite_latest
unzip raspbian_latest  
#unzip raspbian_lite_latest
sudo dd if=2018-11-13-raspbian-stretch.img of=/dev/mmcblk0 bs=4M 
#sudo dd if=2018-11-13-raspbian-stretch-lite.img of=/dev/mmcblk0 bs=4M 
sync
Что бы узнать адрес флэшки, наберите lsblk

Если так случалось, что нет картридера, то залить прошивку можно и на винде с помощью win32diskimager (запускать от рута)

2. Когда заливка завершиться, вытаскиваем СДшку и загружаем с неё малинку.

Теперь её немножко надо настроить, переходим Menu -> Preferences -> Raspberry Pi configuration. 
Либо в консольке(Menu->Accessories->Terminal) :

sudo raspi-config

Расширяем систему на весь объём флэшки: Advanced options->expand filesystem,
включаем ssh в Interfacing options,
подрубаемся к wifi, 
в Advanced options->GL Driver включаем GL (Full KMS) и перезагружаемся.

Вбиваем в консольке ifconfig, запоминаем айпишник, на этом пока что всё.

Кстати, о настройке WIFI raspbian из консоли (если без графического интерфейса, т.е. lite версия):

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf
#Дописываем:
network={
    ssid="The_ESSID_from_earlier"
    psk="Your_wifi_password"
}

#Выходим с сохранением и перезагружаемся:
sudo reboot

3. Приконнектимся к малинке по ssh, раскомментим получение исходников пакетов, установим нужные пакеты и создадим нужные папки

ssh pi@192.168.2.101 (пароль по дефолту "raspberry")
sudo nano /etc/apt/sources.list  #расскомментить строчку с deb-src
sudo apt-get update
sudo apt-get upgrade
sudo rpi-update #Обновим ядро и прочее основное
reboot
sudo apt-get install -y libudev-dev libinput-dev libts-dev libxcb-xinerama0-dev libxcb-xinerama0
sudo apt-get install -y libfontconfig1-dev libfreetype6-dev libx11-dev libxext-dev libxfixes-dev libxi-dev libxrender-dev libxcb1-dev libx11-xcb-dev libxcb-glx0-dev
sudo apt-get install -y libxcb1 libxcb1-dev libx11-xcb1 libx11-xcb-dev libxcb-keysyms1 libxcb-keysyms1-dev libxcb-image0 libxcb-image0-dev libxcb-shm0 libxcb-shm0-dev libxcb-icccm4 libxcb-icccm4-dev libxcb-sync1 libxcb-sync-dev libxcb-render-util0 libxcb-render-util0-dev libxcb-xfixes0-dev libxrender-dev libxcb-shape0-dev libxcb-randr0-dev libxcb-glx0-dev libxcb-xinerama0-dev
sudo apt-get install -y build-essential libgl1-mesa-dev freeglut3 freeglut3-dev mesa-common-dev libglapi-mesa libosmesa6 mesa-utils
sudo apt-get install -y libwayland-egl1-mesa libraspberrypi-dev  freeglut3-dev freeglut3   libegl1-mesa libegl1-mesa-dev libegl1-mesa-drivers libepoxy-dev libepoxy0 libgbm-dev  libgbm1  libgegl-0.3-0  libgegl-dev libva-egl1 mesa-utils-extra
sudo apt-get install -y libraspberrypi0 libva-egl1 libegl1-mesa libegl1-mesa-drivers gegl 
sudo apt-get install -y libglfw3-dev libgles2-mesa-dev
sudo apt-get build-dep qt4-x11 #ради зависимостей
sudo apt-get build-dep libqt5gui5 #ради зависимостей
#Чувствую, большую половину из этого не надо, но я не знаю какую точно т.к. решал проблемы с OpenGL и прочичи либами
sudo mkdir /usr/local/qt5pi
sudo chmod -R 777 /usr/local/qt5pi

4. Так, возвращаемся к хосту, качаем тулчейн:

mkdir raspi
cd raspi
git clone https://github.com/raspberrypi/tools

5. Создаём sysroot и через rsync синхронизируем его с малиновым, что бы оттуда взять заголовочники, либы и компилятор

IP=192.168.2.101 # айпишник малинки
rsync -avz pi@$IP:/lib sysroot # опять идём пить кофе
rsync -avz pi@$IP:/usr/include sysroot/usr
rsync -avz pi@$IP:/usr/lib sysroot/usr # можно сходить просраться
rsync -avz pi@$IP:/opt/vc sysroot/opt

6. Дальше необходимо поправить символьные ссылки, что бы они были относительно нашей скопированной sysroot, для этого есть готовый скриптик, качаем и запускаем:

wget https://raw.githubusercontent.com/riscv/riscv-poky/master/scripts/sysroot-relativelinks.py
chmod +x sysroot-relativelinks.py
./sysroot-relativelinks.py sysroot

7. Теперь можно склонировать Qt, сконфигурировать и запустить на компиляцию

git clone git://code.qt.io/qt/qt5.git QtSources
cd QtSources
perl init-repository
git checkout 5.12 # Если нужно 5.9, то проверял с 5.9.1
git submodule update --recursive


BASEPATH=~/Projects/RaspberryPI/raspi # базовый путь, где все наши манипуляции происходят (без слэша на конце)
./configure -skip wayland -skip script -skip webengine -no-pch -no-kms -no-xcb -no-use-gold-linker -nomake tests -nomake examples -reduce-exports -eglfs  -release -opengl es2 -device linux-rasp-pi3-g++ -device-option CROSS_COMPILE=$BASEPATH/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf- -sysroot $BASEPATH/sysroot -opensource -confirm-license -make libs -prefix $BASEPATH/qt5pi -extprefix $BASEPATH/qt5pi -hostprefix $BASEPATH/qt5 -v
make -j4 # и поспим часик (4 - количество ядер проца, для ускорения)
make install

Чтиво по некоторым фичам: https://doc.qt.io/qt-5/embedded-linux.html, https://doc.qt.io/archives/qt-5.8/configure-options.html, https://doc.qt.io/qt-5/linux-requirements.html, https://doc.qt.io/archives/qt-4.8/configure-options.html

Если возникли ошибки при сборке и нужно переконфигурировать с другими параметрами, не забудьте удалить предыдущий результат, набрав «git clean -dxf»  и «make clean» иначе будет ещё хуже =)
Для Qt < 5.9.1 нужен -device linux-rpi3-g++
При конфигурации отключён QtWebKit! Для Qt < 5.10 нужно указывать «-skip webkit»     Кому нужен уберите «-skip webengine». 
Возможно, нужно так же указать -qt-xcb (и убрать -no-xcb), что бы нормально работали QWidgets, у меня же все приложения только с QML. Так же нужно указать  «-platform xcb»  если у вас gui версия (обычная, а не lite)
При ошибке с JavaScriptCore/wtf/Platform.h:370:6: error: #error «Not supported ARM architecture» добавьте к конфигурации «-skip script» или добавьте к make флаг:»make CFLAGS=»${CFLAGS}-D__ARM_ARCH_7M__»»  (взял из /3rdparty/javascriptcore/JavaScriptCore/wtf/Platform.h)
При ошибке с PCRE2: PCRE2_CODE_UNIT_WIDTH, LINK_SIZE и прочие мессаджы с ней связанные  (отвечает за регулярные выражения)  можно либо отключить ( в конфиге «-no-pcre»), но почему-то у меня не было такого параметра,
либо прописать все дефайны вручную: make CFLAGS=»${CFLAGS} -ldl -DPCRE2_CODE_UNIT_WIDTH=16 -DHAVE_INTTYPES_H=1 -DHAVE_MEMMOVE=1 -DHAVE_LIMITS_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DLINK_SIZE=2 -DMATCH_LIMIT=10000000 -DMATCH_LIMIT_RECURSION=10000000 -DMAX_NAME_COUNT=10000 -DMAX_NAME_SIZE=32 -DNEWLINE_DEFAULT=2 -DPARENS_NEST_LIMIT=250 -DSUPPORT_UNICODE»  причина этому — почему-то не подключается файл config.h (Расположен qtbase/src/3rdparty/pcre2/src/config.h), где прописаны все эти дефайны.
При ошибке с zlib, можно её отключить -no-zlib (скорее всего каких-то либ на хосте нехватает, но т.к. мне было не важно, не стал разбираться, остальных проблем хватило)
При ошибке «ERROR: The OpenGL functionality tests failed!
You might need to modify the include and library search paths by editing QMAKE_INCDIR_OPENGL[_ES2],
QMAKE_LIBDIR_OPENGL[_ES2] and QMAKE_LIBS_OPENGL[_ES2] in the mkspec for your platform.» ИЛИ «In function `QEGLPlatformContext::getProcAddress(char const*)’:
qeglplatformcontext.cpp:(.text+0xa4): undefined reference to `dlsym'»  для Raspbian Stretch нужно подредактировать nano ./qtbase/mkspecs/devices/linux-rasp-pi3-g++/qmake.conf  и изменить названия либ «-lEGL» и «-lGLESv2» на  «-lbrcmEGL» и «-lbrcmGLESv2» так как названия в /opt/vc/lib/ отличаются.

Возможно лучше будет использовать в -device «linux-rasp-pi3-vc4-g++»

Так же возможна проблема с тем, что  EGLFS Raspberry Pi ………………. no, в таком случае файлик нужно поправить, указав правильные пути.
Моя версия:
show

В случае ошибки  «error: invalid use of incomplete type ‘X509 {aka struct x509_st}’«, то это баг Qt: https://bugreports.qt.io/browse/QTBUG-52905. Исправления будут в версии 5.10, так что либо отключайте ssl при конфигурации: «-no-openssl» либо даунгрейдите openssl до 1.0

8. Теперь закинем на малинку скомпилированные библиотеки и заголовочники Qt:

cd ../
rsync -avz qt5pi pi@$IP:/usr/local

9. Ну и можно собрать пример и закинуть на малинку:

cd QtSources/qtbase/examples/opengl/qopenglwidget
$BASEPATH/qt5/bin/qmake
make
scp qopenglwidget pi@$IP:/home/pi

10. На девайсе необходимо дать знать линковщику о наших либах, а так же создать qt.conf в папке, откуда будем запускать все Qt приложения:

ssh pi@192.168.2.101 (пароль по дефолту "raspberry")
echo /usr/local/qt5pi/lib | sudo tee /etc/ld.so.conf.d/00-qt5pi.conf
echo QT_PLUGIN_PATH=/usr/local/qt5pi/plugins/ | sudo tee -a /etc/environment
echo QT_QPA_FONTDIR=/usr/share/fonts/truetype/dejavu | sudo tee -a /etc/environment
printf "[Paths]\nPlugins=/usr/local/qt5pi/plugins\nQml2Imports=/usr/local/qt5pi/qml" | sudo tee ~/qt.conf
cd /usr/local/qt5pi/lib
sudo ldconfig
При проблеме «QFontDatabase: Cannot find font directory /home/pi/lib/fonts.
Note that Qt no longer ships fonts. Deploy some (from http://dejavu-fonts.org for example) or switch to fontconfig.»  нужно указать, где лежат шрифты, для этого добавим переменную окружения (выше уже добавлена) : «echo QT_QPA_FONTDIR=/usr/share/fonts/truetype/dejavu | sudo tee -a /etc/environment» видимо какую-то опцию забыл в конфиге добавить, наверное «-fontconfig«.

Перезагружаем малинку.

11. Но запускать ещё рано, у rasbian по дефолту грузиться mesa драйвер и opengl пахать не будет по нормальному, поэтому заставим её использовать нужный:

Не факт! Сначала всё таки лучше попробовать запустить =)
sudo rm /usr/lib/arm-linux-gnueabihf/libEGL.so.1.0.0 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0
sudo ln -s /opt/vc/lib/libEGL.so /usr/lib/arm-linux-gnueabihf/libEGL.so.1.0.0
sudo ln -s /opt/vc/lib/libGLESv2.so /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0
sudo ln -s /opt/vc/lib/libEGL.so /opt/vc/lib/libEGL.so.1
sudo ln -s /opt/vc/lib/libGLESv2.so /opt/vc/lib/libGLESv2.so.2

Вот теперь наконец-то можно запустить пример! Он на малинке /home/pi/qopenglwidget

Если не запускается, в консольке прописываем

export QT_LOGGING_RULES=qt.qpa.*=true
./qopenglwidget

И гуглим ошибки.

Если совсем не запускается, то прописываем:

ldd ./qopenglwidget

И смотрим по правильному адресу ли лежат библиотеки и всех ли хватает. Потом гуглим на тему ldconfig.

Если будет в выводе:

* failed to add service - already in use?

То подправим файлик «sudo nano /boot/config.txt», убрав «dtoverlay=vc4-kms-v3d» (или закомментировать) и перезагрузиться.

Возможно, стоит при конфигурации указать «-device linux-rasp-pi3-vc4-g++» (при необходимости подправить названия библиотек).

12. С этим разобрались, теперь настроим QtCreator что бы можно было компилить и запускать на малинке в один клик:

12.1. Параметры->Устройства->Добавить
Обычное Linux-устройство
название на свой вкус и цвет
вводим айпишник, логин и пароль
завершить

12.2. Параметры->Сборка и запуск->Компиляторы->Добавить
GCC -> C++
Название: Raspberry PI3 GCC
Путь: /home/pavelk/Projects/RaspberryPI/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++

12.3. Параметры->Сборка и запуск->Отладчики->Добавить
Название: Raspberry PI3 GDB
Путь: /home/pavelk/Projects/RaspberryPI/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gdb

12.4. Параметры->Сборка и запуск->Профили Qt->Добавить
Название: Qt 5.9.1 Raspberry PI3
Путь: /home/pavelk/Projects/RaspberryPI/qt5/bin/qmake

12.5. Параметры->Сборка и запуск->Комплекты->Добавить
Название: Raspberry PI3
Тип устройства: Обычное Linux-устройство
Устройство: выбираем добавленное из первого шага
Компилятор C++: Raspberry PI3 GCC
Отладчик: Raspberry PI3 GDB
Профиль Qt: Qt 5.9.1 Raspberry PI3

12.6. Нажимаем «Применить».

14. Создаём новый проект, в *.pro файл добавляем:

INSTALLS        = target
target.path     = /home/pi

Компилим и после завершения проект должен запуститься на малинке.

Вот как-то так в общем =)

P.S. Большая часть была взята с https://wiki.qt.io/RaspberryPi2EGLFS с моими небольшими правками — думал всё сложнее будет =)

 

Views :

10001

Программирование и отладка STM32F3 Discovery в QtCreator под Windows

Впринципе, алгоритм действий точно такой же, как и в предыдущем посте под Ubuntu

Обновил ссылку на новый ARM GCC

Здесь приведу лишь отличия по пунктам

  1. Качаем  драйвер, распаковываем и ставим. Вместо ST-Link поставим OpenOCD  , скачиваем, распаковываем в любую папку.
  2. так же
  3. Качаем GCC ARM с https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads (справа в списке экзешник) и ставим.  отладчик qtcreator-gdb-7-7-mingw32_nt-6-1-i686 (т.к. для Qt Creator нужно, что бы он был с поддержкой питона), распаковываем в любую папку и прописываем полный путь, имя на ваше усмотрение.
  4. Путь компилятораC:\Program Files (x86)\GNU Tools ARM Embedded\6 2017-q1-update\bin\arm-none-eabi-gcc.exe (либо в ту папку, куда поставили)
  5. При добавлении выбираем OpenOCD, запуск в режиме pipe,
    исполняемый файл: прописываете полный путь до OpenOCD.exe,
    файл конфигурации ставите <full path>\openocd-0.9.0\scripts\board\stm32f3discovery.cfg  под свою плату.
  6. Также
  7. Также

Вот как -то так =)

Если вылетает при отладке, либо при её завершении, поставьте в Qt Creator -> Инструменты -> Параметры -> Отладчик -> GDB, расширенные
галку у «Использовать асинхронный режим для работы с программой»
Если будет ошибка «Unknown remote qXfer reply: OK», то см. пункт 5.1 из статьи для Ubuntu

P.S  Вместо OpenOCD можно использовать старую добрую st-link-utility под Windows, но она старовата и, как мне кажется, тормознута.

Views :

2138

Программирование и отладка STM32F3 Discovery в QtCreator под Ubuntu

Спустя три года опять решил поиграться с STM32F, но уже вплотную.

В этот раз в роли IDE и дебагера будет выступать QtCreator т.к. в новых версиях есть плагинчик для работы с голыми устройствами.

Ось — Ubuntu 16.04, под Windows тут недалеко.

1.  Поставим сам отладчик для STM т.е. gdb сервер

Устанавливаем всё необходимое для сборки:

sudo apt-get install libusb-1.0-0-dev

Надеюсь CMake и GCC уже стоят.

Для этого клонируем репозиторий и собираем ST-Link Utility

cd ~/Projects/ST-Link-Utility
git clone https://github.com/texane/stlink.git .
make release
cd build/Release
sudo make install
sudo ldconfig
sudo udevadm control --reload-rules
sudo  udevadm trigger

Вот впринципе сервер скомпиллен, запускать его для вывода справки:

st-util -h

2. Включаем в QtCreator плагин Help -> About Plugins -> галка напротив BareMetal и перезапускаем QtCreator

3. Дальше необходимо поставить компилятор и отладчик для архитектуры ARM

sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
sudo apt-get update
sudo apt-get install gcc-arm-embedded

4. Добавляем их в QtCreator

Preferences -> Build & Run -> Compillers -> Add -> GCC

Название на ваше усмотрение, у меня: arm-none-eabi-gcc

Путь прописываем такой: /usr/bin/arm-none-eabi-gcc

Preferences -> Build & Run -> Debuggers -> Add

Название на ваше усмотрение, у меня: arm-none-eabi-gdb 

Путь прописываем такой: /usr/bin/arm-none-eabi-gdb 

5. Создадим устройство, переходим в Preferences ->BareMetal -> Add ST-Link

название на ваше усмотрение, у меня ST-Link-Utility

режим запуска: TCP/IP

исполняемый файл: st-util

хост: localhost, порт: 4242

5.1 Нужно дать отладчику дополнительное время для ожидания подключения:

Options->Debugger->GDB->Additional Startup Commands и прописать

set remotetimeout 10

6. Теперь добавляем комплект сборки:

Preferences -> Build & Run -> Kits -> Add

Название на ваше усмотрение, у меня Qt for Bare Metal

Тип устройства: Bare Metal

Устройство: Нажимаете Manager -> Add -> Bare Metal

Название на ваше усмотрение, у меня ST-Link1

Тип сервера gdb:  ST-Link-Utility (из предыдущего шага)

Компилятор:  как задали в предыдущем шаге, у меня arm-none-eabi-gcc

Отладчик: как задали в предыдущем шаге, у меня arm-none-eabi-gdb

Профиль Qt: отсутствует

7. Так, с подготовкой закончили, создаём новый проект, импортировав его шаблон из Git репозитория File-> New -> Import -> Git.

Репозиторий с шаблоном: https://github.com/Riflio/STM32F3DiscoveryQtCreatorTemplate

Путь выбираете свой.

Смените комплект на Qt for Bare Metal и можно наконец то прожать Run, в окне вывод приложения должно появиться примерно это:

Отладка запущена
st-util 1.2.0-147-g3de5cf0
Flash page at addr: 0x08000000 erased
Flash page at addr: 0x08000800 erased
Flash page at addr: 0x08001000 erased

И светодиоды должны начать зажигаться по кругу.

Если вылетает при отладке, либо при её завершении, поставьте в Qt Creator -> Инструменты -> Параметры -> Отладчик -> GDB, расширенные
галку у «Использовать асинхронный режим для работы с программой»
Если будет ошибка «Unknown remote qXfer reply: OK«, то см. пункт 5.1

P.S. Как создавать шаблон под другие контроллеры?
Сделать его достаточно просто, потребуется CMSIS — в ней содержатся описания для доступа к регистрам периферии и STM32F30x_StdPeriph_Driver (в новых версиях переименован в HAL)
Всё это ищется в недрах сайта st.com    ldscripts были найдены в каком-то демо-проекте 😀

Вот как-то так =)

Views :

2841

Ubuntu LTSP fat clients install OPENCHROME drivers

На этот раз достался очередной толстый клиент, но с видяхой VIA VX900, подключил в сеть и опять облом: картинка вся в мыле, не то разрешение и не работает OpenGL, при попытке узнать как он там:

glxinfo

Получаем кучу

Xlib:  extension "GLX" missing on display ":0.0".

Понятно дело, в предыдущий раз были поставлены дрова на Нвидию т.к. остальные клиенты на ней, а теперь зоопарк.

Чтож, добавим в эот зоопарк дрова на VIA VX900, а именно свободные openchrome

Переходим в рут к ltsp, подключаем нужные разделы и ставим дрова:

sudo su
export LTSP_HANDLE_DAEMONS=false
chroot /opt/ltsp/i386
mount -t proc proc /proc
apt-get install xserver-xorg-video-openchrome

разумеется нужно в lts.conf указать конкретный драйвер:

[client mac]
   XSERVER=openchrome

Можно попробовать перегрузиться, но по glxinfo опять облом =(

Смотрим /var/log/xorg.0.log, а там

 LoadModule: "glx"
...
Module glx: vendor="NVIDIA corporation"

Походу, что-то не оттуда грузиться, поэтому сделаем свой xorg.conf.openchrome, который укажем в настройках lts.conf и засунем в него портянку (взял из гугла), где в секции FIles укажем дефолтные пути загрузки:

nano /etc/X11/xorg.conf.openchrome
xorg.conf.openchrome

и пропишем в lts.conf его явно:

[client mac] 
X_CONF=/etc/X11/xorg.conf.openchrome

Можно пробовать перезагрузиться, разрешение должно прийти в норму, а вот с glxinfo опять облом, опять же смотрим xorg.0.log

AIGLX error: dlopen of /usr/lib/xorg/modules/drivers/i965_dri.so failed (/usr/lib/xorg/modules/drivers/i965_dri.so: undefined symbol: _glapi_set_dispatch)

Вот падла, что-то опять не оттуда загрузил, проверяем откуда libglx.so берёт зависимости:

ldd /usr/lib/xorg/modules/extensions/libglx.so

а там

libGL.so.1 => /usr/lib/nvidia-340/libGL.so.1

Бля, тащит libGL от Нвидии. Ладно, значит Нвидиа подсунула в ld свои настройки, идём в /etc/ld.so.conf.d смотрим в *.conf файлах отголоски Нвидии и заменяем на папку, откуда по идее должен быть libGL.so.1 (можно узнать, заюзав find / -name «libGL.so.1»)

/usr/lib/i386-linux-gnu/mesa

Ну и не забываем обновить кэш ld:

ldconfig

Обновляем образ, перегружаем клиента, радуемся,

ha_ha
Таким макаром мы сломали загрузу дров Нвидии.

Создадим и для неё отдельный xorg.conf.nvidia

xorg.conf.nvidia

не забудем прописать в lts.conf для клиентов с Нвидиа карточками

[client mac] 
X_CONF=/etc/X11/xorg.conf.nvidia

Но это ещё не всё…

Дело в том, что Nvidia подменяет системный libGL своим…, а мы заменив пути в /etc/ld.so.conf.d   тем самым указали использовать системный.

и через xorg.conf это никак не настроить =((    Тоесть придётся перед загрузкой клиента заранее прописывать какой там путь должен быть.

Как это сделать более элегантно я не придумал, кроме как запускать скрипты из rc.local

 

 

Вот как-то так =)

Views :

332

Ubuntu LTSP fat clients install NVIDIA drivers

Раздобыл тут на днях парочку толстых клиентов, но радость была недолгой, т.к. после подключения к сети картинка была вся в мыле и настройки не помогали.

Пришлось поплясать с бубном, что бы внедрить в дистрибутив драйвера от Нвидии, т.к. простой установкой nvidia-current дело не обошлось и всё равно грузился драйвер vesa.

Чтож, погнали:

переключаемся в рут к ltsp и монтируем нужные разделы:

sudo su
export LTSP_HANDLE_DAEMONS=false
chroot /opt/ltsp/i386
mount -t proc proc /proc

обновим систему:

sudo su
apt-get update
apt-get dist-upgrade

снесём отголоски предыдущих установок:

apt-get remove --purge nvidia-*
apt-get autoremove

Но это потянет за собой и оболочку, поэтому её нужно вернуть обратно (замените на свою, у меня lubuntu):

apt-get install lubuntu-desktop

установим заголовочники ядра и утилиты для пересборки:

apt-get install dkms build-essential linux-headers-generic

выпилим намертво vesa:

echo options nouveau modeset=0 | tee -a /etc/modprobe.d/nouveau-kms.conf
echo 'nouveau' | sudo tee -a /etc/modules
update-initramfs -u
nano /etc/modprobe.d/blacklist-nouveau.conf
>>blacklist nouveau
>>blacklist lbm-nouveau
>>options nouveau modeset=0
>>alias nouveau off
>>alias lbm-nouveau off

Что бы наверняка, можно вообще удалить её (не забудьте глянуть будет ли оболочка в списке зависимостей, если что — вернуть обратно, как-написано выше ):

apt-get --purge remove xserver-xorg-video-nouveau 

ну и ставим новые дрова (гляньте на сайте Нвидии какие подходят):

apt-get install nvidia-340

закругляемся:

umount /proc
exit
sudo ltsp-update-kernels
sudo ltsp-update-image

Осталось только в когфиге lts.conf прописать у клиентов какой драйвер использовать:

[client mac]
   XSERVER=nvidia

После перезагрузки клиента можно глянуть какие дрова используются:

lspci -k| grep -EA2 'VGA|3D'

Вот как-то так =)

 

 

 

 

Views :

316