nanogui: Speed Issues on a slow CPU
Subject:
Speed Issues on a slow CPU
From:
Amadeus ####@####.####
Date:
3 Oct 2007 10:15:24 +0100
Message-Id: <200710031115.03287.amadeus@iksw-muees.de>
Hello,
this is my first post to this list. I am the gui who wants to get PIXIL
running on the Nintendo DS. This effort is hosted at www.dslinux.org.
The Nintendo DS is a dual-core machine. An ARM7 CPU @ 33 MHz for the
sound, IO and background tasks. And an ARM946es @ 66 MHz for the main
system.
There are several limitations and shortcommings on this system...
First of all, there is no MMU, only a MPU. So there is uClinux / Kernel
2.6.14 running.
Second, there are only 4 MByte of internal memory. There was a
possibility to expand this memory +32 MByte externally, but only on
16bit bus with only ONE(!) write strobe.
I costed me several month and a lot of gcc hacking to reclaim this
memory as general-purpose memory. So now we have a 36MByte uClinux
system, with 32 MByte of this memory is a bit slower than usual.
The screen is 256 x 192 pixel RGB 555.
There are no shared libraries and no dynamic loader on this system. I
have had some issues with PIXIL about this, but no big problems.
I have nano-X and PIXIL up and running, but I am facing serious speed
issues. The reaction to a click on the touchscreen is slow, and the
calculator needs 1-2 seconds to display.
What I have done so far:
- define NDEBUG in nano-X drivers.
- add assembler code for horizontal and vertical lines in the driver.
- implement shared memory support.
There were small improvements in speed, but nothing worth mention.
The load monitor applet is displaying a constant load of about 40% CPU
usage (I think because of the frequent screen updates in the load
monitor window).
So, can someone with more experience in nano-X and PIXIL explain which
are the most performance-critical parts of the system and how to
improve them?
regards
Amadeus
--
We're back to the times when men were men
and wrote their own device drivers.
(Linus Torvalds)
