Searching \ for '[PIC]: correct typecast to pass pointers in Hitech' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'correct typecast to pass pointers in Hitech'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: correct typecast to pass pointers in Hitech'
2001\07\11@083720 by mike

flavicon
face
Given a procedure to read a number of bytes from 16F87x internal
eeprom to a given address :
void readeeprom(char address,char nbytes,char *dest)
{
EEADR=address;
EECON1=0;
do {  RD=1; *dest++=EEDATA; EEADR++;}  while(--nbytes);
}

The following calls give "illegal conversion of integer to pointer
(warning)" but do generate correct code and work correctly :
readeeprom(rxbuffer[2],8,&rxbuffer[0]);
readeeprom(rxbuffer[2],8,(char)&rxbuffer[0]);

It's not a major problem but it would be nice to know the 'correct'
way to do it to avoid the warning messages.

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


2001\07\11@091638 by Spehro Pefhany

picon face
At 01:38 PM 7/11/01 +0100, you wrote:
>Given a procedure to read a number of bytes from 16F87x internal
>eeprom to a given address :
>
>void readeeprom(char address,char nbytes,char *dest)
>{
>EEADR=address;
>EECON1=0;
>do {  RD=1; *dest++=EEDATA; EEADR++;}  while(--nbytes);
>}
>
>The following calls give "illegal conversion of integer to pointer
>(warning)" but do generate correct code and work correctly :
>
>readeeprom(rxbuffer[2],8,&rxbuffer[0]);                <---- this should work,
if rxbuffer is an
                                                      array of char

>readeeprom(rxbuffer[2],8,(char)&rxbuffer[0]);   <---- this is wrong, you
don't want to cast
                                                      the pointer to char!

readeeprom(rxbuffer[2],8,(char *) &rxbuffer[0]); <---- this is correct, but
I don't know why
                                                      you would want to
write it this way!

readeeprom(rxbuffer[2],8,rxbuffer);              <---- this is how I would
write it


IOW:-
char rxbuffer[10];  NOT char * rxbuffer[10];  (the latter would be an array
of pointers to char)
readeeprom(rxbuffer[2],8,rxbuffer);

It sounds like the pointer-array duality in C has you snagged, if  you
persist, all will
become clear.

Best regadrs,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.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


2001\07\11@134111 by mike

flavicon
face
>>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.

>>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!

>readeeprom(rxbuffer[2],8,(char *) &rxbuffer[0]); <---- this is correct, but
>I don't know why  you would want to
>write it this way!

I think this is what I was looking for.
There is a  VERY good reason why I want to do it this way - maybe I
shouldn't have confused things by using an array as the example!

I want to pass the address of a target variable of ANY type, so my
readeeprom routine can stuff the data straight into the  variable,
whether it be a char, int, long or array.
This is much more code, space and time-efficient than passing the
values  e.g. :
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]

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


2001\07\11@154552 by Spehro Pefhany

picon face
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"
.....speffKILLspamspam@spam@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


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...