Последнее обновление:
November 20, 2017

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

Печатаем из Qt на онлайн фискальнике ККТ PAYONLINE-01-ФА

В связи с очередным злоебучим ёбаным (по моему мнению) законом 54-ФЗ пришлось клиентам резко обновлять кассы и выкидывать из своего кармана 40 штук, что бы поменять шило на полноценный анальный зонд.

Я бы да же этому был бы рад из-за возможности заработать на обновлении, но вот что-то радоваться чужому горю вообще не фонтан.

В общем, подключаем приблуду по микро USB (ком-порта у меня в ноуте нет), заходим на оф. сайт, качаем и драйвер «USB VCOM«.

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

С драйвером мы будем работать через ActiveX (старовато, ну а хули делать. Радует немного, что Qt поддерживает эту технологию).

Создаём новый проект (у меня консольное приложение), создаём в проекте папку activex, в неё кидаем саму либо. В неё же сгенерируем заголовочник и исходник.

C:\Projects\KKT-PAYONLINE-01-FA\KKT-PAYONLINE-01-FA\activex
C:\Qt\5.9.2\mingw53_32\bin\dumpcpp DrvFR.dll

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

В папке должно появится два файла: «drvfrlib.h» и «drvfrlib.cpp» — они то нам и нужны, добавляем их в проект.

В настройках проекта («*.pro» файле) подключаем пару модулей 

QT += axcontainer widgets

Они нам нужны для работы с ActiveX.

Наша цель сейчас подключиться к фискальнику, проверить кассовую смену (если истекла — печатаем z-отчёт, если закрыта — открываем, иначе нам ничего не сделать больше), делаем продажу, отключаемся.

Код с комментами, надеюсь ясно, «main.cpp«:

#include <QCoreApplication>
#include <QApplication>
#include <QDebug>

#include "activex/drvfrlib.h" //-- Подключаем заголовочник либы
using namespace DrvFRLib; //-- Сразу задаём в каком пространстве имён будем работать

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);
    qDebug()<<"Started!";

    DrvFR * fr = new DrvFR(0, 0); //-- Создаём класс драйвера

    //-- Подключаемся к поебени
    fr->SetConnectionType(0); //-- Метод её подключения к нам, 0-локально
    fr->SetProtocolType(0); //-- Вервия протокола, 0-стандартная
    fr->SetComputerName("HCSTerminal"); //-- Задаём имя, под которым она нас будет знать
    fr->SetTimeout(0); //-- Сколько будет ждать ответа (рекомендую 0, иначе будут сюрпризы)
    fr->SetComNumber(3); //-- Устанавливаем на каком com-порту висит (COM3 - в моём случае)
    fr->SetBaudRate(115200); //-- Устанавливаем скорость подключения (115200 - дефолтная)
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ по дефолту)
    qDebug()<<"Connect"<<fr->Connect();


    //-- Проверим состояние
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ)
    qDebug()<<"EcrStatus"<< fr->GetECRStatus();
    qDebug()<<"EcrMode"<< fr->ECRMode(); //-- Подробнее на стр. 64. Сейчас нас интересует: 4-смена закрыта, 3-смена открыта, но кончилась (нужно напечатать Z-отчёт с гашением)
    qDebug()<<fr->ECRModeDescription();



    //-- Печатаем z-отчёт с гашением
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ)
    fr->PrintReportWithCleaning();
  
      //-- Откроем новую смену
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ)
    fr->OpenSession(); //-- открывает смену
    

    //-- Начинаем формирование нового чека
    fr->SetCheckType(0); //-- Устанавливаем тип нового чека, 0-продажа
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ)
    qDebug()<<"OpenCheck"<<fr->OpenCheck();
    qDebug()<<"Result"<<fr->ResultCode()<<fr->ResultCodeDescription();
    
    //-- Добавляем позиции продажи
    fr->SetQuantity(1.0); //-- Устанавливаем количество
    fr->SetPrice(3); //-- Устанавливаем цену
    fr->SetStringForPrinting("Проверка печати"); //-- Описание товара
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ)
    fr->SetDepartment(1); //-- Задаём отдел продажи (если хуёвин несколько, что бы отличать)
    qDebug()<<"Sale result"<<fr->Sale();


    //-- Завершаем формирование чека, после закрытия выйдет на печать
    fr->SetSumm1(3); //-- Сумма оплаты наличными, если несколько типов оплат, то соответственно fr->setSumm2(); Если сумма по всем позициям будет не совпадать, то на чеке автоматически будет выведена сдача.
    fr->SetStringForPrinting("==="); //-- В чеке будет двойная линия
    fr->SetPassword(30); //-- Задаём пароль оператора (30 - админ)
    qDebug()<<"Check status"<<fr->CloseCheck();
    
    //-- Отключаемся
    fr->Disconnect();

    delete fr;

    qDebug()<<"Ended!";
    return a.exec();
}

