Názory k článku Nový X11 server napsaný v x86 assembleru, KDE zase úspornější
-
X11 je již často s grácií posílaný do temné minulosti, ale původní návrh měl pro počítače s menším množstvím paměti a často s grafickým výstupem běžícím na oddělěném HW své kouzlo. Přitom X11 kompatibilních aplikací je stále mnoho a s růstem paměti v embedded světě, kde je dnes běžné mít na malém MCU čipu okolo 500 kB a i více SRAM a megabajty Flash se již i bez externí paměti MCU přiblížila plnohodnotným počítačům, na kterých se provozoval UNIX a X11 v osmdesátých letech a PC na kterých jsem GNU/Linux provozoval v letech devadesátých, například i80486 4 MB paměti s X11 běžel pěkně a byl plně použitelný.
X11 tedy může být i cesta pustit přenositelné aplikace na MCU.
My před lety začali používat jen samotnou GDI vrstvu z https://microwindows.org/ nejdříve na čipech s architekturou H8S v systemless režimu, později s RTEMSem a SuiTk na infůzních pumpách a poté opět v HPLC přístorjích v system-less režimu na LPC1768 a LPC4088.
Nyní vedu experimentální GSoC s cílem integrace podpory pro NuttX. Základ integrace již chodí, jsou otestovaná dema psaná Windows GDI stylem, lokální X11 a časem třeba vzdálené X11 puštění aplikací je úkol druhé půle léta. Ukázka na NuttXu v QEMU zde. Ve vláknu je pak i mnoho dalších informací.
Nano-X by pak mělo dát i na NuttXu možnost portovat/používat aplikace například s FlTk nebo i třeba Dillo browser.
Výsledek bude k vidění na OTREES možná již na letošních LinuxDays, určitě na příštím InstallFestu.
-
Vsetko pekne a zaujimave ale co je cielom? Vytvorit co najlacnejsi prenosny pocitac? Embedded zariadenie ktore niekde bude? Vsetko sa da riesit ale podla mna nejako uplne inac. Cena lacneho pocitaca ktory zvladne Xwindows je zlomok ceny samotneho displaya ak sa bavime o rozmere 12 palcom napriklad. A ak potrebujem vzdialenu aplikaciu spustat Z takto maleho pocitaca tak to je lahsie a jednoduchsie napisat to ako nejaku web aplikaciu so vzdialenym pristupom.
-
Cílem je především jednodušší grafika přímo na nějakém embedded zařízení, určitě to není míněné jako náhrada tabletu, mobilu, počítače a asi spíš ani jako základ pro nějaký kalkulátor. Tam všude je jednodušší vzít něco standardizovaného a tedy levnějšího.
Výhoda použít API dostupných i na GNU/Linuxu i na menších systémech je přenositelnost. Například díky Microwindows jsme kompletní GUI, uživatelskou logiku a mnoho subsystémů infúzních pump šlo testovat na GNU/Linuxu v Microwindows okénku emulujícím framebuffer v X11 ploše. Cílové zařízení byl RTEMS na Motorola/Freescale/NXP i.MX1 ARMu. Deklarativně v XML popsané obrazovku, nastavení, přechody mezi stavy a mnoho dalšího pro asi pět jazyků včetně arabštiny a ruštiny představovalo přes 70 tisíc řádek.
Podobně jsme řešily malé terminály k odběrovým místům do chemičky, kde na HW běžel síťově načítaný GNU/Linux a grafika běžela přímo na framebufferu.
Na malých zařízeních s 64 kB RAM size popis z XML a dynamicky v paměti vytváření GUI realizovat nešlo, ale stejný základ Microwidows+SuTk umožňuje mnoho immutable objektů referencovat přímo z Flash a obrazovku pak poskládat z C kódu a to i včetně event connectorů, alternativa/ekvivalent signal slotů z Qt.
Většinou jsme tedy využívali tu nízkou vrstvu Microwidows, kde tím, že jsme i drivery pro třeba naše specifické displeje a HW implementoval podle Microwindows definovaného API, tak byla zajištěná přenositelnot a znovu využitelnost tak v rozsahu 25 let.
I vyšší Microwindows API blízké programování klasický WinAPI aplikací pro Windows se také může někde hodit a ta implementovaná část je celkem konzistentní a logická. Prostě pořád nevymýšlíte znova a znova, jak implementovat kreslení čáry, kruhu výplně obecného polygonu atd... Souhlasím, že NuttX již nabízí NXwidgets a LVGL a pro něco určitě budou lepší.
Port skutečně plných X11 aplikací je spíš vedlejší efekt, ale zase i na malém RTOS možnost odsunout grafiku do jiného vlákna a třeba i v případě buildu NuttXu v režimu pro MMU pro nějaký RISC-V s MMU (třeba i levný ESP32-S31 ho již nabízí) nebo pro ARM z řady A (M má model pro reálnou vzájemnou ochranu procesů nešťastný) to může přinést i zvýšení bezpečnosti kdy GUI neohrozí paměť procesu, který třeba něco kritičtějšího řídí.
Souhlasím, že dnes by i na malá MCU byl zajímavý a modernější Wayland, ale jeho model kompozice plných bitmap je celkem paměťově náročný. X11 dokázal v historické době kompletní grafiku udržet jen v jedné kopii framebufferu na grafické kartě a jen aplikace informovat, které oblasti/obdélníky mají překreslovat s tím, že X11 maskoval to co bylo zakryté. S obecným tvarem oken se to trochu pokazilo, bylo potřeba k takovým oknům držet mastkovací bitmapu, ale běžně to bylo 1 bit na pixel. Pak přišel požadavek na antialiasing textu a jeho prolnutí s obecným pozadím a to původní koncept X11 zlikvidovalo, bitmapy celých oken se musely přenášet do aplikací a zpět... Ale na ta malá zařízení často tak vysoké estetické požadavky kladené nejsou, potřebujete, aby technik nebo uživatel mohl něco zkontrolovat, nastavit s několika klasickými fonty, atd., takže ten původní X11 koncept vychází stále výhodně.
Nějakou představu jak se takové přístroje ovládají, si lze vytvořit třeba z našich ještě o generaci starších manuálů pro HPLC přístroje, které využívaly znakové dvou a čtyřřádkové displeje. Manuály pro ty přístroje se SuiTk psali jak pro infůzní techniku tak HPLC výrobci, takže ty asi online nemám.
-
A nejake na sieti vysiace sluzby ktore funguje cez REST api a JSON? 'Graficke' rozhranie potom cez WEB, command line alebo kludne aj nieco s vystupom na display ale narocnejsie na obsluhu. Vsetky zaroven kludne aj naraz ovladajuce to zariadenie. Ja som naposledy pouzil EspHome a bol som velmi prekvapeny ako dobre to funguje. Popis v YAML nahrate to tam vsetko funguje. Dokonca sa to samo naintegruje aj do HomeAssistenta.
-
Tak na něco složitějšího má smysl přístup přes web, ale na lokální nastavení zařízení, které často ani nemá Ethernet nebo WiFi nebo právě na to nastavení adres a hesel se lokální displej hodí. Zároveň je to často rychlý indikátor problému a třeba možnost nějakého emergency zásahu i pro ta zařízení, která komunikaci mají. Přitom malý TFT displej na SPI je často záležitost desetikorun a na druhou stranu na řídicím embedded systému často máte opravdu minimum paměti. Ano dnes se to mění. Ale stále má malý lokální displej smysl a často s nějakou na míru připravenou klávesnicí je to na ty servisní zásahy nejjednodušší. Potřeujete povolit obtokový ventil, nechat pumpu pročistit, popřepínat složky, utáhnout ventil atd... Když budete zařízení hledat na mobilu, pak ho dokládat a přesovat ruce na ventily, kohout atd, pak pro každé přepnutí opět brát mobil, na kterém si prsty od vody nebo i rozpouštědel popatláte display, ten možná ani nebude správně dotyky brát. Proti tomu tlačítka trochu pošpinění vydrží a tak podobně.
Zároveň správa web aplikace v zařízení, její update kvůli bezpečnosti, atd. to vše často výrazně vývoj a údržbu prodraží. Když vezmete náš přístroj vyrobený v roce 1996, propojíte ho dvoudrátovou komunikací s dalším z roku 2022, přes lokální klávesnice nastavíte adresu na sběrnici, provedete tubing, odmačkáte si purge a složky a pak to připojíte k CHROMuLANu na Linuxu nebo WIndows 11 a necháte naběhnou atodetect a dokonfigurujete a můžete rozjet analýzy, tak si stále myslím, že lokální displeje mají smysl. A dnes již je to řešení s grafikou místo textových řádek jednodušší.
-
Jinak Vaše zkušenost je domácího nasazení, tam Vám nikdo WiFi a další nezakazuje. V nemocnici jsou požadavky často přísné a připojení se na Ethnernet je na dlouhé papírování, dnes třeba i na Akademii věd, nemáte certifikáty, doložený systém update driverů atd. bezdrát na sále v nemocnici je ještě o třídu složitější, ano doktoři tam vejdou s mobilem a nikdo to moc neřeší, ale dodané zařízení ještě třeba s možností ohrožení pacienta je i bez WiFi hodně zkoušek a papírování. Stějně tak určitě nebudou chtít nějaké cloud technologie a lokální server s otevřeným portem i jen do lokální sítě je optět na stanovení zodpovědné osoby a papírování. A nejedná se o spotřební materiál, y když zjistíte, že Vaše domácí IoT je nebezpečné, tak ho vyhodíte a za pár korun z Číny koupíte nové prvky. U zařízení za 100 tisíc až jednotky miliónů to takto nechodí, 20 let provozu není žádná výjimka, mezitím se sítě a technologie změnily několikrát. Přitom ta zařízení ořád lze obsluhovat. Je to stejné jako u měřící techniky, kde stále i nová zařízení mívají GPIB a to se v sestavách používá.
-
API je chranene tokenom a je mozne urobit update cez to WIFI. Mozete to napojit aj na socket file co bude pristupny cez SSH na seriovej linke/USB porte. Princip zostava, nepotrebujem tam ziadne Xwindows. Rovnako ako na ovladanie segmentoveho alebo ineho LCD display asi tiez nejdete cez X. Proste ten usecase ze potrebujem na mikro zariadeni mat XWindows je cudny.
-
Tak pokud se opíráte jen do těch X11, tak tam souhlasím, že je to spíš zajímavost, kuriozita, cvičení na kterém z mého pohledu není v daném GSoC takový důraz. Určitě je nepočítám používat vzdáleně a lokálně mají overhead. Ale to Microwindows API (minimálně pro mě) smysl má právě pro tu přenositelnost GUI řešení nad těmi jeho nižšími API a obecně i jako celkem rozumná sada grafických funkcí, obdélníky, kruhy, linky, fonty a ty třeba až po TrueType, když je místo a celkem promyšlené blit funkce, bitmapy a další.
Jinak i jen SSH je v malém embedded s 64 kB a možná i s 380 kB SRAM potíž. Teď běží GSoC na DropBear pro NuttX a již byl demonstrovaný, že chodí. Ale výkonnostně a asi i bezpečností to bude omezené a posílal přes to grafiku je nesmysl. Na maitainer CLI přístup to smysl má, ale aby tím sestra kontrolovala na místě infúzní pumpu opravdu ne. Ta musí mít lokální displej s informací, jak rychle dávkuje, kolik je již vydávkováno, jaký je tlak atd a ovládání nezávislé na ostatní technice a komunikaci. Když se něco rozbije, musí okamžitě přepsat rychlost a nastavit zbytek dávky na jiném ze skříně vytaženém přístroji. Je tam i tedy ya výhoda, že informace jsou na tom zařízení, které se obsluhuje, tedy nícké riziko, že manipuluji s něčím jiným, než si myslím. Stejně tak u HPLC nebo i lkolejových obvodů v Elektroline, tam také přímo v rozvaděčích desky na NuttXu malé GUI mají, v tomto případě na LVGL. A jasně, ladění se dělá přes USB nebo CAN a je k tomu kompletní aplikace která zabere s daty, průběhy velkou obrazovku připojeného počítače. Ale okamžité bar-grafy a další pohledy plus LEDky přímo na úzkých čelíčkách v zásuvném systému jsou cenná/nutná okamžitá zběžná kontrola.
-
I když je úžasné, jak efektivně lidé dokázali využít tehdejší slabý hardware, dnes u zařízení za sto tisíc asi nepotřebujete řešit 380 kB SRAM. Polovina bývá marže, takže výrobní náklady 50 tisíc. Něco fixní (vývoj), neví variabilní (součástky). Určitě ale není třeba použít počítačovou jednotku za sto korun, můžeme klidně za tisícovku. A rázem máme klasický výkonný počítač s dost RAM, úložištěm a nějakou integrovanou GPU. Všechny parametry od výkonu po kapacity minimálně x1000.
19. 7. 2026, 17:01 editováno autorem komentáře
-
Ale vy tam klasický PC HW opravdu nechcete. To MCU je s interrupty a lokálním HW úplně jinde na tu hlavní funkci, kterou má plnit, motory, přesné časování atd. I jen přes PCIe máte roundtrip jednotkách usec, Přitom tam nechcete řešit PC věci atd. Ano můžete tam dát nějaké ARM 32 nebo 64-bit Linux SBC, ale zase to tam nechcete. Ani tam nechcete ESP32 s Flash a kódem na SPIFI. Chcete tam nějaký Cortex-M nebo ekvivalentní malý RISC-V, který má teplotní rozsahy, často nechcete pro jednoduchost vývoje BGA, chcete rozumně rychlou Flash na čipu atd...
Nějaká rezerva na počítačový modul tam je, ale tole není IT, kde je ta procesorová část ta stěžejní a její výkon hlavní. Máte tam přesnou optiku, specielní zdroje světla, motory, safírové písty, ventily, holografické mřířky, zdroje světla, díly v tisícínách mm, obrábění PEEK-u, montáž, oživení, kalibrace, obslužný nadřazený SW, vývoj na relativně málo kusů, potřebu mít to možnost vyrábět alespoň 10, 15 let a neřešit, že daná sezónní novinka/spořebák za rok nebude. Přitom ceny v průmyslu nasaditelných PC jsou o řády jinde, než to co stavíte doma a často srovnatelné s mnohařádově výkonnějším HW do serverů. Chcete spolehlivost a v zásadě bezúdržbovost. Neřešit nějaké BIOSy, drivery, jejich update, atd. Přitom i spotřeba a zdroje jsou jiné, třeba jeden na 24 V pro motory a a něj malým hrníčkem s řízením uděláte galvanicky oddělěných 5 V pro řízení a několik dalších pro oddělěné komunikace, přesné převodníky atd. Těch 24 V třeba 100 W, ale 5V třeba do 5W a z nich chcete nepájet stepdownem malý Cortex-M ne x86 zrůdu nebo topící Cortex-A a již určitě ne při 85 stupních se zastavující Rasperry PI bez potřebných rozhraní a periferií nebo něco jiného spotřebního. Ano, kde je to potřeba, tak se dá i.MX6/8/9, nebo Xilinx či průmyslové Ti s GNU/Linuxem, ale k tomuto modulu stejně budete muset často pro perieferie přidat nějaký ten Cortex-M přesto, že i ty SoC mají periferie celkem pěkné. Nevyjde to propojením, galvanickým oddělěním atd. Přitom o vyšší řízení má smysl vzdáleně přes nějaký k tomu určený protokol, takže zase ten další GNU/Linux po cestě je minimálně někdy jen další zbytečná starost a problém na údržbu. Jinak sám mám v zařízeních GNU/Linux rád, když to smysl dává. Ale třeba certifikaci Linuxové distribuce pro nasazení přímo v infúzní pumpě považuji za šílenost, proto jsem tam dali RTEMS. V té době ani RT na Linuxu usazené nebylo a i teď je to při velikosti jádra šílenost.
Opravdu jste u mnoha případů hodně v jiné oblasti než kde se pohybujeme a ta cena, velikost a spolehlivost té řídící elektroniky jsou v jiném ranku.
-
Jedna z možností jsou dva čipy. Jeden ten Cortex-M a jeden normální. Pak točíte realtime motorkama jednoduchým kódem a složitější logika nad tím není omezena hardwarem. Pokud by se těch zařízení dělalo hodně, tak je užitečné přesunout část nákladů z variabilních do fixních, ale to mi nepřijde jako případ těchto zařízení.
-
Ale vždyť právě pro ty malé o Linuxu nehovořím. NuttX běží i na 32 nebo 64 kB SRAM atd. Jen mám zájem mít na tu grafiku API, se kterým mohu ty SW moduly testovat snadno i pod GNU/Linuxem, kde se snadněji debuggují, udělá CI, otestuje kód Vlagrindem atd... A jak jsem několikrát uvedl tak X11 je by-product, hlavní cena jsou ta nižší ale přenositelná API, která Microwindows/Nano-X také automaticky nabízí. Tak se netočte kolem argumentu, který Vám nerozporuji.
