Small Device C Compiler suite

On Mon, 2012-07-23 at 16:36 +0200, roelof 't Hooft wrote:
> 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;
> }

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

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@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>

On Tue, 2012-07-24 at 11:11 +0200, Maarten Brock wrote:
> 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.


> You could also just place a struct variable in memory.

That works right out of the box :-)


> 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

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

> Anyway, dank je wel !
>
> roelof

Graag gedaan,
Maarten

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

On Wed, Aug 1, 2012 at 8:46 AM, Kustaa Nyholm <Kustaa.Nyholm@...:

> Hi,
>

Hi Kusti,


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

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.


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

It is also a warning from recent gpasm version.


> 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;
>
>
This is deprecated method for 16 bit pics (18fxxx).


> we could use something like:
>
> CONFIG USBDIV=ON, CPUDIV=OFF, PLLDIV=0
>

Exactly.


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


> 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 :-(


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


> 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

<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