[avrdude-dev] Re: sharing code between bootloader and application

[Joerg Wunsch]

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. ;-)