Hi All, Am trying to re-write a code in PLM51 to embedded C. There is a statement in PLM51 as below.
DECLARE TASK(17) STRUCTURE(PNTR BYTE,STATUS BYTE,DELAY WORD); DECLARE DELAY_HEAD BYTE AT (.TASK(0).PNTR); //ERROR LINE//
What i have understood from this is-- DELAY_HEAD is a byte variable which resides at the same location as that of TASK(0).PNTR.(From the PLM51 manual)
I have rewritten the same into C as below.
struct tsk { unsigned char PNTR ; unsigned char STATUS; unsigned int DELAY; }TASK[17]; unsigned char DELAY_HEAD _at_ &TASK[0].PNTR ;
But its giving error 221:non-constant case/dim expression. Plss help..!!
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
Porting is not really a beginner's job - precisely because it relies upon a thorough understanding of both the source and target languages.
The errors you are getting are due to basic 'C' programming issues.
Is this a commercial or hobby project?
For links to some essential 'C' reference material, see: blog.antronics.co.uk/.../
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 ?
Wow - major forum bug.
Seems the forum have a temporary file with fixed name for storing posted text, so if two posts at the same time, everything breaks badly.
The above text, claimed to have been posted by me, is actually a post from this thread: http://www.keil.com/forum/18464/
Why do you not keep a specific subject in the thread you did create for that discussion? Your checksum thread is: http://www.keil.com/forum/18448/
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.
Indeed - quite so!
"and checking the datasheet to see if a specific chip have any optional extras"
Of course.
Hey, Thankyou for all the help so far. I have compiled my code and now... Its showing...
compiling ****.c linking... ****.obj To **** RAMSIZE(256) CODE (?CO?CONTROL1(0x7FFE)) WARNING L16 WARNING L16 ERROR L110 RESTRICTED VERSION WITH 0800H BYTE CODE SIZE LIMIT;USED:3014H BYTE LINK/LOCATE RUN COMPLETE.2WARNINGS,1ERROR(S)
Then there is one more fatal error shown in the end.
FATAL ERROR L250:CODE SIZE IN RESTRICTED VERSION EXCEEDED
I am using the student version of KEIL.So are these errors and warnings due the size limit issue?or some other problem???Because i cannot convert this code to a HEX file this way.
RESTRICTED VERSION WITH 0800H BYTE CODE SIZE LIMIT; USED:3014H BYTE
It tells you that you have a 0800H-byte limit, and have used 3014H bytes - in what way is that not clear?
Again, it tells you that you have a restricted version, and you have exceeded the limit.