Вот как-то так выглядит алгоритм печати чека (продажи). Если какой-то метода вернёт что-то отличное от 0, значит произошла ошибка. Разумеется каждый раз печатать z-отчёт и открывать смену не нужно, как и писал выше, нужно проверять сначала, но для примера не стал (лень). 

Если будет ругаться на «enum TBarcodePrintType«, то просто закомментите в двух местах.

А вот теперь попробуем  продать товар с ценой, где есть копейки:

....
fr->SetPrice(3.23);
....
fr->SetSumm1(3.23);
....

Облом, да? Дробная часть у цена откинулась наглухо. А дело в том, что в документации у цены стоит тип «Cyrrency» (Денежный).

Какого хуя их не устраивало просто хранить в копейках для меня загадка (впрочем, ничего нового, скорее всего разработчики не на плюсах).
В C++ разумеется такого идиотского типа нет, поэтому dumpcpp нам его заменил на qlonglong, но вот про извращения с дробной частью он не знал.

Придётся ему рассказать, а следовательно перекомпилировать модуль ActiveQt, по пути: «C:\Qt\5.9.2\Src\qtactiveqt\src\activeqt».  Сам виновник: container/qaxbase.cpp».

Надеюсь, отметили установку исходников. Если нет, то запускаете UpdateManager и выкачиваете исходники.

Открываем «container/qaxbase.cpp», в районе строки 2002 находим:

case VT_CY:
        str = "qlonglong";

Меняем на:

case VT_CY:
        str = "double";

Немного не правильно, но лучшего решения я не вижу, предлагайте в комментах.

Компилим:

cd C:\Qt\5.9.2\Src\qtactiveqt\src\activeqt
set PATH=C:\Qt\5.9.2\mingw53_32\bin;%PATH%
set PATH=C:\Qt\Tools\mingw530_32\bin;%PATH%
qmake
mingw32-make
mingw32-make install

Пути не забудьте на свои поменять.

После этого заново генерируем исходник и заголовочный из ActiveX.

Вот как-то так.

Views :

9

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 :

7

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

Сталкиваюсь иногда с некоторыми хитростями в 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 пикселей.
На тот случай, если мы не будем ставить Layout.fillWidth в true, ну что бы он занимал какое-то место по умолчанию.

Делаем:

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

Получаем:

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

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

Дело в том, что Layout.prefferedWidth управляет пропорционально шириной относительно соседей, когда задано 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
}

Получаем:

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

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

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

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

Views :

5

Конвертер картинок для 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 :

13

Компиляций 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 :

47

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

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

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

2. так же.

3.

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

Качаем MinGW 4.9.2, распаковываем в папку C:\SysGCC\mingw32

