Hello,
integrating some additonal code initially developed on top of the firmware from early 2019 (and worked fine there), I integrated this code into the most recent firmware version.
Doing so, compiling (cload) was not successful, causing the error ".bss" will not fit in region 'RAM'. Reducing memory usage for my algorithm solved this issue, but I wanted to even extend the algorithm. Of course, I should also consider a more efficient implementation for my stuff, but I continuously plan to make modifications around the crazyflie (its basically our research plattform).
Since the algorithm worked out in the old firmware without any modifications, other firmware parts seem to need more RAM in the current version.
So my question is:
Do you have any advice how to reduce memory usage of the basis firmware? We are developing decentral swarm applications and we currently make use of the flow deck v2 the LPS deck (in tdoa Mode, tdoa3 seems to be preferable for us) and also the Multiranger deck (not yet but intended), so using a heterogenous team to solve tasks.
Since, we do not plan to use the lighthouse deck, one might think of getting rid of the relating functions to hopefully free some additional RAM.
Other aspects would be the different controllers - I think we will use one and do not plan to switch (maybe even an own-developed one some day).
However, instead of brutally deleting code, there might be some better way in order to keep in touch with your overall firmware progress and potential bug-fixes.
There might also be possibilities to store data outside the RAM. Some hints for such a solution would also be beneficial.
Thank you in advance
Klaus
Free RAM for additional code mofications
Re: Free RAM for additional code mofications
Hi!
There has been a lot of changes to the firmware since 2009 and mostly additions, so indeed RAM is starting to run out. We need start pruning the firmware in order to free this up, as it would be good for users like you to continue adding more functionalities to the firmware.
You could try to disable code that is not used, by putting #defines around them. There are currently 3 controllers and 2 kalmanfilters, and to disable the LPS modes that are not using. You can also look into using the CCM RAM on the stm (https://github.com/bitcraze/crazyflie-f ... issues/546), which gives an additional 64 kb.
In general, I would advise to start thinking about which elements of your current code would be useful to integrate in the current firmware. For instance, we have a pull request currently going on to store position of other crazyflies (https://github.com/bitcraze/crazyflie-firmware/pulls), which seems to be usable for your application as well? If it exists in the firmware, we test it with every release and maintain it. Anything that is not generic enough to integrate, can be done as an out-of-tree build in the applayer: https://www.bitcraze.io/documentation/r ... app_layer/
So, if you can think about which blocks and modules can be added to the crazyflie firmware, please mention this list as an issue/ticket on https://github.com/bitcraze/crazyflie-firmware/issues. Then we can discuss about which elements can be integrated and which is more suitable for the applayer.
There has been a lot of changes to the firmware since 2009 and mostly additions, so indeed RAM is starting to run out. We need start pruning the firmware in order to free this up, as it would be good for users like you to continue adding more functionalities to the firmware.
You could try to disable code that is not used, by putting #defines around them. There are currently 3 controllers and 2 kalmanfilters, and to disable the LPS modes that are not using. You can also look into using the CCM RAM on the stm (https://github.com/bitcraze/crazyflie-f ... issues/546), which gives an additional 64 kb.
In general, I would advise to start thinking about which elements of your current code would be useful to integrate in the current firmware. For instance, we have a pull request currently going on to store position of other crazyflies (https://github.com/bitcraze/crazyflie-firmware/pulls), which seems to be usable for your application as well? If it exists in the firmware, we test it with every release and maintain it. Anything that is not generic enough to integrate, can be done as an out-of-tree build in the applayer: https://www.bitcraze.io/documentation/r ... app_layer/
So, if you can think about which blocks and modules can be added to the crazyflie firmware, please mention this list as an issue/ticket on https://github.com/bitcraze/crazyflie-firmware/issues. Then we can discuss about which elements can be integrated and which is more suitable for the applayer.
Re: Free RAM for additional code mofications
Good Morning!
Thank you very much. We'll make use of your tipps - there is an additional requirement to store path data from at least one other Crazyflie in addition to the own path for the algorithm we plan to implement soon.
Storing positions of other Crazyflies -> definitely yes, this would be very desirable.
We will discuss requirements like those internally and post them as issues.
Thank you very much. We'll make use of your tipps - there is an additional requirement to store path data from at least one other Crazyflie in addition to the own path for the algorithm we plan to implement soon.
Storing positions of other Crazyflies -> definitely yes, this would be very desirable.
We will discuss requirements like those internally and post them as issues.
-
kristoffer
- Bitcraze
- Posts: 630
- Joined: Tue Jun 30, 2015 7:47 am
Re: Free RAM for additional code mofications
A few additional comments:
If you are not using the high level commander, there is a fairly large chunk of memory to be freed here https://github.com/bitcraze/crazyflie-f ... evel.c#L86.
We have been discussing moving statically allocated task stacks and queues to the CCM RAM. It can probably be done by modifying the macros in https://github.com/bitcraze/crazyflie-f ... atic_mem.h, but I have not had the time to look at it. I think it would give free up quite some "normal" RAM.
If you are not using the high level commander, there is a fairly large chunk of memory to be freed here https://github.com/bitcraze/crazyflie-f ... evel.c#L86.
We have been discussing moving statically allocated task stacks and queues to the CCM RAM. It can probably be done by modifying the macros in https://github.com/bitcraze/crazyflie-f ... atic_mem.h, but I have not had the time to look at it. I think it would give free up quite some "normal" RAM.