[Sdcc-user] a better way to define a pointer to structure ?

[roelof 't Hooft]

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

[roelof 't Hooft]

Post by roelof 't Hooft
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;
}

I changed the return value from externe_init() to void
because it is not needed due to the external declaration
of the message pointer.

roelof

[Maarten Brock]

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

Post by roelof 't Hooft
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
#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);
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;
}
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 : mcs51 3.2.1 #8035 (11 Jul 2012) (Linux)
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
https://lists.sourceforge.net/lists/listinfo/sdcc-user

[roelof 't Hooft]

Post by Maarten Brock
Roelof,
Is there a reason why you use this "poor man's malloc"?

Because I have been trying to get this pointer thing to
work for ages now and that was the best I could come up
with. First time, long ago, I tried it would not work so
I implemented a large array and had #defines for the
different positions in the header file. But that annoyed
me to the extent that I wanted to change it to a structure
so I started trying again a few weeks ago.

Post by Maarten Brock
You could also just place a struct variable in memory.

That works right out of the box :-)

Post by Maarten Brock
And unless you use its contents in
an ISR or asm you don't need volatile either.

So, if I read this right I do not have to make the variable
volatile and can still use it in an ISR (and all the other
c files).

Anyway, dank je wel !

roelof

[Maarten Brock]

Post by roelof 't Hooft

Post by Maarten Brock
And unless you use its contents in
an ISR or asm you don't need volatile either.

So, if I read this right I do not have to make the variable
volatile and can still use it in an ISR (and all the other
c files).

No, if you want to use the pointer in both an ISR and your main loop you
have to use volatile. But if you use it only in the main loop you can
leave volatile out. Volatile means that the compiler should make no
assumptions about the data staying at the same value, because it can
change at any moment. An ISR can do that or a piece of asm or real
hardware.

Post by roelof 't Hooft
Anyway, dank je wel !
roelof

Graag gedaan,
Maarten

[Kustaa Nyholm]

Hi,

a fried is using a piece of code I wrote and is getting a bunch of these
warnings which I'm not seeing:

main.asm:19:Warning[212] __CONFIG has been deprecated for PIC18 devices.
Use directive CONFIG.


He is on Windows with SDCC 3.x.y and I'm on Mac stuc with 2.8.9 atm.

Googling around it looks to me like this warning is from MPASM and not
gpasm?

Is hes toolchain messed up or does it work like that on Windows..should it
work..what is going on?

But more importantly what is the right way to handle this?

Web search suggests that instead of:

code char at 0x300000 CONFIG1L = 0x20;


we could use something like:

CONFIG USBDIV=ON, CPUDIV=OFF, PLLDIV=0


is that right? Is that syntax supported by SDCC / gputils?

Did not find anything about this in the SDCC / gputils manuals...

If this is the Right Way (tm) then where are those bits define or can
one just use the names of those bits in the processor datasheet?

I could of course install SDCC latest (and I will, very soon now) and
even try it on Windows and experiment but don't want to have anything
more on my plate right now as atm this is not my problem so I'm
hoping someone on the list can throw some light on this?

br Kusti

[Borut Ražem]

Post by Kustaa Nyholm
Hi,

Hi Kusti,

Post by Kustaa Nyholm
a fried is using a piece of code I wrote and is getting a bunch of these
main.asm:19:Warning[212] __CONFIG has been deprecated for PIC18 devices.
Use directive CONFIG.

This warning was introduced in one of recent gputils releases, so you are
using an older version of gputils then your frend if you don't see the
message.

He is on Windows with SDCC 3.x.y and I'm on Mac stuc with 2.8.9 atm.
It is the same on all OS-es. It depends on gputils version.

Post by Kustaa Nyholm
Googling around it looks to me like this warning is from MPASM and not
gpasm?

It is also a warning from recent gpasm version.

Post by Kustaa Nyholm
Is hes toolchain messed up or does it work like that on Windows..should it
work..what is going on?
But more importantly what is the right way to handle this?
code char at 0x300000 CONFIG1L = 0x20;

This is deprecated method for 16 bit pics (18fxxx).

Post by Kustaa Nyholm
CONFIG USBDIV=ON, CPUDIV=OFF, PLLDIV=0

Exactly.

Post by Kustaa Nyholm
is that right? Is that syntax supported by SDCC / gputils?

Yes, this is right. It is supported also by SDCC 3.2.0:
#pragma config USBDIV=ON, CPUDIV=OFF, PLLDIV=0

In the SDCC 3.2.0 release this was still a little bit buggy. You should try
it with the latest snapshot build If it doesn't work for you.

Post by Kustaa Nyholm
Did not find anything about this in the SDCC / gputils manuals...

For sdcc it is documented in the sdccman included in 3.2.0 release package
and in recent snapshot build doc packages.
It is not documented in gputils :-(

Post by Kustaa Nyholm
If this is the Right Way (tm) then where are those bits define or can
one just use the names of those bits in the processor datasheet?

You should use the definitions from datasheet.

Post by Kustaa Nyholm
I could of course install SDCC latest (and I will, very soon now) and
even try it on Windows and experiment but don't want to have anything
more on my plate right now as atm this is not my problem so I'm
hoping someone on the list can throw some light on this?

I hope I did ;-)

br Kusti
P.S.: This is just a warning since using __CONFIG directive on 16 bit pic
devices is deprecated by gputils and mpasm, but it still works. I recomend
to use CONFIG directive in gputils and #pragma config approach in sdcc for
newly dedveloped software.

Borut

[Kustaa Nyholm]

<big snip>

Thanks Borut, everything is now clear. I will use
the new format when I switch 3.2.0 or whatever is
current when I do that... hopefully soon.

br Kusti