Search code examples
cembeddeddriverstm32

Embedded Design - An external software uses internal software api's


I'm using an STM32F103C8 to develop a minimal game console The issue is that I want to build a separate project that includes a "game development library" which will include APIs to control the screen, audio, inputs etc.. basically a framework for game development that each "game-dev studio" uses to build it's game, however these functions need to use the actual drivers that reside in the core (hidden from the game developer), how do I access my internal drivers to provide an external API to some functions

how do I make that link between different bin files?


Solution

  • First of all please note that simply handing over the complete source with an API in the form of a header file, then letting the users link it all together with their program, is the easiest solution by far.

    That being said, then similar solutions do exist on various Cortex M, where the silicon vendors have placed firmware in non-accessible memory locations - most typically drivers for bootloaders, hiding away the flash/eeprom driver as well as the serial bus drivers. This relies on those functions being programmed at fixed, physical memory locations, where the functions were written using the same calling convention (likely ARM EABI) as the C code calling them.

    Similarly, you could link your API to fixed, absolute memory locations using a custom linker script, then provide access using function pointer casts. Here is some pseudo code example, using gcc-like syntax.

    Internal implementation, not available to the user:

    void mylib_init (void) __attribute__((section(".mylib_init")));
    

    Public API, does not have access to the indentifer mylib_init, so it has to be created:

    #define MYLIB_INIT_ADDRESS 0x12345678u // physical address of .mylib_init
    
    typedef void mylib_init_t (void);
    #define mylib_init ((mylib_init_t* const) MYLIB_INIT_ADDRESS)
    
    
    // usage:
    #include "public_api.h"
    ...
    mylib_init();
    

    You would still preferably just use one binary, because downloading two different binaries one at a time, programming different areas, is going to be painful. Likely possible (been there done that) but needlessly complex. Maybe it's possible to merge two .bin files with some handy tool, maybe the GNU S-record libs can do that(?).