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...

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 :-)

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 :-)