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

howto: function library in separated hex-file

Due to the lack of flash memory i want to move code parts in a separate function library and locate the same in RAM. I thought to use the LIB166 and assign certain code modules to the RAM-address area.
In addition i want be able to build and deploy (download) this RAM function library without the need to build&programm the flashed code again. Means i need the hex-files: flashcode.h86 and functionlib.h86.
Is there a way to create a functionlib.h86 with the LIB166 and L166 which shares certain interface functions to a flashcode.h86? Or are there any alternative solutions?

Parents
  • "THE BEST WAY YOU STORE EACH FUNCTION CODE IN A HEX FILE. LOAD IT ONLY WHEN NEEDED."

    Besides managing to scream like a pig, your suggestion is also impractical. If each hex file has function object code statically linked, then each hex file is designed to load at one very specific address - which must not collide with any address range needed by another function that also needs to be called within a similar time frame.

    So if all these hex files just represents non-overlapping object code, then there is no reason for not concatenate them into a single hex file and load.

    Come back when you besides SCREAMING also have a good solution for dynamically relocating hex files while loading them, so they can be loaded at any address. First with dynamic relocation support will your suggestion be viable.

Reply
  • "THE BEST WAY YOU STORE EACH FUNCTION CODE IN A HEX FILE. LOAD IT ONLY WHEN NEEDED."

    Besides managing to scream like a pig, your suggestion is also impractical. If each hex file has function object code statically linked, then each hex file is designed to load at one very specific address - which must not collide with any address range needed by another function that also needs to be called within a similar time frame.

    So if all these hex files just represents non-overlapping object code, then there is no reason for not concatenate them into a single hex file and load.

    Come back when you besides SCREAMING also have a good solution for dynamically relocating hex files while loading them, so they can be loaded at any address. First with dynamic relocation support will your suggestion be viable.

Children
  • @Per and Andrew:
    A further solution #2 could be as followed - while using the C166 toolchain only.

    1. Reserve a RAM-Area and allign interfacing functions (addresses) to a RAM-Address area.
    (in case of a need assign for each function a dedicated address).
    2. Build (static link) the whole stuff - leads to one total hex-file eg. flashcode.h86
    3. Now create a further/new c-module which contains a dummy main().
    Now build a 2nd h86 functionlib.h86. Means build the dummy main() together with the modules cotaining the interface functions to a functionlib.h86 file. (ensure to have the use the same reserved RAM-Addresses as given in step#1.
    4. Flash the flashcode.h86. The target will have some code loaded in the RAM which of course is volatile.
    5. Download functionlib.h86 from the host-app on demand - means prior before any functionality of these interface functions are required.

    But before i dig more into this solutions i thought i'll ask this forum for help.
    Because i imagine that i am not the only one in the world with the issue:
    "Lack of flash-size" ,"extend code-space by using RAM"

  • "Lack of flash-size" ,"extend code-space by using RAM"

    The thing is, with most microcontrollers, the RAM size is significantly smaller than the Flash size - so this doesn't generally make a lot of sense.

    Rather than try to make the architecture do things it was never intended to, might it be better to seek-out a chip that's actually equipped for your task?

    Are you stuck with the C167CS ?

  • @Andrew:
    yes i am stuck with the C167CS! I want to do software maintenance for hardware which is out in the field. And I have 512KB RAM (~256KB free) and total 1MB Flash. Moving code-fragements of size ~5-10KB to the RAM would already meet my purpose.
    So it is worth to look into this.