Bona dies Nos sumus in project deductae Qt in STM32F7-Inventio et loqui de eo vellem. Antea iam narravimus quomodo deduceremus .
Qt est compages transversalis, quae non solum graphice elementa includit, sed etiam talia quae QtNetwork, copia generum ad operandum cum databases, Qt pro Automatione (inclusa pro IoT implementation) et multo plura. Turma Qt proactivum est de utendo Qt in systematis immersis, ergo bibliothecae satis configurabiles sunt. Tamen, usque nuper, pauci homines de portandis Qt microcontrolers portandis cogitaverunt, probabiliter quia tale negotium difficile videtur - Qt est magnum, MCUs parva sunt.
Ex altera parte, momento exstant microcontrollers cum multimedia et meliores primae Pentiums operari destinati sunt. Circiter anno elapso, Qt blog apparuit . Tincidunt portum de Qt pro RTEMS OS fecerunt, et exempla cum contentis in pluribus tabulis currentibus immissi sunt stm32f7. Hoc interest, nos. Notabile erat, et tincidunt ipsi de eo scribunt, Qt tarde in STM32F7-Inventa sit. Mirabamus nos si Qt sub Embone possemus currere, et non solum content trahere, sed animationem currere.
Qt 4.8 diu Embox allatum est, ita eam experiri decrevimus. Mobilium applicationem elegimus - exemplum manantis animationis.
Qt moveblocks in QEMU
In primis, Qt, si fieri potest, configuramus cum minimis componentibus, quae ad animationem sustentandam requiruntur. Hacc est optio "-qconfig minima, parva, medium ....". Configurationem conectit fasciculus ex Qt cum multis macros - quid efficere / quid disable. Post hanc optionem, alia vexilla schematismi addimus si aliud quid disable velimus. En exemplum nostri .
Ut pro Qt laborare, OS convenientiae iacuit addere debes. Unus modus est ad efficiendum QPA (Qt Platform Abstractio). In fundamento cepimus plugin in Qt inclusa fb_basi parata, ex quo QPA opera Linux. Eventus est parvum plugin emboxfb vocatum, quod Qt cum framebuffer embox praebet, et inde sine ullo extrinseco adiutorio illuc trahit.
Hoc est quod creando plugin similis
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();
}
Et hoc est quod videbimus sicut redrawing
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;
}
Quam ob rem, optimization compilator pro magnitudine memoriae -Os enabled, bibliotheca imago evasit 3.5 MB, quod utique non convenit in memoriam praecipuam STM32F746. Ut iam in alio articulo de OpenCV scripsimus, haec tabula habet:
- 1 MB ROM
- 320 KB RAM
- 8 MB SDRAM
- 16 MB QSPI
Cum subsidium exsequendi codicis ex QSPI ad OpenCV iam adiectum sit, decrevimus ut totam Embox c Qt imaginem in QSPI oneratam incipere. Et eia, omnia fere statim a QSPI inceperunt! Sed sicut in OpenCV, evenit quod tardius operatur.
Itaque hoc modo facere decrevimus - primum imaginem QSPI imitamur, deinde eam in SDRAM oneratis et inde exegimus. Ex SDRAM factum est paulo velocius, sed adhuc longe ab QEMU.
Deinde idea erat punctum fluctui includere β post omnia, Qt facit aliquas calculi coordinatarum quadratorum in animatione. Conati sumus, sed hic non habuimus aliquam accelerationem visibilem, licet in Qt tincidunt asseruit FPU notabilem incrementum dat velocitati pro "animatione trahere" in touchscreen. Notanter minus potest esse punctum fluitantis calculi in mobilibus mobilibus, et hoc pendet ab exemplo specifico.
Plurimum efficacissima idea erat ab SDRAM ad memoriam internam framebuffer movere. Ad hoc efficiendum, dimensiones ductiles non 480x272, sed 272x272 fecimus. Colorem etiam profunditatis ab A8R8G8B8 ad R5G6B5 submisimus, ita reducendo magnitudinem unius pixelli ab 4 ad 2 bytes. Framebuffer resultans magnitudo est 272 * 272 * 2 = 147968 bytes. Haec acceleratio notabilis, fortasse notissime, animatio paene levis facta est.
Novissima optimatio erat ut Embox codicem ex RAM et Qt codicem SDRAM curreret. Ad quod faciendum, primum, ut solet, embox simul cum Qt statically coniungimus, sed textum, rodata, data et bss segmenta bibliothecae in QSPI ponimus ut deinde eam ad SDRAM transscribamus.
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))
Exsequendo codicem Embox ab ROM, accelerationem notabilem accepimus. Quam ob rem animatio satis lenis evasit;
Ad extremum, dum articulum parat et configurationes Embox varias quaerit, evenit ut Qt globulorum cinematographicorum QSPI cum framebuffer in SDRAM operaretur, et in bottleneck erat ipsa magnitudo compagis! Ut videtur, "slideshow" initialem superare, 2 triplex acceleratio satis erat ob reductionem vulgarem in compage magnitudine. Sed talem exitum assequi non potuit, transferendo solum codicem embox ad varias memorias ieiunium (per accelerationem non 2, sed circiter 1.5 temporibus).
Quam experiri te
Si STM32F7-Inventum habes, currere potes Qt sub embox te ipso. Legere potes quomodo hoc in nostro fiat .
conclusio,
Quam ob rem, Qt tractavimus deducere! Multiplicatio operis, ut videtur, aliquantum exaggeratur. Naturaliter, debes considerare specialia microcontrollorum et architecturam systematum computatrorum generaliter intelligis. Optimization eventus demonstratur ad notum factum quod bottleneck in systemate computando non est processus, sed memoria.
Hoc anno festo participemus . Ibi planius tibi narrabimus et ostendemus Qt, OpenCV in microcontrolers et res gestas nostras.
Source: www.habr.com