Qt를 STM32로 포팅

좋은 오후에요 우리는 프로젝트에 있습니다 엠박스 STM32F7-Discovery에서 Qt를 시작했고 이에 대해 이야기하고 싶습니다. 앞서 우리는 이미 출시 방법을 설명했습니다. OpenCV.

Qt는 그래픽 구성요소뿐만 아니라 데이터베이스 작업을 위한 클래스 세트인 QtNetwork, 자동화용 Qt(IoT 구현 포함) 등을 포함하는 크로스 플랫폼 프레임워크입니다. Qt 팀은 임베디드 시스템에서 Qt를 사용하는 데 적극적으로 참여해 왔기 때문에 라이브러리 구성이 상당히 가능합니다. 그러나 최근까지 Qt를 마이크로 컨트롤러로 포팅하는 것에 대해 생각한 사람은 거의 없었습니다. 아마도 그러한 작업이 어려워 보였기 때문일 것입니다. Qt는 크고 MCU는 작습니다.

반면에 현재 멀티미디어와 함께 작동하도록 설계되고 최초의 펜티엄보다 우수한 마이크로 컨트롤러가 있습니다. 약 XNUMX년 전, Qt 블로그가 등장했습니다. 게시. 개발자는 RTEMS OS용 Qt 포트를 만들고 stm32f7을 실행하는 여러 보드에서 위젯이 포함된 예제를 시작했습니다. 이것이 우리의 관심을 끌었습니다. STM32F7-Discovery에서 Qt가 느리다는 것이 눈에 띄었고 개발자 스스로도 그것에 대해 썼습니다. 우리는 Embox에서 Qt를 실행하고 위젯을 그리는 것뿐만 아니라 애니메이션도 실행할 수 있는지 궁금했습니다.

Qt 4.8이 오랫동안 Embox로 포팅되어 왔기 때문에 우리는 그것을 사용해 보기로 했습니다. 우리는 탄력 있는 애니메이션의 예인 moveblocks 애플리케이션을 선택했습니다.

QEMU의 Qt moveblocks

우선 애니메이션을 지원하는 데 필요한 최소한의 구성 요소 집합으로 Qt를 구성합니다. 이를 위해 “-qconfigminimal,small,medium...”옵션이 있습니다. Qt의 구성 파일을 많은 매크로(활성화할 항목/비활성화할 항목)와 연결합니다. 이 옵션 뒤에 다른 것을 비활성화하려면 구성에 다른 플래그를 추가합니다. 다음은 우리의 예입니다. 구성.

Qt가 작동하려면 OS 호환성 레이어를 추가해야 합니다. 한 가지 방법은 QPA(Qt Platform Abstraction)를 구현하는 것입니다. 우리는 Linux용 QPA가 작동하는 기반으로 Qt에 포함된 기성 fb_base 플러그인을 기반으로 삼았습니다. 그 결과 Qt에 Embox의 프레임버퍼를 제공하고 외부 도움 없이 거기에 그림을 그리는 emboxfb라는 작은 플러그인이 탄생했습니다.

플러그인을 만드는 모습은 다음과 같습니다.

QEmboxFbIntegration::QEmboxFbIntegration()
    : fontDb(new QGenericUnixFontDatabase())
{
    struct fb_var_screeninfo vinfo;
    struct fb_fix_screeninfo finfo;
    const char *fbPath = "/dev/fb0";

    fbFd = open(fbPath, O_RDWR);
    if (fbPath < 0) {
        qFatal("QEmboxFbIntegration: Error open framebuffer %s", fbPath);
    }
    if (ioctl(fbFd, FBIOGET_FSCREENINFO, &finfo) == -1) {
        qFatal("QEmboxFbIntegration: Error ioctl framebuffer %s", fbPath);
    }
    if (ioctl(fbFd, FBIOGET_VSCREENINFO, &vinfo) == -1) {
        qFatal("QEmboxFbIntegration: Error ioctl framebuffer %s", fbPath);
    }
    fbWidth        = vinfo.xres;
    fbHeight       = vinfo.yres;
    fbBytesPerLine = finfo.line_length;
    fbSize         = fbBytesPerLine * fbHeight;
    fbFormat       = vinfo.fmt;
    fbData = (uint8_t *)mmap(0, fbSize, PROT_READ | PROT_WRITE,
                             MAP_SHARED, fbFd, 0);
    if (fbData == MAP_FAILED) {
        qFatal("QEmboxFbIntegration: Error mmap framebuffer %s", fbPath);
    }
    if (!fbData || !fbSize) {
        qFatal("QEmboxFbIntegration: Wrong framebuffer: base = %p,"
               "size=%d", fbData, fbSize);
    }

    mPrimaryScreen = new QEmboxFbScreen(fbData, fbWidth,
                                        fbHeight, fbBytesPerLine,
                                        emboxFbFormatToQImageFormat(fbFormat));

    mPrimaryScreen->setPhysicalSize(QSize(fbWidth, fbHeight));
    mScreens.append(mPrimaryScreen);

    this->printFbInfo();
}

그리고 다시 그리는 모습은 다음과 같습니다