Качаем Python 2.7.x

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

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

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

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 --recursive https://github.com/qt/qt5 -b 5.7 Qt57Sources
cd Qt57Sources
BASEPATH=/c/SysGCC/Raspberry
PATH=$PATH:/c/SysGCC/Raspberry/bin
PATH=$PATH:/c/SysGCC/mingw32/bin
./configure -skip wayland -c++std 11 -skip webkit -release -opengl es2 -device linux-rasp-pi-g++ -device-option CROSS_COMPILE=$BASEPATH/bin/arm-linux-gnueabihf- -sysroot $BASEPATH/arm-linux-gnueabihf/sysroot -opensource -confirm-license -platform win32-g++ -xplatform linux-arm-gnueabihf-g++ -skip qtscript -make libs -prefix $BASEPATH/qt5pi -extprefix $BASEPATH/qt5pi -hostprefix $BASEPATH/qt5 -v
make -j 4
make install

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

Для Qt 5.7 нужно применить патчик:

wget http://pavelk.ru/wp-content/uploads/qt57raspberrypi.patch
patch -p1 < qt57raspberrypi.patch

8. так же

9. так же

10. так же

11. так же

12. так же

12.1. так же

12.2. Путь C:\SysGCC\Raspberry\bin\arm-linux-gnueabihf-g++

12.3. Путь C:\SysGCC\Raspberry\bin\arm-linux-gnueabihf-gdb
           для qmake путь C:\SysGCC\Raspberry\qt5\bin\qmake

12.4. так же

12.5. так же

14. так же

15. ????

16. PROFIT!

Views :

816

Кросскомпиляция Qt 5.9 для Raspberry Pi3

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

Приступаем.

Обновлено для Qt 5.9.1 и Raspbian 2017-09-07 Stretch для Raspberry PI3 ModelB

1. Первым делом необходимо скачать образ ОС для малинки, это будет raspbian и залить её на SD карточку, которая уже должна быть воткнута.

mkdir ~/Projects/RaspberryPI 
cd ~/Projects/RaspberryPI 
wget https://downloads.raspberrypi.org/raspbian/images/raspbian-2017-09-08/2017-09-07-raspbian-stretch.zip
unzip 2017-09-07-raspbian-stretch.zip 
sudo dd if=2017-09-07-raspbian-stretch.img of=/dev/mmcblk0 bs=4M
sync
Что бы узнать адрес флэшки, наберите lsblk

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

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

Теперь её немножко надо настроить, переходим Menu -> Preferences -> Raspberry Pi configuration

Жмём «expand filesyste», включаем «ssh», перезагружаемся.

Подключаемся к сети (можно по вафле), вбиваем в консольке (Menu->Accessories->Terminal)  ifconfig, запоминаем айпишник, на этом пока что всё.

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

ssh pi@192.168.2.101 (пароль по дефолту "raspberry")
sudo nano /etc/apt/sources.list  #расскомментить строчку с deb-src
sudo apt-get update
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 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 Qt59Sources
perl init-repository
git checkout 5.9.1
git submodule update --recursive

cd Qt59Sources
BASEPATH=~/Projects/RaspberryPI/raspi # базовый путь, где все наши манипуляции происходят (без слэша на конце)
./configure -skip wayland -skip webkit -skip script -qt-xcb -no-pch -no-use-gold-linker -nomake tests -nomake examples -reduce-exports -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 -j 4 # и поспим часик (4 - количество ядер проца, для ускорения)
make install
Для Qt < 5.9.1 нужен -device linux-rpi3-g++
Если возникли ошибки при сборке и нужно переконфигурировать с другими параметрами, не забудьте удалить предыдущий результат, набрав «git clean -dxf»  и «make clean» иначе будет ещё хуже =)
При ошибке с 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/ отличаются.  И make запускать так: «make CFLAGS=»${CFLAGS} -ldl»» или так: «LIBS=-ldl ./configure«. Хрен знает что из этого помогло, скорее первое. 
В случае ошибки  «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 Qt59Sources/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.

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 :

3359

Программирование и отладка 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 :

484

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

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

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

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

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

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

cd ~/Projects/ST-Link-Utility
git clone https://github.com/texane/stlink .
make 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 apt-get install gcc-arm-none-eabi
sudo apt-get install gdb-arm-none-eabi

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 :

841

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 :

181