Declare variable in the same location as that of a struct member

Or have the C program just access task[0].pntr instead of delay_head.

By the way - note that when porting your PLM51 code to C, i _strongly_ urge you to switch case for your variables. All-capital letters are normally reserved for preprocessor symbols, and another developer who sees code with huge amounts of upper-case symbol names will get a heart attack while desperately trying to look up what your symbols "expands" to.

Hi,
I shall check with the case of the variables.I shall try with unions too.
I have rewritten those statements as below:

struct tsk *tskptr = &TASK[0].PNTR;
unsigned char DELAY_HEAD = tskptr->PNTR;

This is giving error:247

I have to use the variable(delay_head)itself because its used in too many places and would be confusing to access the TASK[0].PNTR directly..

Pls tell me what to do...!!!

Thanks..!!

Sorry to ask, but what is your knowledge level of the following?

- The source language of the code you are porting from
- The target language you are porting to

Hi,
I am a beginner in programming.Probably 8months of programming experience.
I am just familiar with PLM-51 concepts and tried to understand the code by referring the manual.i have a basic knowledge in C programming and Microcontrollers through College and hence working on Embedded C.
Thanks

Note that a pointer in C is a completely different data type from an integer - even if the integer data type happens to have the same size as the pointer.

And a pointer in Keil C51 is even worse, since the 8051 processor have multiple memory regions that requires special types of pointers just to tell the compiler that it requires special assembler instructions to reach the specific memory region.

Without that knowledge, you would have a hard time making the port. Your checksum code (from the other post) requires a pointer to code memory. In this case, you need pointers to data or xdata (I don't actually know, since I do not know where you will place your variables when you port the application).

Note that switching memory model when compiling may hide some of these issues, but not really to your advantage. You really need to know and understand the meaning of a code pointer, or the implications of playing with data, idata, xdata or maybe pdata (besides having const variables stored in the code to save RAM).

Hi,
The logic of Checksum here is clear to me.
Pls s tell me how to rewrite the below statement in C.

DECLARE CONTROL1 WORD AT (7FFEH) CONSTANT (0FFFFH); /* checksum Eprom */

I have written the same statement in C as

code unsigned int CONTROL1 _at_ 0x7FFE;

But i dont know how to initialise the value FFFF to this variable.
This is used in Checksum detection test code.

Thanks.

page 201 (9-26) c167 manual.

Note: RP0H cannot be changed via software, but rather allows to check the current
configuration.

Any idea how to change this reset value so the pins in port 6 are just normal I/O pins ?

Hi,
I have solved the checksum error for now..
I have changed the memory model to large in the options of the compiler.
My code for that part is now as given here.

    unsigned char code MEM_VAL;
        unsigned int idata *MEM_PTR = &MEM_VAL; /*Warning 259:-Diff pointer mspace */
        unsigned int idata CHECK;
        unsigned int code CONTROL1 = 0xFFFF;
for(MEM_PTR=0x0000;MEM_PTR<=0x7FFD;MEM_PTR++)
        {
                CHECK=CHECK+MEM_VAL;
                PCON=0x10;                                                               T3=0x0DF;
        }
        CHECK=CHECK+0x0FF+0x0FF;
        if(CHECK!=CONTROL1)
         {
                INITIAL_ERROR=90;
        }

and then selected the linker as BL51 in options and gave a statement as below in the "BL51 Locate".

 CODE(?CO?CONTROL1(07FFEh))

As of now there are no errors except for the warning mentioned above.I am trying to remove the warning now.
Thanks.

First off - you don't need to change memory model just to get a large pointer.

Secondly, the processor have multiple memory regions - each memory region requires specific instructions to access the data. MEM_VAL is specified "code". Where in your code do you think you instruct the compiler that MEM_PTR is expected to point into the "code" memory region?

What do you think happens when the compiler looks at the type of pointer, and inserts assembler instructions accessing one memory area while the intended values are actually in a compiletely different memory area.

data, idata, code, xdata, pdata really are important for you to understand. Actually vital to understand. Because address 0 in one of these memory regions is a different memory cell compared to address 0 in another memory region.

Indeed - these are absolutely fundamental to any use of any 8051-derivative!

"address 0 in one of these memory regions is a different memory cell compared to address 0 in another memory region"

There are a few cases where the regions overlap - it is left as an exercise for the student to think about which these may be.

It is also possible for the external hardware interface to make (some of) the external memory ranges overlap...

"It is also possible for the external hardware interface to make (some of) the external memory ranges overlap..."

Yes, sometimes xdata may for example be aliased with code for IAP support. And sometimes to allow the processor to download and run code from RAM. But knowing about the different memory regions and checking the datasheet to see if a specific chip have any optional extras is absolutely vital.