Hlavní navigace

Vlákno názorů k článku Operace s framebufferem na Raspberry Pi (vykreslování do framebufferu) od ogar - Zrovna nedavno se mi dostal do ruky jeden...

  • Článek je starý, nové názory již nelze přidávat.
  • 30. 1. 2016 11:51

    ogar (neregistrovaný) ---.net.upcbroadband.cz

    Zrovna nedavno se mi dostal do ruky jeden platebni terminal postaveny na linuxu (SoC Maxim, puvodne Zilog Zatara) s barevnym display (320x240x16b).

    Bohuzel, tento display je pripojeny pres SPI a implementace framebufferu je plne software, tj. framebuffer je pouze a jenom v systemove pameti a pouze pri kazdem ioclt(FB_REFRESH) se pres SPI prenese celych 150kb na display.
    Celkove to vychazi maximalne tak na 15fps.
    Navic, tento framebuffer podporuje pouze tento jeden specificky mod 320x240x16b (coz je ale celkem logicke :-), kazdy pokus o nastaveni jakehokoliv jineho konci s chybou.

    Sranda je, ze terminal nema ani klavesnici (je urcen pouze jako contactless a pro male castky, tedy vzdy bez overovani uzivatele) a tudiz ani zadnou systemovou konzolu, pouze seriovy port (USB CDC) a ethernet.

    Puvodni pokusy o port Chocolate Doomu dopadly spatne: SDL ani DirectFB nejdou pouzit, jelikoz:
    1) predpokladaji fyzickou konzoli a ctou z ni
    2) snazi se menit rozliseni a hloubku displayi ...

    Takze nakonec byl resenim specialni SDL home-made driver pro tento terminal, kde
    a) z stdin (seriova konzole, telnet) ctu klavesy a simuluju stisky a pousteni (bud timeout nebo stik jine klavesy)
    b) simuluju i vetsi/mensi rozliseni a orezavam/centruju do 320x240 (vracim vzdy SDL_FULLSCREEN | SDL_NOFRAME)
    c) simuluju i jinou bitovou hloubku (ale vracim vzdy SDL_HWPALETTE) a sam prepocitvam pixely do pozadovaneho 565 formatu

    Kupodivu, vysledny produkt je i celkem hratelny :-)

  • 1. 2. 2016 16:40

    Pavel Tišnovský

    To ma na strane displeje double buffering nebo primo vidis, jak se pomalu prenasi tech 150kB?

    jinak 320x200x16b je na toto zarizeni docela luxusni rezim, to muze vypadat pekne (vim, vim zadne HDI, ale co uz).

  • 1. 2. 2016 22:13

    ogar (neregistrovaný) ---.net.upcbroadband.cz

    No podle indicii v kodu 'SDK' by to mohl byt ili9341 (https://www.adafruit.com/datasheets/ILI9341.pdf).
    Bohuzel mam to zarizeni pouze 'zapujcene' a nerad bych provadel 'vivisekci' ....

    Kazdopadne v teto implementaci je zrejmne 'natvrdo' pripojeny pres SPI a zadny buffering na strane display se neprovadi, protoze je krasne videt (kdyz clovek vi, co ma cekat) prekreslovani/te­aring :-)

    Vzhledem k funkci tomuto zarizeni je ten displayi az az. Zvlaste kdyz je clovek odkojeny 8-bity (u mne CBM +4, ale to si mozna pamatujes z koleji :-) - 320x200 mono nebo 160x200 4 barvy (z toho 2 pro cely screen stejne a dve menitelne per 4x8 pixel block).

    Navic, ja jsem asi hardcore, a muj nazor programatora/im­plentatora se zde rozchazi s 'marketingem' a 'lobby' vyrobcu terminalu :-(

    Podle mne ma terminal slouzit pouze a jenom k zobrazeni+potvrzeni castky a zadani PINu. Ostatni veci - barevne reklamy, .... at si resi na nejakem tabletu vedle, nebot:
    a) terminal ma PCI, EMV, (a milion dalsich) certifikaci -> je to drahe a specialovane zarizeni s relativne malo pameti (16MB standard, 64-128MB luxus)
    b) malokdy je to posix-like system, vetsinou nejaky specialni 'inhouse rtos like' -> prelozit na tom nejakou 'standardni knihovnu' skoro nemozne (hlavne pokud pouziva I/O funkce), clovek je rad kdyz najde neco podobneho sprintf()
    c) aplikace primarne akceptuji bankovni karty, takze kazdapidizmena -> dukladne testovani vsecho
    d) aplikace musi byt podepsane, takze kazda pidizmena -> procedura podpisu
    e) reloaduji se pres posmanagement v bance, takze kazda pidizmena -> procesne pres banku

    Vedle toho kdyz si predstavim tablet:
    1) napr. 'znacka' Sencor za 2KKc
    2) je tam android a 'matlaci' screen
    3) aplikace na to 'sflaka' jakykoliv student bokem na kolejich
    4) 'samo' sa to updatuje pres store

    Ale na druhou stranu mne to zase zivi, tak co si stezuju :-)

  • 2. 2. 2016 21:01

    Pavel Tišnovský

    jj CBM a další mašinky, grafika na pár kilobajtů a šlo to. Mě se na RPi (ale i na dalších podobných bobulkových a ovocných jednodeskových mikropočítačích) líbí právě ten nízkoúrovňový přístup, který na jiných strojích moc nemá smysl. Tady ale ano: máš GPIO, framebuffer, nějaké to HDI a pod tím realtime systém nebo klasický kernel (podle preferencí každého soudruha :-).