Hi, I just tried the following (function version):

void change_value(data unsigned char *pointer)
{
   *pointer = 0x12;
}

void main(void)
{
   unsigned char c = 0x34;
   data unsigned char *p;

   p = &c;

   change_value(p);
(...)

But in this case it seems *p was kept unaltered (*p = 0x34) after the
function call. Any clue why?
Note: I also tried to cast &c to a data unsigned char * but this didn't work
either.

Regards,
Guerra

On 1/15/07, Rodrigo Guerra <[EMAIL PROTECTED]> wrote:

Hello Ernst,

I've just tried to declare the pointer as a data pointer following your
instructions and this worked out.
Thank you very much for your support.

Now I will try to transfer the solution to the more complex application. I
will try to update the list in case something else comes out.

PS.: I had already noticed in gptrput1.c that the code and the eeprom
cases were not implemented yet, but the data case was there. I just didn't
realize it would use some other code if I declared the pointer as a data
pointer.

Thanks again,
Guerra

On 1/14/07, Ernst Bachmann <[EMAIL PROTECTED]> wrote:
>
> On Sunday 14 January 2007 10:48, Rodrigo Guerra wrote:
> > > On 1/14/07, Borut Razem < [EMAIL PROTECTED]> wrote:
> > > > Rodrigo Guerra wrote:
> > > > > <snip>
> > > > > void main(void)
> > > > > {
> > > > >      unsigned char c = 0x34;
> > > > >      unsigned char *p;
> > > > >
> > > > >      p = &c;
> > > > >      p = 0x12;
> > > > >
> > > > > (...)
> > > > > <snip>
>
> Could you try with:
> void main(void)
> {
>      unsigned char c = 0x34;
>      data unsigned char *p;
> //   ^^^^^
>      p = &c;
>      *p = 0x12;
> }
>
> "data" here tells the compiler your pointer will always be used to point
> into
> RAM, never Flash/EEPROM/xmem/whatever, so it can optimize the gptrput
> call
> away and directly work with the pointer.
>
> It's always good practice to declare your pointers like that, unless you
> really need a generic pointer.
>
> Still, this doesn't fix the original problem, but if the result is still
> wrong
> with a "data" pointer, the problem most likely lies elsewhere.
>
> /Ernst
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sdcc-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>



--
Rodrigo da Silva Guerra
PhD Student

Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan




--
Rodrigo da Silva Guerra
PhD Student

Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to