Hello,
I am working on an embedded systems framework based on ChibiOS/RT. The framework is intended for UAV peripherals, and provides device drivers, UAVCAN protocol support, publish-subscribe and worker threads. A lot of common functionality (e.g., transmitting UAVCAN heartbeats, retrieving messages left in RAM by the bootloader) is supported just by adding a single line to the Makefile.
I'd like to reduce the flash footprint in general, but especially for a particular use-case: a bootloader. The bootloader can be single threaded, but because all of these modules use publish-subscribe and worker threads in order to be self-sufficient and independent of each other, that single thread needs to be a worker thread. Currently, I can get the footprint for an "empty application" - that is, an application with all of the UAVCAN functionality - down to about 15k. I am targetting 12k for the bootloader, so I need to cut out at least probably 4-5k of flash. Since the bootloader can be single threaded, it shouldn't need to use ChibiOS/RT - it can just use the ChibiOS startup code and the ChibiOS HAL. But most modules use ChibiOS/RT APIs -
primarily, the coremem allocator, mailboxes, threading APIs and mutexes. Obviously, I'll have to ifdef away all of the threading APIs and mutexes, but I can't do that to the coremem allocator and mailboxes. Will I have to re-implement those or can they be easily used stand-alone?
A couple of notes and questions from what I've seen in the nm output:
- "0000008c r pal_default_config" I'd prefer to just leave GPIOs in their reset state and use PAL APIs to configure them individually.
- For some reason I'm getting about 90 of these: "00000002 T Vector1C" - it seems like, given that this is a weak symbol that just aliases to _unhandled_exception, they shouldn't be emitted individually. Anyone know why they are?
- "000001a0 D _vectors" - does this need to be in RAM? 416 bytes is a bit of a blow when you only have 16k. (I'll investigate this further tomorrow.)
Thanks,
Jonathan
reducing flash usage
Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: reducing flash usage
Hi,
HAL can be used without RT, there is a bare-metal OSAL that emulates the required functionalities of the RTOS, you may use the OSAL API for your bootloader, it is very close to the RT API except it is prefixed by "osal" instead of "ch".
You may re-implement the core allocator easily, it uses nothing of the RTOS. Mailboxes are not available under OSAL but could be implemented, just change the API inside and keep everything else equal.
Consider that RT, in its reduced configuration can be very small, make sure that all those changes are worth the time spent.
The "VectorXX" symbols are the entries in the IRQ table, it is strange if you see those undefined, those are all weakly defaulted to a common symbol. "_vectors" is the base of the table and usually it is in flash.
Giovanni
HAL can be used without RT, there is a bare-metal OSAL that emulates the required functionalities of the RTOS, you may use the OSAL API for your bootloader, it is very close to the RT API except it is prefixed by "osal" instead of "ch".
You may re-implement the core allocator easily, it uses nothing of the RTOS. Mailboxes are not available under OSAL but could be implemented, just change the API inside and keep everything else equal.
Consider that RT, in its reduced configuration can be very small, make sure that all those changes are worth the time spent.
The "VectorXX" symbols are the entries in the IRQ table, it is strange if you see those undefined, those are all weakly defaulted to a common symbol. "_vectors" is the base of the table and usually it is in flash.
Giovanni
Re: reducing flash usage
Perhaps my ld script is wrong and is placing the vectors in ram instead of flash.
Re: reducing flash usage
Hmm. The ld script has basically this:
Code: Select all
MEMORY
{
bl (rx) : ORIGIN = 0x08000000, LENGTH = 12K
app (rx) : ORIGIN = 0x08000000+12K, LENGTH = 64K-12K-4K
param1 (rx) : ORIGIN = 0x08000000+60K, LENGTH = 2K
param2 (rx) : ORIGIN = 0x08000000+62K, LENGTH = 2K
ram (rwx) : ORIGIN = 0x20000000, LENGTH = 16K-256
app_bl_shared (rwx) : ORIGIN = 0x20000000+(16K-256), LENGTH = 256
}
REGION_ALIAS("PROGRAM_REGION", app)
REGION_ALIAS("VECTORS_FLASH", PROGRAM_REGION);
REGION_ALIAS("VECTORS_FLASH_LMA", PROGRAM_REGION);
[...]
SECTIONS
{
.vectors : ALIGN(16)
{
KEEP(*(.vectors))
} > VECTORS_FLASH AT > VECTORS_FLASH_LMA
}
Re: reducing flash usage
Question about the vector table... Presumably it is ok to use the flash occupied by disabled vectors for data? The simplest way would be to truncate the vector table after the highest vector that is in use.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: reducing flash usage
Yes, it is possible.
You may also save significant space by removing the functions alignment option in the makefile if present. I assume you are already using -Os as optimization level.
Giovanni
You may also save significant space by removing the functions alignment option in the makefile if present. I assume you are already using -Os as optimization level.
Giovanni
Re: reducing flash usage
Giovanni, any opposition to removing pal_default_config in favor of requiring users to call the PAL APIs to configure each individual pad? Eliminating it saves me 244 bytes of flash and simplifies my code.
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: reducing flash usage
You need to disable it in source code, it does not have a switch. Probably you just need to comment out the function call, code and table should then be garbage collected.
Giovanni
Giovanni
Who is online
Users browsing this forum: No registered users and 19 guests