avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Const lookup table


From: Peter Bosscha
Subject: Re: [avr-gcc-list] Const lookup table
Date: Sat, 20 Apr 2002 08:34:22 +0200

I've gone through a bit of a learning curve getting a Mega128 to go
using the windows version of AVRGCC. 
Yes it works, but there are a number of things to watch out for: (I'll
make some bold statements and see what reaction I get :-) )

- You have to hack around a bit to get the compiler to go for MEGA128:
(I was helped by another kind soul, so if you need, I'll provide..)
a. create/use your own linker script
b. get your own startup module
c. here and there you have to change some stuff in the mega128 include
file to get the macro's going nicely.

- FPLib does not work if your code gets bigger than 64KBytes. (There is
a quick fix for that.) 

- Constant (PROGMEM) addressing above 64k(byte) does not work easily
unless you write your own macro's. (Fundi's: The ELPM macro does not
work for MEGA128)
The best way is to avoid having flash constants above 64K and then
you're OK.

- The standard watchdog functions do not work, for some reason Atmel saw
fit to make the Mega128 work a little differently from the rest.

- There's a bug in using -O3 for the compiler (Highest optimisation),
always use -O2 or -Os

- In my experience, for really complex programs with loads of local
variables and complex structures there's even a bug using -O2/-Os. For
the fundi's: the R28/R29 pointer to the local variables on the stack
gets clobbered, resulting in your call not returning to the right
address. The bug is real but I once spent about 4 hours trying to
recreate it using a simple example. This so I could report the bug,
unfortunately the bug is pretty elusive and I got fed up. 
In other words: it is not something that people will experience very
quickly and -Os, -O2 is pretty safe.

- The latest windows release has a bit of an outdated library, there are
a number of nice new functions available in newer releases of libc.

In conclusion, it works but there are a number of issues to be aware of
and undoubtedly you'll hit a wall somewhere. The nice part is that
there's lots of friendly people around willing to help.

Have a nice day,

Peter
>>> "Sander Pool" <address@hidden> 04/19/02 20:19 PM >>>

That's pretty slick. I'm thinking of using a mega128 to create sound
(speech
to be exact) and I was thinking I could store quite a few small samples
in
flash memory.

Does avrgcc take care of the 64 KB boundary automatically or do I need
to
specify in which segment the tables go?

This is cool stuff! Of course I'd first have to make the m128 avrgcc
work on
windoze :-)

    Sander

----- Original Message -----
From: "Peter Bosscha" <address@hidden>
To: <address@hidden>; <address@hidden>
Sent: Friday, April 19, 2002 5:11 AM
Subject: Re: [avr-gcc-list] Const lookup table


> Hi Andries,
>
> There you go:
>
> void ASSIGN_Relay(unsigned char Number)
> {
>  volatile unsigned char Relay_select = 0;
>     static unsigned char PROGMEM Lookup_relay [16] = {
>       0x06, 0x05, 0x07, 0x00, 0x02, 0x04, 0x01, 0x03,
>       0x03, 0x01, 0x04, 0x02, 0x00, 0x07, 0x05, 0x06
>       };
> }
>
> Of course you'll have to use PRG_RDB to get your variables (!)
>
> Regards
> Peter Bosscha
>
>
> >>> Andries Posthumus <address@hidden> 04/19/02 12:15PM
> >>>
> Hi all
>
> Please help, I would like to use a lookup table, in a subroutine. I
> don't
> want to store the lookup table in RAM, how can store it in program
> memory
>
> void ASSIGN_Relay(unsigned char Number)
> {
>  volatile unsigned char Relay_select = 0;
>     static unsigned char Lookup_relay [16] = {
>       0x06, 0x05, 0x07, 0x00, 0x02, 0x04, 0x01, 0x03,
>       0x03, 0x01, 0x04, 0x02, 0x00, 0x07, 0x05, 0x06
>       };
> }
>
> Andries Posthumus
>
>
> avr-gcc-list at http://avr1.org
>

avr-gcc-list at http://avr1.org


avr-gcc-list at http://avr1.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]