Reply by kevin_townsend2●December 10, 20102010-12-10
Paul:
Thanks for looking into it (somewhat exhaustively!). I checked myself before
seeing your reply, and noticed that with -0s it went from 36 to 25 instructions.
Not bad, but I'm really not familiar enough with ARM assembly to know if
there is still room to shave some extra fat off or not. There's
necessarily 7 register changes and I don't think I can reduce that further.
I have the pins grouped on single GPIO banks for efficiency as well.
I'm OK with ~15fps if this looks like the best possible, just wanted to
know if this was the best I could do in these methods. It's always a
useful exercise to look at things at this level anyway and I don't do it
enough.
25 cycles per pixel writing consecutively (one cmd then endless data writes), or
~150 cycles writing pixels randomly (set x, set y, set color). A bit more than
I expected (pehraps I'm naive?), but screen updates at least feel instant.
There's a bit of tearing visible on full screen animations, but for a $7
240x320 16-bit LCD on a $3 MCU I probably can't demand too much either.
Reply by kevin_townsend2●December 10, 20102010-12-10
Paul:
> However, yes, the address constants may well be able
to be loaded into
> a register, if the compiler is astute. However, I know that GCC does
> some rather strange things what are not intuitive.
I generally compile with -0s (32kb part!), and it definately improves the
performance a fair amount (6-8fps w/o optimisation to 15fps with), so
there's room for improvement, but it's hard to guess where. Is there
a straight-forward way to find a function in optimised code to see what
it's changing?
I assume writing the best C code possible will hopefully improve the optimised
code as well, but I'll need to do some benchmarks to really find out.
Kevin
Reply by Paul Curtis●December 10, 20102010-12-10
Hello Kevin,
You haven't provided definitions of ILI9325_DATA_MASK or
ILI9325_WR_PIN or...
So... can't compile it. A little more, please? (One assumes pREG23
is a volatile unsigned *.)
-- Paul.
Friday, December 10, 2010, 6:55:43 PM, you wrote:
> I've been working on a TFT LCD driver (ILI9325)
using an 8-bit
> interface, and have been able to get it up to about 15fps @ 72MHz
> paying attention to how I set GPIO (single cycle clear+set as
> described in section 8.5.1 of the 1343 UM, etc.). Compiling with no
> optimisation (GCC 4.4), it still feels kind of slow with the cmd
> method taking 40 cycles. Since this function is very heavily used,
> I was wondering if anyone could make some suggestions how I could
> further optimise it? I'd like to stay in C for portability, but
I'm
> open to anything to shave a few cycles off. 40 feels like a lot!
>
> Sorry for the longish code chunk, but for completeness sake here's the C
and generated code:
> ---------- START CODE ----------
> ----- HEADER FILE (bit and register definitions)
-----
If you have a suggestion, I'd definately appreciate any suggestions.
Kevin
Reply by jsm09a●December 10, 20102010-12-10
--- In l..., "kevin_townsend2" wrote:
> Sorry for the longish code chunk, but for
completeness sake here's the C and generated code:
In looking at the ASM code, seems like there are at least three address
constants that are loaded multiple times. I suspect that the multiple loads
will be swallowed up if you turn on optimization. Alternatively, you could
declare a register variable and load the constant just once into the register
variable.
Reply by Paul Curtis●December 10, 20102010-12-10
Hello,
Friday, December 10, 2010, 8:09:34 PM, you wrote:
> --- In l..., "kevin_townsend2" wrote:
>> Sorry for the longish code chunk, but for
completeness sake here's the C and generated code:
> In looking at the ASM code, seems like there are at
least three
> address constants that are loaded multiple times. I suspect that
> the multiple loads will be swallowed up if you turn on optimization.
> Alternatively, you could declare a register variable and load the
> constant just once into the register variable.
In high optimization levels, I expect GCC would replace values
that are known constant with the constant. This is called constant
propagation. I know it happens...
However, yes, the address constants may well be able to be loaded into
a register, if the compiler is astute. However, I know that GCC does
some rather strange things what are not intuitive.
-- Paul.
Reply by kevin_townsend2●December 10, 20102010-12-10
I've been working on a TFT LCD driver (ILI9325) using an 8-bit interface,
and have been able to get it up to about 15fps @ 72MHz paying attention to how I
set GPIO (single cycle clear+set as described in section 8.5.1 of the 1343 UM,
etc.). Compiling with no optimisation (GCC 4.4), it still feels kind of slow
with the cmd method taking 40 cycles. Since this function is very heavily used,
I was wondering if anyone could make some suggestions how I could further
optimise it? I'd like to stay in C for portability, but I'm open to
anything to shave a few cycles off. 40 feels like a lot!
Sorry for the longish code chunk, but for completeness sake here's the C
and generated code:
---------- START CODE ----------
----- HEADER FILE (bit and register definitions) -----