At 06:42 PM 7/11/01 +0100, you wrote:

Hi, Mike:-

>>>readeeprom(rxbuffer[2],8,&rxbuffer[0]);                <---- this should
work,
>>if rxbuffer is an
>>                                                       array of char
>it DOES work, and also works for non-array variables, but the compiler
>thinks I'm doing something wrong.

It shouldn't give you a warning in that case, because &rxbuffer[0] (and
rxbuffer) are both pointers to char.

>>>readeeprom(rxbuffer[2],8,(char)&rxbuffer[0]);   <---- this is wrong, you
>>don't want to cast
>>                                                       the pointer to char!
>But a pointer IS a char (i.e. byte) on a pic! I know it, but the
>compiler doesn't seem to trust me!

In ANSI C it certainly isn't (necessarily) a char, in microcontroller C's
it sometimes is and sometimes isn't, and in HiTech C (for midrange core),
it is only if it is  pointing at RAM (and there are two incompatible types
of RAM pointers 8-( ). Generic pointers in Keil C, for example, are 3 bytes
long. In Hitech C for the 14 bit cores.. you can have function pointers,
pointers to bank 0/1 ram, pointers to bank 2/3 ram, and const pointers
(which can point to RAM or ROM).

The first and last are 16 bits. Otherwise you couldn't have a lookup
table with more than 128 ints in it, for example, as in code compiled for
the 12-bit core.

>char c;
>int i;
>long l;
>char buffer[8];
>
>readeeprom(0,1,(char*)&c); // reads 1 byte to a char
>readeeprom(1,2,(char*)&i); // reads 2 bytes to an int
>readeeprom(3,4,(char*)&l); // reads 4 bytes to a long
>readeeprom(7,6,(char*)&rxbuffer[2]); //reads 6 bytes to rxbuffer[2..7]

I don't see anything much wrong with what you are doing there. I don't
like void*  hacks, and the cast makes it clear what is going on.
Obviously, the casts in the the first and last examples are superflous.

BTW, I'd surely use sizeof( _type_ ) rather than hard coding the number
of bytes in each function call to improve portability (especially
with double). And I'd probably use #defines with a sizeof() offset
from the previous address to set EEPROM address constants.

Best regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads