Subject: Re: a question about arm-gcc
To: Danny Lau <email@example.com>
From: Adam Nohejl <firstname.lastname@example.org>
Date: 06/08/2006 23:12:53
2006/06/07 v 8:54, Danny Lau:
> Thank you above two for your advices.
> I think the declaration of the LCD_BUFFER does not really care in
> this case. Please let me have a short explanation. The panel
> engaged in is a 240*320 pixels and 16Bpp LCD panel, 16Bpp(16 Bit
> per pixel) means that a pixel is representated by a half-word
> variable. So for the data-bus length and the storage space, I use
> one "uint32" to representate two pixels. The meaning of the
> expression "240>>1" is to get how many double-pixels in a single
> lcd line, and "320*3" is for how many rows the virtual buffer is.
> Finally, as I had said I had implemented this function in the
> ADS1.2, and it runs well.
I was just pointing out that if you use 32-bit ints for a buffer of
16-bit values (for whatever reason), you can't assign the colors in
the way you do (LCD_BUFFER[y][x] = color). Just wonder why you bother
with the "double-pixels" and don't use: uint16_t buffer[the actual
You also didn't explain the *3, but I guess you have three
framebuffers in the same buffer(?).