Roelof,

Is there a reason why you use this "poor man's malloc"? 
You could also just place a struct variable in memory. 
You can initialise the pointer with the address of this 
variable. But if it never changes you might as well use 
the variable itself. And unless you use its contents in 
an ISR or asm you don't need volatile either.

__xdata struct _message my_message;
__xdata struct _message *ptr2message = &my_message;

my_message.address = databyte;
ptr2message->control = 0;

Maarten

> Hi all,
> 
> It is me again with a pointer issue :-(
> (that is an ongoing battle with me)
> 
> I would like to know if there is a better way to do
> what I have done in the next source code :
> 
> 
> extern.h :
> 
> #define _cast_message (volatile __xdata struct _message *)
> 
> typedef struct _message
> {
>       uint8_t address;
>       uint8_t trx_bytes;
>       uint8_t rcv_bytes;
>       uint8_t control;
>       uint8_t buffer[16];
> };
> extern volatile __xdata struct _message *message;
> 
> uint16_t externe_init(uint8_t);
> 
> 
> 
> extern.c :
> 
> volatile __xdata struct _message *message;
> volatile __xdata uint8_t memoryspace[16 + 4];
> 
> uint16_t externe_init(uint8_t databyte)
> {
>       message = _cast_message &memoryspace[0];
>       ...;
>       message->address = databyte;
>       message->buffer[10] = 0x96;
>       ...;
>       return (uint16_t)&message->address;
> }
> 
> 
> 
> main.c :
> 
> void main(void)
> {
>       message = _cast_message externe_init(0x30);
>       ...;
> }
> 
> 
> 
> I have a structure which I would like to access in other c files.
> To have an actual piece of RAM I needed to create some with the
> memoryspace buffer and get that address in the pointer message
> (a poor man's malloc function).
> After some hacking I also got the address exported to the main
> function. So far so good.
> I know this is not good coding but I am unable to find a better
> way of doing this.
> 
> If I do not get the address of memoryspace into message it will
> be zero. I can understand that but I defined the memory as 0x1000
> bytes large starting at 0x7000. What is going on there ?
> I expected the compiler/linker to complain about that.
> 
> sdcc version :
> 
> SDCC : mcs51 3.2.1 #8035 (11 Jul 2012) (Linux)
> 
> 
> command line to compile :
> 
> sdcc -D_87c591 -c --model-small --code-size 0x7000 --xram-size 0x1000
> --xram-loc 0x7000 --iram-size 0xff extern.c
> sdcc -D_87c591 -c --model-small --code-size 0x7000 --xram-size 0x1000
> --xram-loc 0x7000 --iram-size 0xff main.c
> sdcc --code-size 0x7000 --xram-size 0x1000 --xram-loc 0x7000 --iram-size
> 0xff main.rel extern.rel
> packihx main.ihx > main.hex
> 
> 
> Thanks,
> 
> roelof
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
> 



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user

Reply via email to