On Fri, 2010-10-15 at 16:44 +0200, Raphael Neider wrote:
> Hi,
>
> >> __code unsigned char __at( 0xf00000 )
> >> values[] = {
> >> 0x00, 0x01,
> >> 0x02, 0x03,
> >> 0x04, 0x05,
> >> };
> >>
> >> Unfortunately, when I use the EEPROM read commands for index 0, I get
> >> 0x00, for index 1, I get 0x02, and index 2, I get 0x04.
>
> Could you check whether/which of the .hex / .o / .lst / .asm files are OK?
> If I am not mistaken, there was a problem in gputils with addressing
> certain memory spaces.
> I might have a look into this myself later, but updating gputils to
> whatever is currently out there might be worth a try.
Actually there's a bug in SDCC I think too.
When declaring code such as this....
__code unsigned char __at ( 0xf00000 )
we end up doing this in the generated assembly....
values:
DB 0x00, 0x01, 0x02, 0x03, 0x04, 0x05
The problem with this is that gpasm has special opcode for EEPROM data
known as "DE", so SDCC should be outputting
values:
DE 0x00, 0x01, 0x02, 0x03, 0x04, 0x05
And then there's an additional problem in gpasm which I've hacked here
and it works now.
But I think this needs to be dealt with by using __eeprom instead of
__code inside SDCC. So we could do this...
__eeprom unsigned char
values[] = {
...
};
We shouldn't need to define the EEPROM location as the assembler should
know that too.
Alan.
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
