ppisa commented on issue #18566:
URL: https://github.com/apache/nuttx/issues/18566#issuecomment-4702902454
@Acfboy , there is minor problem in your example code and it is the
definition of the `main()` function. It should be left exactly as in the
regular POSIX program as a `main` and conversion to
```
PROGNAME = $(CONFIG_EXAMPLES_MICROWINDOWS_PROGNAME)
```
is already task of build system. If the NuttX is build in the full MMU mode
then real standalone programs with `main` functions are build. The same it is
even for flat and ELF loadable binaries for single address space. Only case of
builtins linked into single image requires main function name transformation.
```diff
diff --git a/examples/microwindows/mwdemo_main.c
b/examples/microwindows/mwdemo_main.c
index 1bcd7764f..08da63cda 100644
--- a/examples/microwindows/mwdemo_main.c
+++ b/examples/microwindows/mwdemo_main.c
@@ -11,7 +11,7 @@
extern int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nShowCmd);
-int mwdemo_main(int argc, FAR char *argv[])
+int main(int argc, FAR char *argv[])
{
int ret;
```
By the way, please document for others how you call the QEMU and may it be
run
```
make savedefconfig
```
in NuttX and then
```
mkdir boards/x86_64/qemu/qemu-intel64/configs/microwindows
cp defconfig boards/x86_64/qemu/qemu-intel64/configs/microwindows
```
that everybody can test the code by
```
tools/configure.sh qemu-intel64:microwindows
```
As for the performance, there could be more things to consider but emulation
in QEMU has to solve each point and it is questionable which mode is used, etc.
But in general it seems that basic idea works and the match between
Microwindows and NuttX is straightforward. So that is great base for
development. We will see how it would work on real devices.
There is one thing to to consider, when framebuffer is in the main memory
but display is not updated by hardware/DMA and keeps separate frame copy, then
NuttX uses `CONFIG_FB_UPDATE` and it is necessary to call
```
full_screen.x = 0;
full_screen.y = 0;
full_screen.w = fb_state.vinfo.xres;
full_screen.h = fb_state.vinfo.yres;
err = ioctl(fb_state.fd, FBIO_UPDATE, (uintptr_t)&full_screen);
```
to propagate image onto screen somewhere in main loop or some timer. If the
Micowindows drawing functions are capable to record which bounding rectangle
needs update or even somehow keep list of lines which needs to to be updated
then it can help to minimize copy of data to the screen. And that time can be
considerable for some slow SPI or even low clocked parallel connections. I have
had Microwindows driver long long time ago for such slow display around 1998
which has kept update need flag for each row. But it is really old time and
very specific hardware.
--
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]
