on-chip xram

you can use a function pointer to make a function call.

You can use a GOTO to jump to a label. But that usually makes your code a mess and it is not recommended.

you can use a function pointer to make a function call.

You can use a GOTO to jump to a label. But that usually makes your code a mess and it is not recommended.

i tried using a function pointer...

static unsigned int s_addr;
unsigned char xdata *xloc;
void (far *MyFunc)(void)=(void far*)(xloc);

void main (void)
{
  s_addr=get_addr();
  xloc=(unsigned char xdata *)s_addr;
  (*MyFunc)();
}

but the 3rd line shows error
MAIN.C(30): error C141: syntax error near '*', expected ')'
MAIN.C(30): error C129: missing ';' before ')'
get_addr() is a function which returns the address to which i need to make the jump...

There are some major issues with function pointers in Keil C51 - do not use them until you have thoroughly studied & understood the issues!

Start here: http://www.keil.com/appnotes/docs/apnt_129.asp

http://www.keil.com/support/man/docs/bl51/bl51_ol_fp.htm
http://www.keil.com/support/man/docs/lx51/lx51_ol_fp.htm

And many more: www.keil.com/search.asp

And many previous discussions: www.keil.com/search.asp

What, exactly, is the purpose of this "trainer kit" ?

As already noted, the fundamental 8051 architecture means that it is not well-suited for loading user programs as you describe.

Therefore, if it is suppoosed to be specifically an 8051 trainer, you will be doing your students a disservice by suggesting that they use an 8051 in such an application.

On the other hand, if the purpose is to demonstrate loading user programs as you describe, then the 8051 is a poor choice.

In conclusion:

Either drop the "user program" idea - and concentrate on what an 8051 is useful for;

Or use a more appropriate processor to demonstrate the "user program" idea.

That doesn't mean that your students cannot load their own programs!

It just means that the way you're proposing is not the way to do it on an 8051 - and, therefore, not the way to teach it on an 8051!

Teach your students to use the normal ISP (In-System Programming) or IAP (In-Application Programming) approach for an 8051 .

That's because the the 3rd line is wrong!
It's nothing to do with Keil or the 8051 - it's just not valid 'C' syntax.

You need to go back to your 'C' text book for details of how to do function pointers in the 'C' programming language in general.

Then you need to study the Keil Manuals for the Keil-specific details - and all the limitations - of function pointers in C51.

But, again, this is really not a great thing to be doing on an 8051 at all!

yea you are right..storing the opcodes in the xdata space is not going to do any good and also there are chances of them being over-written since xdata space is read/write...but this supposed trainer kit has already been implemented...and as per the manual the upper 32K bytes of an external RAM IC is meant for the user program memory...they probably have some mapping between the xdata and code space....will check properly...anyways thanQ for all the help and links...greatly appreciate...:)

and i've got a way around the function pointer problem....

typedef void (*fun_ptr)(void);
fun_ptr xloc ;
fun_ptr MyFunc;
void main (void)
{
  s_addr=get_addr();
  xloc=(fun_ptr)s_addr;
  MyFunc=(fun_ptr) xloc;
  (*MyFunc)();
}

it works..!!

So what, exactly, is your goal here?

Why do you think you need two steps?

  xloc=(fun_ptr)s_addr;
  MyFunc=(fun_ptr) xloc;

By the way - an address in XDATA will only match an address in CODE if the board you have maps them identically, i.e. if the 32 kB of RAM have the XDATA start address 0x8000 and you have hardware that maps it into the CODE address range 0x8000 to 0xFFFF, or the RAM have XDATA start address 0 and maps into CODE space 0x0000 to 0x7FFF. If there isn't a unity mapping when the RAM is accessed as XDATA or as CODE, then you can't just do a type cast - you must then also take into account an offset.

Another thing - will your 32kB of XDATA-connected RAM map over the interrupt vectors? If not - what have you planned to do, to let a student create his own interrupt handler for a timer, UART etc?

But the huge question to ask: How can there already exist hardware for this, without these problems already having been covered? There should be documentation telling what your board can do.

It used to be a common trick on Trainers to overlay part of the code space with the XRAM. This allowed the monitor / loader program to be safe. And allowed the student to "program" the Trainer. Chips with Flash memory have made this unnecessary.

"Chips with Flash memory have made this unnecessary"

Indeed.

So, again, what is the goal of this "trainer"?

Is it for a course in computer archaeology...?!

computer archaeology
love the (here very appropiate) expression

Erik