Subject: Re: a question about arm-gcc
To: Danny Lau <email@example.com>
From: Adam Nohejl <firstname.lastname@example.org>
Date: 06/06/2006 20:24:38
2006/06/06 v 12:13, Danny Lau:
> Hi, all
> I am rewiting gzboot to let messages be dumped to the LCD panel
> rather than the COM port,and the arm--netbsdelf-gcc is generated by
> command "build.sh -m evbarm tools". For some reasons, I feel that
> the compiler cann't output correct binary code.
> The LCD panel is a 240*320, 16Bpp one. So, a large memory buffer
> was engaged in as a framebuffer, that is a large continuously
> "unsigned int" memory array. I declare it as this: unsigned int
If you really mean "[240>>1]" by "[240<<1]" (according to your last
message), this will allocate (320*3) * (240/2) = 960 arrays
containing 120 elements of type int. This probably isn't what you
want (see below).
> The chip(s3c2410) will raise an "Undefine instruction" exception
> (run time) when I use "array operator" to iterate the buffer items,
> like LCD_BUFFER[y][x] = color,
The inner array has only 120 elements, therefore x has to be less
> and preform well when I use "pointer operator" to get access the
> items, like *(LCD_BUFFER+y+x) = color; For some other buffer, like
> strings, the situation is totally reversed.
This works only if you define LCD_BUFFER as a contiguous one-
The way you work with arrays seems a bit odd to me, but I don't
really understand the framebuffer stuff, so I hope I got it right.