David Kelly wrote: > On Mon, May 11, 2009 at 08:21:37AM -0600, Weddington, Eric wrote: > >>>> Sounds to me as if you are making the "bootloader" too big and >>>> should simply link an entire application for every possible >>>> target. What you are doing would make more sense if the loadable >>>> modules could run out of RAM. >>>> >>> That would be no use, the loadables must be non-volatile. This is a >>> tester that will be sent to a factory (somewhere). When a new >>> product is to be tested, I can e-mail them the test routine which >>> they then burn into flash (each of these is 0x900 bytes, there can >>> be up to 0x0a of them). >>> >> Why is this method superior to having a regular bootloader, and you >> have N applications, where each application is the individual test >> routine and the common portion? Why do you have create this custom >> interface which has its own set of problems? Alternatively, creating a >> custom Makefile to handle building 10 different applications is >> certainly easier in comparison. >> > > I agree, thats how I would handle it. Either build a custom linked > application for each customer or provide the customer with the tools to > build one of their own. What he is trying to do is in effect create a > run time program linker. > > Eric, David etc.,
Thanks for the suggestions but it seems I haven't explained the problem properly. The end users of this equipment will be factory operators who cannot compile, link or do any of these software things. Thus I have developed an extremely simple (read idiot-proof [i hope]) interface to use with a terminal program (minicom, teraterm etc.). This is far more simple than any existing boot loader (OK, I *could* write my own, but I'm too far along now). The loadable elements are small (0x900) and will only ever be updated one at a time. If I compiled and linked the whole lot, then each small change would requite the sending & loading of 64k of code, which I think is much too much for these people (and, for compatibilty with modern PCs, the comms. is run over a USB virtual RS-232 port which produces far too many serial errors for my liking - but that's another issue). I have the entire application written and am knocking the last bugs out now. I confess that GCC seems to me to be mostly something to fight with, perhaps I have been spoiled in the past using manufacturer's C compliers that were tailored especially for the target. I simply require a way to fix absolutely this jump table in memory. Whether I write it in C or assembler seems to me to be irrelevant, as is using an array of pointer to functions, because I still have the problem of fixing these at absolute addresses. If anyone knows a way to do this, I would very much appreciate it. Many thanks for all the input, Robert. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
