ppisa commented on issue #18566: URL: https://github.com/apache/nuttx/issues/18566#issuecomment-4633754866
@Acfboy , @acassis, @ghaerr we have found some time with @michallenc today for discussion and proceed with initial experiment to compile Microwindows core parts (engine, drivers, bitmap precompiled fornts) in to NuttX apps library. See my NuttX APPs branch `add-microwindows` https://github.com/ppisa/nuttx-apps/tree/add-microwindows and commit https://github.com/ppisa/nuttx-apps/commit/de37743ab1ab4e33ca441a81728eff891a5f9001 ``` graphics/microwindows: introduce Microwidows/Nano-X graphics support to NuttX ``` The defines system in Microwindows generates lots of warning so we have used `-Wno-undef` for that. The fixed defines in NuttX integration are setup only for little-endian system for now. The next step is to implement basic screen driver forNuttX framebuffer API. It can be based on Linux `src/drivers/scr_fb.c`, `src/drivers/scr_rtems.c` code or I have some such simple drivers in some of my old embedded projects. As for the test applications, I suggest to start with copy of some simple test based on GDI API. If everything is in the place, then only ``` #include "device.h " PSD psd; ... psd = GdOpenScreen(); ``` should be required to connect to the screen. We use such low level GDI API approach in SuTk for example https://gitlab.com/pikron/sw-base/suitk/-/blob/master/suitk/sui_gdi.c . See how `GdFillRect`. Then you could try to move to `src/demos/mwin/mwdemo.c` demos. The complex one which tests Windows like approach is `mwdemo.c` . I think that you should try to port that application into NuttX APPS `examples` as standalone NuttX sources instead of attempts to compile it through Microwindows build system. When this work, you can move to X11 API (Nano-X). We need to decided what would be the best build system strategy there. I think that Unix domain sockets (` socket(PF_UNIX, SOCK_STREAM, 0);`) would work well on NuttX. That is some overhead but not critical so I would consider to not modify heavily the system to use message queues or something similar. For really constrained devices, the low level GDI API without communication and separate threads is optimal choice from my experience. For larger systems it is OK to have sockets and hey open even way to remote access though AF_INET... As for the experiments, we have started with QEMU x86 native configuration ``` tools/configure.sh qemu-intel64:fb ``` which runs without memory context switches and system and processes virtual addresses isolation. This aligns with typical NuttX use on small embedded systems. Check what is the size of memory of your target board and use appropriate (small enough) display where frame-buffer memory firs into available RAM. We have run Microwindows with SuiTk ons the devices with as small as LPC1768 with only 64 KB of SRAM and we have reserved enough space for communications, time program etc. But we have kept framebuffer on only two bits per pixel. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
