On 22/05/14 16:14, Fabius wrote:> >> >> What the hell are you trying to do? Even a smallish ARM Cortex M4 has >> 512 KB of FLASH these days. Why are you trying to overlay?!?!? >> > 5MB..for now..How do you possibly manage to get 5 MB of code? It's easy to use up lots of space with data, and equally easy to handle loading that at runtime. If you really need that much code, get a Cortex M4 with an external memory bus and use that.
load binary modules at run time
Started by ●May 21, 2014
Reply by ●May 22, 20142014-05-22
Reply by ●May 22, 20142014-05-22
David Brown <david.brown@hesbynett.no> writes:> On 22/05/14 16:14, Fabius wrote: >> >>> >>> What the hell are you trying to do? Even a smallish ARM Cortex M4 has >>> 512 KB of FLASH these days. Why are you trying to overlay?!?!? >>> >> 5MB..for now.. > > How do you possibly manage to get 5 MB of code? It's easy to use up > lots of space with data, and equally easy to handle loading that at > runtime. > > If you really need that much code, get a Cortex M4 with an external > memory bus and use that.Thanks David. I wanted to say this, but I was supposing Fabius has some very weird corner-case. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●May 23, 20142014-05-23
On 23/05/14 01:26, Randy Yates wrote:> David Brown <david.brown@hesbynett.no> writes: > >> On 22/05/14 16:14, Fabius wrote: >>> >>>> >>>> What the hell are you trying to do? Even a smallish ARM Cortex M4 has >>>> 512 KB of FLASH these days. Why are you trying to overlay?!?!? >>>> >>> 5MB..for now.. >> >> How do you possibly manage to get 5 MB of code? It's easy to use up >> lots of space with data, and equally easy to handle loading that at >> runtime. >> >> If you really need that much code, get a Cortex M4 with an external >> memory bus and use that. > > Thanks David. I wanted to say this, but I was supposing Fabius has some > very weird corner-case. >I'm sure he has good reasons for wanting this arrangement, but I think it could be worth his while taking a step back and telling us what he is looking for in the complete system. Then maybe he can get ideas here for alternative approaches that would work better.
Reply by ●May 23, 20142014-05-23
Il 23/05/2014 08:49, David Brown wrote:> > I'm sure he has good reasons for wanting this arrangement, but I think > it could be worth his while taking a step back and telling us what he is > looking for in the complete system. Then maybe he can get ideas here > for alternative approaches that would work better. >Thanks to all of you, I'll try to explain better the situation, sorry for my english: I'm developing a system where the user can choose a set of functionalities grouped by c modules, there are no dependencies between these modules. The user can wait 1 second to obtain the functionality but I would a fast system startup. 5 MB is the total sum of the binary modules for now, but I can load a single module on the internal SRAM without problem (I'd prefer keep secure this code.. ) from an SDcard where are stored (crypted). If I maintain only one project with all c modules thanks to the overlay method I'm able to develop this application..but I'm not happy that each time that I add o modify a module I have to recompile all the modules and the base system..I'd prefer a modular system.. I'm using a Cortex M4 (without MMU) with Crossworks (gcc).
Reply by ●May 23, 20142014-05-23
On 23.5.14 18:48, Fabius wrote:> Il 23/05/2014 08:49, David Brown wrote: >> >> I'm sure he has good reasons for wanting this arrangement, but I think >> it could be worth his while taking a step back and telling us what he is >> looking for in the complete system. Then maybe he can get ideas here >> for alternative approaches that would work better. >> > Thanks to all of you, I'll try to explain better the situation, sorry > for my english: > > I'm developing a system where the user can choose a set of > functionalities grouped by c modules, there are no dependencies between > these modules. The user can wait 1 second to obtain the functionality > but I would a fast system startup. > 5 MB is the total sum of the binary modules for now, but I can load a > single module on the internal SRAM without problem (I'd prefer keep > secure this code.. ) from an SDcard where are stored (crypted). > If I maintain only one project with all c modules thanks to the overlay > method I'm able to develop this application..but I'm not happy that each > time that I add o modify a module I have to recompile all the modules > and the base system..I'd prefer a modular system.. > > I'm using a Cortex M4 (without MMU) with Crossworks (gcc).I do not quite understand the re-compile requirement. The system is so large that it is sensible to build it from modules, and you need to re-compile only those modules that have been changed. The make utility helps automating this task. You do have to link the overlay file again, if an overlay changes, but there is no need to change the root code, unless the calling sequence to the overlay code changes. -- Tauno Voipio
Reply by ●May 23, 20142014-05-23
On Fri, 23 May 2014 17:48:40 +0200, Fabius <fabio.ferrari.aone@gmail.com> wrote:>Il 23/05/2014 08:49, David Brown wrote: >> >> I'm sure he has good reasons for wanting this arrangement, but I think >> it could be worth his while taking a step back and telling us what he is >> looking for in the complete system. Then maybe he can get ideas here >> for alternative approaches that would work better. >> >Thanks to all of you, I'll try to explain better the situation, sorry >for my english: > >I'm developing a system where the user can choose a set of >functionalities grouped by c modules, there are no dependencies between >these modules. The user can wait 1 second to obtain the functionality >but I would a fast system startup. >5 MB is the total sum of the binary modules for now, but I can load a >single module on the internal SRAM without problem (I'd prefer keep >secure this code.. ) from an SDcard where are stored (crypted). >If I maintain only one project with all c modules thanks to the overlay >method I'm able to develop this application..but I'm not happy that each >time that I add o modify a module I have to recompile all the modules >and the base system..I'd prefer a modular system.. > >I'm using a Cortex M4 (without MMU) with Crossworks (gcc).Sounds like a classic overlay loading case. I don't know the features of the tool chain but assuming that the linker is capable of generating pure binary modules for a specific load address, things should be quite simple. Just decide a common load address for all your 100 object modules and compile and link them independently with that load address. No need for position independent code (PIC) or for fixups during loading. If you change one module, just recompile that module. If your modules use some common routines, such as C-runtime routines, put these into the root of the tree. Link this root and get a symbol table file from that linking. Link all your modules against this symbol table file. If you change the tree root, you need to generate a new symbol table file and relink all your 100 modules against it. If your module contains multiple entry point, link an indirect jump table in the beginning of each module, so you can recompile each module independently. I have used this trick, when programming a 4 to 8 KiB EPROM took at least 5 minutes each, thus making a change to one routine took only 5 minutes to reprogram instead of using an hour to reprogram a dozen EPROMS. You should look at the documentation of your tool chain, if you can specify an absolute load address for compilation and linking and also verify that you can generate an absolute file (no relocation or fixups, no debug info) in file. You could also search for terms like "autoload vector" "RSX-11" (with quotes), to see how autoload was implemented in the past, but of with manual overlay loading, there were far more alternatives on a PDP-11.
Reply by ●May 24, 20142014-05-24
FabiusAone wrote:> > Hi guys, > > I have 100 c modules, my system has to run only one module at a time (at run time); these modules have few functions called by the system and these have the same prototipe for every module. These modules has a lot of dependencies with the system. > My first approach was create only one project with all files, assign one section for each module, specify that all these sections must run in the same section. > > Example: module A, B > > name=".text_A" runin=".text_runmodule" > name=".rodata_A" runin=".rodata_runmodule" > name=".data_A" runin=".data_runmodule" > name=".bss_A" runin=".bss_runmodule" > > name=".text_B" runin=".text_runmodule" > name=".rodata_B" runin=".rodata_runmodule" > name=".data_B" runin=".data_runmodule" > name=".bss_B" runin=".bss_runmodule" > > > with objcopy I extracted all the sections so I can create A.bin a B.bin e load these files at run time on the runmodule sections (in RAM) > > I created an array of a structure that contains pointer to the module's functions. > > drawbacks are: > 1 - I have to create a lot of sections > 2 - when I'm working with a module, I have to exclude from build the other modules to speed up time > 3 - every time I modify a module I have to recompile all the modules because system has changed..and theoretically I SHOULD retest all the modules.. > > Any suggestion? Static or shared library? What else?.. > > Thanks, > Fabius >It looks a lot like you're using Linux. That probably means you have POSIX. The POSIX constellation has dlopen / dlsym / dlerror / dlclose to dynamically load modules. I've only used this with .so files, but it may go beyond that. The fail cases for this are *painful* but it works. When you do this, it might be worthwhile to get out of the IDE and use a console/shell prompt and makefiles. You'll have to more or less hand-code dependencies somewhere, but if you're rigorous with header files, you can use "gcc -M" to generate a file full of dependencies and munge that. You sound (downthread) like you *really* need a good regression suite derived from unit tests and integration tests. -- Les Cargill
