This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Static library

Hi

I have a project made with a custom board with STM32F3, and I use ARM Keil and ARM Tools for development of the project. The current memory's layout is a partition for bootloader and other for firmware. Now, the project's specifications is changed and the memory layout is divided by 3 partition: a bootloader, kernel, firmware. The kernel has a relevant and critical functions which the final user cannot update, only can update the firmware partition.

I was thinking do a library which contains the kernel but this library must be in a static partition of the memory and some functions must be allocated in a specific address because the firmware has to access it. Do I need make a keil project to build and generate a lib? In the firmware keil project, how can a made an interface to access in the function's library?

Best regards

Parents
  • The kernel must be 100% self-sufficient unless you want a lot of problems later on.

    With the kernel as a library, the linker may link the symbols to different addresses at different times.

    And with the kernel as a library, the kernel and the firmware will share the same set of runtime library functions which includes all internal, hidden, symbols within the runtime library. And besides the obvious RTL functions, the compiler regularly introduces hidden helper functions, such as for 64-bit arithmetic or similar that might be too large to inline at every needed location.

    So build the boot loader as one project. And the kernel as a second object. And then the updateable part as a third project - and this project might then make use of a pointer table or similar to locate the entry points in the kernel. This makes the kernel behave similar to a BIOS in a computer - an update of a program doesn't require the BIOS to be updated, and an update of the BIOS doesn't require the application to be updated.

Reply
  • The kernel must be 100% self-sufficient unless you want a lot of problems later on.

    With the kernel as a library, the linker may link the symbols to different addresses at different times.

    And with the kernel as a library, the kernel and the firmware will share the same set of runtime library functions which includes all internal, hidden, symbols within the runtime library. And besides the obvious RTL functions, the compiler regularly introduces hidden helper functions, such as for 64-bit arithmetic or similar that might be too large to inline at every needed location.

    So build the boot loader as one project. And the kernel as a second object. And then the updateable part as a third project - and this project might then make use of a pointer table or similar to locate the entry points in the kernel. This makes the kernel behave similar to a BIOS in a computer - an update of a program doesn't require the BIOS to be updated, and an update of the BIOS doesn't require the application to be updated.

Children