You let the user provide his own USERCODE.C and USERCODE.H. You provide all your stuff pre-compiled as either .OBJ or .LIB files. Your user then compiles his modules and links his USERCODE.OBJ to the OBJ/LIB that you provide into the final .HEX which gets loaded into the target MCU.

The above is the simplest and most reliable way it can all work.

Of course you could go off and devise any number of other schemes where the users code is compiled and linked independently so it can be loaded at run time (maybe even ISP by the main code module). However in these cases in order to share functions it is necessary to define specific entry points in the main module via some type of function vector table.

If you really really must do the the latter thing above it is then best if you decide the specific functions to be shared and provide a documented interface between the function table main code and the user code. This is best achieved by using assembler language to craft up the interface and fully just use registers to pass values back and forth.

This gets all very messy to try to provide any other more general purpose set of functionality in sharing across languages, compilers and even tool versions. And then you start to look how to go about how to provide for either user global data and local data variables in the user code and how the particular main code compiler provides for that and you end up with a maintenance nightmare. I say this in a general case for small resource embedded systems and particular for '51 type MCUs.

In the end the first described scheme above is the only really practical and reliable way to make this work without having to administer some severe restrictions on the way the user code works and what resources are available to it. If I was forced to have to make something more along the lines of the second scheme then I would limit the user code to ASSEMBLER ONLY and REGISTER INTERFACE and PREDEFINED CALLBACKS in the main and maybe NO DATA variables.

Michael Karas