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

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

Re: [avr-gcc-list] Access to constants via elpm


From: E. Weddington
Subject: Re: [avr-gcc-list] Access to constants via elpm
Date: Fri, 30 Aug 2002 11:14:11 -0600

On 30 Aug 2002 at 17:51, Roland Zitzke wrote:

> Hi,
> Thanks for the hint
> > >
> which is also
> > defined in ina90.h. This is perhaps what you are looking for.
> >
> The macro starts with:
> #define __ELPM_enhanced__(addr) ({  \
>  unsigned long __addr32 = (unsigned long)(addr); \
> But did anyone ever try this casting to unsigned long?
> It doesn't seam to work in my application and I wonder how the
> compiler treats the symbol when performing the cast - as a 16 bit
> pointer or a long value? Roland
> 

Ok, try this:

#define __ELPM_enhanced__(addr)                \
(                                              \
    {                                          \
        unsigned char __result;                \
        __asm__ __volatile__                   \
        (                                      \
            "movw r30, %A2\n\t"                \
            "sts  %1, %C2\n\t"                 \
            "elpm %0, Z\n\t"                   \
            : "=r" ((unsigned char)__result),  \
              "=m" (RAMPZ)                     \
            : "r" ((unsigned long)addr)        \
            : "r30", "r31"                     \
        );                                     \
        __result;                              \
    }                                          \
)

Give the macro a 32-bit address (unsigned long) and it will spit out 
the data (unsigned char) that is programmed in the flash.

I've tested this out on my ATmega128 and it works. However, I have no 
idea if it will work on other AVR processors and I would be very 
interested to know if it did.

Also, I'm in the process of slogging through writing other inline 
assembly macros. Consequently I'm not completely sure if I'm getting 
the constraints correct. But on the other hand, the compiler / 
assembler doesn't give me any errors or warnings either. Any input to 
this part is also appreciated.

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



reply via email to

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