As Dave N6NZ wrote: > >But next time please start a new thread, and in the right mailing > >list. This issue is more for the avr-gcc-list mailing list.
> OK. I wasn't aware of that list. I took the liberty to invite you. ;-) OK, let's move that thread over there: please do respect the mail-followup-to header of this message. [about sharing code between bootloader and application] > >You're right, that is one idea. Other people have also built the > >application and bootloader together. There is no one right way of > >doing this. > Sure. But is there *a* right way of doing this that is easy to > explain, has a clean implementation, and solves most people's > problems? I once drafted a solution which you can find here: http://www.mikrocontroller.net/topic/63508#504663 The link is in the header of that article. If you can't see it (maybe you need to be logged in), it's http://www.mikrocontroller.net/attachment/21170/shlib.tar.gz Knut Schwichtenberg sent me an improvement for it which I haven't found the time yet to really look into (and probably won't be able before leaving for vacation). Once I'm through his submission, I intend to roll all this into another demo application for avr-libc, as it appears this becomes a frequently requested item. As you might guess from the above name, it features a simple `shared library'-style implementation: you create a common (shared) set of library functions by linking them together, prepended by a jump table forming the public entrypoints. The jump table is accompanied by a stub module that only declares its entry point symbols. When you link your final application(s) (or the bootloader), you include the symbols from this stub, so whenever a function is requested that is present in the shared library, this request will be satisfied from that stub rather than dragged in from the actual (standard) library. Anything else will still be linked from the library. Everything is transparent to the user at this point, they link their applications as usual, only including the symbols from the stub. Obviously, functions that require local data (.data or .bss) are not really suitable candidates for a shared library. (The original Unix shared lib approach did eventually resolve that issue, but I think it's just too cumbersome for our small applications to deal with, so I didn't investigate how it could be done.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ avrdude-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avrdude-dev
