This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Plug in application modules

Hi All,

CPU: STM32F10x cortex-m3.
Keil compiler.

I wonder if anyone can point me in the right direction?

What I need to do is build a system that is made up of a core with modules that will be plugged in at a later point in time. I.E. the core will be compiled and run able, the product will then be configured for it specific variation by placing modules in memory for it to use. The modules will not be dynamic loaded, apart from at initial boot up where these modules will be resolved and hooked in.

The core will consist of the RL-RTX os, some basic house keeping tasks and base functionality that is able to hook into the added modules.

I guess in GNU/linux Id be using insmod or in windows a DLL, SMX by micro devices has dynamic load module facility which I think is a bit more than I need.

Any ideas how to do this?

Regards,
DaveE

Parents
  • There are no stylish solutions for your problem, I am afraid. Maybe you can generate a header file per module, describing (based on the respective .map file) where each function/variable reside. These header files can then be used throughout the program for address resolution.
    If you use a script for header file generation, you can keep your system functional as long as you re-build your the components from scratch when something changes. You must also pay attention to address collisions.

Reply
  • There are no stylish solutions for your problem, I am afraid. Maybe you can generate a header file per module, describing (based on the respective .map file) where each function/variable reside. These header files can then be used throughout the program for address resolution.
    If you use a script for header file generation, you can keep your system functional as long as you re-build your the components from scratch when something changes. You must also pay attention to address collisions.

Children
  • Go for #defines for building applications with different functionality. Splitting each "module" into a separate source file means that it should be enough with:

    #include "options.h"
    #if HAVE_MODULE_XX
    <optional file contents here>
    #endif // HAVE_MODULE_XX
    

    Handle language strings separately. They are simple data so you can download a large block with all strings directly after each other, and a final double-zero to end the block. Let the program locate the first, second, third, ... strings and use by the program. On boot, the application can scan through the strings once, and create a lookup table, which means that you don't have to bother anything with any dynamic linking. It will just be normal data to process.

    Having plugin modules is not something you should do for known functionality, but to allow extensions to be written after you have shippped the product, and where it isn't suitable with a boot loader and then reprogram the main application.

  • Thanks for the comments.

    How about if I produce a core obj file then link it with the swappable modules obj files, so long as the api of functions remain the same this I think achieves the same as I originaly intended without the associated memory problems?
    Then use control file for the linker to pick up the correct module versions.
    However it still requires a fully licensed linker to build the final image.

    I guess this is much the same as using a library but I pick the libraries late and I may use many of them.

    Have I missed anything/got the wrong idea?

  • Why not just auto-build 10 different customer editions whenever you make a release build. The build time should be short, and is made by you.

    Then combine an application download file with one of multiple language files when programming the unit in factory.

    It shouldn't matter so much if the language file contains the strings for the biggest deluxe edition of the application.

    Just remember that you are not limited to building from the IDE. You can set up a script to build any number of combinations automatically and a normal PC can produce a lot of binaries in an hour :)