I have decided to make one of my ideas open source.
I do not know if SplitCode is a known solution but I did try to find that out. All I have found is that the very ends of SplitCode idea are tangent to the "Link to SRAM" and "Link to Flash" build options available in some IDEs (like uVision, CoIDE or CodeWarrior). Both are also available in SplitCode, with the core of the SplitCode continuum spanning in between those.
First, what has already been made and what the plan is:
- publish the basic, bulletproof project in a public git repository. One architecture, one toolchain, one vendor, one chip.
- design at least several partitioning policies for SplitCode. Currently there are only four available, that is:
- "Link to SRAM",
- ....(placeholder for other todo policies)
- "Convenient", a good starting point,
- "Advanced" laying close to "Link to Flash",
- "Link to Flash".
- include the libraries in partitioning process (currently only object files are partitioned)
- make the policies as independent/reusable as possible (each architecture would have to have a separate set of policies but within architecture code reuse is possible).
- the partitioning algorithm should be eventually implemented as a part (module) of the linker (ld) but for development purposes it is currently kept as makefile, thus it slows down linking stage a little bit.
- each policy has some underlying guidelines the end-user should follow. If some guideline is violated then the user has to be explicitly informed about that, why such violation decreases the development efficiency and how to improve. This part is far from complete.
- comparing hex files should not use cmp but rather should check if a binary loaded contains a binary to be loaded. In other words removing data from end of binary should not create "ROM has changed" message because the code can still be run.
- I would like the SplitCode project to become an integral part of GNU ARM Eclipse plug-in one day.