QRegion QEmboxFbScreen::doRedraw()
{
    QVector<QRect> rects;
    QRegion touched = QFbScreen::doRedraw();

    DPRINTF("QEmboxFbScreen::doRedrawn");

    if (!compositePainter) {
        compositePainter = new QPainter(mFbScreenImage);
    }

    rects = touched.rects();
    for (int i = 0; i < rects.size(); i++) {
        compositePainter->drawImage(rects[i], *mScreenImage, rects[i]);
    }
    return touched;
}

결과적으로 메모리 크기 -Os에 대한 컴파일러 최적화가 활성화되면 라이브러리 이미지가 3.5MB로 판명되었으며 이는 물론 STM32F746의 메인 메모리에 맞지 않습니다. OpenCV에 대한 다른 기사에서 이미 썼듯이 이 보드에는 다음이 포함됩니다.

• 1MB ROM
• 320KB RAM
• 8MB SDRAM
• 16MB QSPI

QSPI에서 코드 실행에 대한 지원이 이미 OpenCV에 추가되었으므로 전체 Embox c Qt 이미지를 QSPI에 로드하는 것부터 시작하기로 결정했습니다. 만세, 모든 것이 QSPI에서 거의 즉시 시작되었습니다! 하지만 OpenCV의 경우와 마찬가지로 너무 느리게 작동하는 것으로 나타났습니다.

따라서 우리는 이런 방식으로 수행하기로 결정했습니다. 먼저 이미지를 QSPI에 복사한 다음 SDRAM에 로드하고 거기에서 실행합니다. SDRAM에서는 조금 더 빨라졌지만 여전히 QEMU에서는 거리가 멀습니다.

다음으로 부동 소수점을 포함시키는 아이디어가 있었습니다. 결국 Qt는 애니메이션에서 사각형 좌표에 대한 일부 계산을 수행합니다. 우리는 시도했지만 여기서는 눈에 띄는 가속도를 얻지 못했습니다. 기사 Qt 개발자들은 FPU가 터치스크린의 "애니메이션 드래그" 속도를 크게 향상시킨다고 주장했습니다. moveblocks에서는 부동 소수점 계산이 훨씬 적을 수 있으며 이는 특정 예에 따라 다릅니다.

가장 효과적인 아이디어는 프레임 버퍼를 SDRAM에서 내부 메모리로 옮기는 것이었습니다. 이를 위해 화면 크기를 480x272가 아닌 272x272로 만들었습니다. 또한 색 농도를 A8R8G8B8에서 R5G6B5로 낮추어 한 픽셀의 크기를 4바이트에서 2바이트로 줄였습니다. 결과 프레임 버퍼 크기는 272 * 272 * 2 = 147968바이트입니다. 이로 인해 상당한 가속이 이루어졌으며 아마도 가장 눈에 띄게 애니메이션이 거의 매끄러워졌습니다.

최신 최적화는 RAM에서 Embox 코드를 실행하고 SDRAM에서 Qt 코드를 실행하는 것이었습니다. 이를 위해 먼저 평소와 같이 Embox를 Qt와 정적으로 연결하지만 라이브러리의 텍스트, rodata, 데이터 및 bss 세그먼트를 QSPI에 배치한 다음 이를 SDRAM에 복사합니다.

section (qt_text, SDRAM, QSPI)
phdr	(qt_text, PT_LOAD, FLAGS(5))

section (qt_rodata, SDRAM, QSPI)
phdr	(qt_rodata, PT_LOAD, FLAGS(5))

section (qt_data, SDRAM, QSPI)
phdr	(qt_data, PT_LOAD, FLAGS(6))

section (qt_bss, SDRAM, QSPI)
phdr	(qt_bss, PT_LOAD, FLAGS(6))

ROM에서 Embox 코드를 실행함으로써 우리도 눈에 띄는 가속을 얻었습니다. 결과적으로 애니메이션이 매우 매끄러워졌습니다.

마지막에 기사를 준비하고 다양한 Embox 구성을 시도하는 동안 Qt moveblocks는 SDRAM의 프레임 버퍼를 사용하는 QSPI에서 훌륭하게 작동하며 병목 현상은 정확히 프레임 버퍼의 크기라는 것이 밝혀졌습니다! 분명히 초기 "슬라이드쇼"를 극복하기 위해서는 프레임 버퍼 크기의 진부한 감소로 인해 2배 가속이면 충분했습니다. 하지만 Embox 코드만을 다양한 고속 메모리에 전송하는 것만으로는 이러한 결과를 얻을 수 없었습니다(가속률은 2배가 아니고 1.5배 정도였습니다).

직접 시도해 보는 방법

STM32F7-Discovery가 있는 경우 Embox에서 Qt를 직접 실행할 수 있습니다. 이 작업이 어떻게 수행되는지는 당사에서 읽을 수 있습니다. 위키.

결론

그 결과, 우리는 Qt를 출시할 수 있었습니다! 우리 의견으로는 작업의 복잡성이 다소 과장된 것 같습니다. 당연히 마이크로컨트롤러의 특성을 고려하고 컴퓨터 시스템의 아키텍처를 전반적으로 이해해야 합니다. 최적화 결과는 컴퓨팅 시스템의 병목 현상이 프로세서가 아니라 메모리에 있다는 사실을 잘 보여줍니다.

올해 우리는 축제에 참여할 것입니다 TechTrain. 여기서는 더 자세히 설명하고 마이크로컨트롤러의 Qt, OpenCV 및 기타 성과를 보여드리겠습니다.

출처 : habr.com