How to define LCD buffer area using STK1000

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using an STK1000 and avr32-gcc in Cygwin environment. The code is for stand alone, not Linux.

I want to reserve 230,400 words of the STK1000's 8MB SDRAM for use as an LCD frame buffer. (That's 640x480 pixels of 24 bits each, packed.) This should be fine since the STK1000 has 8 MB, or 2Mwords of RAM.

I intend to program this address into the STK1000's LCDC dmabaddr1 register as follows:

unsigned long *frame_buffer_ptr;

frame_buffer_ptr = ????; // how do I get memory???

volatile struct avr32_lcdc_t *lcdc = &AVR32_LCDC;

lcdc->dmabaddr1 = (unsigned long) frame_buffer_ptr;

It would also be good if I can just assign an array of the required size, or any other way to get the memory allocated and get its address.

I'm currently trying to use malloc but it fails, returns null pointer. Does anybody have an idea or suggestion on how I can reserve this memory and get a pointer for the LCDC?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Certainly normal dynamic memory allocation should be fine. If your malloc fails, check the docco and see whether there's a maximum malloc size. Usually it isn't good practise to malloc more than a page (4K) but some times it is unavoidable.

What's the errno at failure? Just -ENOMEM or something more interesting?

-S.

btw this should be in embedded devel rather than hardware.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is that there is no "docco." And no amount of memory less than a full frame buffer would be useful. And I have no idea what the failure is since I have limited debugging capability.

I wish I could just do this:

unsigned long frame_buffer[230400];

Unfortunately the compiler is unwilling to grant me this small favor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr32-gcc links against newlib, the docco for newlib should be relatively comprehensive.

So long as you have access to a terminal, you should be able to printf the errno. If you can get to a terminal, it might be worth printing the memory allocation stats. IIRC newlib ships with a function (in malloc.h?) which prints various useful memory allocation stats and limits to stderr.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GregoryC wrote:

I wish I could just do this:

unsigned long frame_buffer[230400];

Unfortunately the compiler is unwilling to grant me this small favor.

Are you sure he will be able to grant it at all? Have you set up the SDRAM controller? You will have to do that first in order to access that memory segment.

malloc() doesn't work?

11011110101011011100000011011110

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
avr32-gcc links against newlib, the docco for newlib should be relatively comprehensive.

So long as you have access to a terminal, you should be able to printf the errno. If you can get to a terminal, it might be worth printing the memory allocation stats. IIRC newlib ships with a function (in malloc.h?) which prints various useful memory allocation stats and limits to stderr.


The "docco" for newlib is TOTALLY MISSING!!! Maybe the guys at Atmel kept as a secret.

Seriously, where the heck is the newlib documentation? I've never seen any.

BTW I used the code in the SDRAM example (after I fixed the erroneous example) and got my SDRAM to work. I've set my buffer there and at least I can access it from code, although the LCDC refresh isn't accessing it for some reason I cannot find.

So where is the documentation for newlib?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As posted in another thread: http://sourceware.org/newlib/

Documentation URL: http://sourceware.org/newlib/lib...

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks! It looks like Linux stuff and not Atmel stuff. That could have something to do with my never heard of it since I'm not a Linux guy and I'm not using Linux on my AVR32 design.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is designe for embedded (standalone) usage and open source. Not good at all for Linux usage as it is a bit too light-weight. For Linux we use uClibc which is almost a full C library implementation compared to glibc.

But good you found what you were looking for, it is clear that the official documentation should have links to this site where you can find more specific documentation.

Hans-Christian