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?
But RAM is volatile. So you need to store any code you want to run from RAM in either the flash, or some (possibly serially connected) external non-volatile memory.
Are you sure that you have selected the correct processor for your task? The processor selection process is one of the most important steps in a development process.
I've a technical solution where a host-application always downloads via a USB-connection volatile data into the RAM and then invokes commands to the Infineon C167CS MCU. I intend to just attach the functlib.h86 to the download data and eg. invoke then any further functionlib-attach procedures (if necessary).
So ja, the MCU C167CS seem to set correctly.
Per, thank you for your response.
THE BEST WAY YOU STORE EACH FUNCTION CODE IN A HEX FILE. LOAD IT ONLY WHEN NEEDED.
What you're describing is a Dynamically-Linked Library (DLL).
The Libraries used by C166 are (designed to be) Statically-Linked - so you have a whole bunch of work to do to implement the dynamic linking...
"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.
@Andrew: ja, even i thought at a 1st glance i've to the whole Dynamic Link Lib bunch. And in fact, that can be solution.
However it think it is not necessarily required. For my embedded device/ use case a general static link could be still sufficient. But what i need is to break up the static link/build into two separated hex-files.
So i've eg. one solution in mind: 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. Extract from flashcode.h86 the reserved RAM-Area parts to a separate functionlib.h86 4. Flash the flashcode.h86 and later download the functionlib.h86 on demand. 5. In case of required modifications in functionlib.h86, modify the code and do steps #2-#4 again except NOT to program the flashcode.h86 again.
What i dont like at this solution that there will be a lot of proprietary convetions/rules for the build steps. I'd prefer more a tricky solution which could be done with the given C166 Tool chain only.
@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.