nanogui: port question
Subject:
Re: [nanogui] port question
From:
Ed Sutter ####@####.####
Date:
11 Jul 2005 13:05:12 +0100
Message-Id: <42D26048.1010306@lucent.com>
Thanks to all for the responses.
I have it running as a standalong MicroMonitor (uMon) application
on the CSB536 from Cogent Computer Systems. I added appropriate
kbd/mouse/scr drivers, then made slight modifications to the demos
to hook to uMon and it just worked! Nice package!
Actually, in the process of working with this, I used a debugging
memory allocator that comes with uMon and it detected a few memory
overruns. I haven't had time to investigate this entirely so it could
be a false alarm; however, I was able to sidestep the alledged problem
by adding 32 to all the allocation sizes (indicating that the size of
the overrun is small).
I will let you know if I actually find a problem here. Has anyone
ever reported any similar issue?
Thanks very much
Ed Sutter
> : I'm brand new to MicroWindows. I'm considering using MicroWindows
> : (i.e. NanoGUI) on a board with no RTOS (for now). The board has a
> : framebuffer hooked to an LCD display and runs MicroMonitor as the
> : bootloader. As a result, I want to write a simple 'C' main()
> : function to exercise NanoGUI on this hardware.
> :
> : Before I go any further, is this outside the focus of NanoGUI or is
> : it reasonable to think that it can be built for an environment that
> : is RTOS-less?
>
> Yes, Nano-X is designed to be able to run on pretty bare
> hardware. Screen, keyboard and mouse I/O can be handled
> directly with the scr, kbd and mou drivers, as discussed in the
> Architecture document. These do not require any OS. In
> addition, HAVE_FILEIO can be set to N in the config file
> if you don't have any file i/o capabilities underneath Nano-X.
>
> As Aaron stated, there is the need for basic C library,
> string manipulation, and malloc/free however. Also,
> a mechanism to wait for a mouse or kbd event (MwSelect)
> has to be implemented. This is implemented in nanox/srvmain.c.
>
> The win32 applications are already single-application binaries.
> The nano-X API applications will need to be linked
> using the LINK_APP_INTO_SERVER config option
> if you don't have multiple process execution capability
> in an underlying OS. In the eCos case, folks have linked
> multiple nano-X apps together and used cooperative
> threading to run them all from within a single executable.
>
> Regards,
>
> Greg
