LPC1788 - Bootloader and shared library

3
votes

I'm developing an embedded software for my custom board (LPC1788). My objective is to improve skill and experience regarding C programming for embedded systems.

I have implemented a USB Bootloader that launches the user application if it exists. Otherwise it is used to easily load the application through USB. My USB bootloader uses a static library board.a, and so does the user application.

Is there any trick how to reference board.a, which was linked into the binary of the bootloader, from the user application?

In other words, I want to optimize flash memory space by putting in the board.a code and data just once.

NB: I use LPCXpresso (NXP MCU Tools/GNU Make Builder) it invoke arm-none-eabi-gcc (GNU ARM Embedded Toolchain)

1
clinkerembeddedcortex-m3
I don't think there is an easy way to do it, but suppose that you in the future will improve the library board.a, so improving userApp too. You will be able to upload the new app with the improved library without touching the bootloader. This is the normal way of working - I mean: you flash the bootloader only once, and the app once or many times. I think that sharing the library is not a good idea. - linuxfan says Reinstate Monica
Yes, you have totally reason about upgrading board.a force to upgrade bootloader (un-normal working). I just wanted to optimize space. Thank you :) - hiak
In theory I don't see any reason why this wouldn't work. But it is dependent on your toolchain (compiler/linker), so please edit your question and add details on those. - user694733

1 Answers

2
votes

Just like using shared libraries on an operating system. your system design can be such that when the bootloader branches to the application it could for example use one of the registers (r0 for example) to contain the address to the "shared" library, or it could contain a pointer to an array of pointers that are the addresses to the individual functions within board.a that you want to share. Functions are nothing more than addresses from a linking/using perspective anyway so it is a matter of matching up function pointers in the application with the already in place functions in the address space (flash I assume). This is all that shared libraries do they just have libraries and stubs to help it be invisible to your applications that run on those operating systems.