Subject: Re: a question about arm-gcc
To: Adam Nohejl <adam@lokisw.com>
From: Danny Lau <liudengcs@gmail.com>
List: port-arm
Date: 06/09/2006 14:14:40
------=_Part_10245_20516755.1149833680299
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
On 6/9/06, Adam Nohejl <adam@lokisw.com> wrote:
>
>
> 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
> dimensions].
yes, I originally make LCD_BUFFER be uint16_t type, and have no run-time
problems when compiled by armcc. But when I merge the code into gzboot and
compiled by gcc 3.3.3, the run-time exception occurred, so I have to try to
make LCD_BUFFER be uint32_t or uint8_t type.
The code I wrote is: (this function clear the whole lcd display buffer
by the single color, which specified by the argument "U16 c". armcc do it
well, gcc raise an exception)
void Lcd_ClearScr(U16 c)
{
unsigned int x,y ;
for( y = 0 ; y < SCR_YSIZE ; y++ ) // #define SCR_YSIZE 320 * 3
{
for( x = 0 ; x < SCR_XSIZE ; x++ ) // #define SCR_XSIZE 240
{
// volatile unsigned short LCD_BUFER[SCR_YSIZE][SCR_XSIZE];
LCD_BUFER[y][x] = c;
}
}
}
You also didn't explain the *3, but I guess you have three
> framebuffers in the same buffer(?).
Yes, so I can smoothly scroll screen up.
--
> Adam
>
>
------=_Part_10245_20516755.1149833680299
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br>
<div><span class="gmail_quote">On 6/9/06, <b class="gmail_sendername">Adam Nohejl</b> <<a href="mailto:adam@lokisw.com">adam@lokisw.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br>2006/06/07 v 8:54, Danny Lau:<br><br>> Thank you above two for your advices.<br>><br>> I think the declaration of the LCD_BUFFER does not really care in
<br>> this case. Please let me have a short explanation. The panel<br>> engaged in is a 240*320 pixels and 16Bpp LCD panel, 16Bpp(16 Bit<br>> per pixel) means that a pixel is representated by a half-word<br>> variable. So for the data-bus length and the storage space, I use
<br>> one "uint32" to representate two pixels. The meaning of the<br>> expression "240>>1" is to get how many double-pixels in a single<br>> lcd line, and "320*3" is for how many rows the virtual buffer is.
<br>> Finally, as I had said I had implemented this function in the<br>> ADS1.2, and it runs well.<br><br>I was just pointing out that if you use 32-bit ints for a buffer of<br>16-bit values (for whatever reason), you can't assign the colors in
<br>the way you do (LCD_BUFFER[y][x] = color). Just wonder why you bother<br>with the "double-pixels" and don't use: uint16_t buffer[the actual<br>dimensions].</blockquote>
<div> </div>
<div>yes, I originally make LCD_BUFFER be uint16_t type, and have no run-time problems when compiled by armcc. But when I merge the code into gzboot and compiled by gcc 3.3.3, the run-time exception occurred, so I have to try to make LCD_BUFFER be uint32_t or uint8_t type.
</div>
<div> </div>
<div>The code I wrote is: (this function clear the whole lcd display buffer by the single color, which specified by the argument "U16 c". armcc do it well, gcc raise an exception)</div>
<div> </div>
<div>void Lcd_ClearScr(U16 c)<br>{<br> unsigned int x,y ;<br> <br> for( y = 0 ; y < SCR_YSIZE ; y++ ) // #define SCR_YSIZE 320 * 3<br> {<br> for( x = 0 ; x < SCR_XSIZE ; x++ ) // #define SCR_XSIZE 240
<br> {</div>
<div> // volatile unsigned short LCD_BUFER[SCR_YSIZE][SCR_XSIZE];<br> LCD_BUFER[y][x] = c;<br> }<br> }<br>}</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">You also didn't explain the *3, but I guess you have three<br>framebuffers in the same buffer(?).</blockquote>
<div> </div>
<div>Yes, so I can smoothly scroll screen up.</div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">--<br>Adam<br><br></blockquote></div><br>
------=_Part_10245_20516755.1149833680299--