Disabled the LAPACK functions that take too much memory #184
Conversation
|
Test PASSed. |
|
Hmmmm, my vote would be a compiler macro for controlling this, probably based on compiler architecture. My concern is that this makes libswiftnav less portable, and also isn't configurable. I currently I don't exactly know what the conventions are within lapack (or similar libraries), for this sort of thing, but I'm sure @fnoble @henryhallam @gsmcmullin have good ideas. |
|
agreed that this should be controlled by a compiler macro via #ifdef / #else but I would prefer that that macro be explicitly defined in our makefile rather than based on compiler architecture. That way we could still build the stack-hogging version for ARM if we had an ARM with more RAM, and we can also build the small-stack version for x86 for SITL testing. |
|
Does chibiOS have a notion of a ulimit? If chibiOS (or whatever we're using) has a memory management control that'll death scream if a function allocates insane memory, that could also work #DoesNotKnowAnythingAboutRTOSes. |
|
unfortunately not, there's no proper memory management unit on the Cortex-M4. There is a memory protection unit but its capabilities are limited and we aren't using it at all at the moment. |
|
After talking with @fnoble, I think we should just move away from lapack altogether for embedded linear algebra, since the constraints of an embedded environment are different from what lapack was written for and and now we know which functionality we really need. (We can still build off of BLAS if we need. It doesn't really allocate anything anywhere). In the meantime, we should just do it more or less the way I did in this PR. I'll change it to using an #ifdef / #else and throw something in the makefile as @henryhallam suggested. |
|
Test PASSed. |
|
Test PASSed. |
|
Test PASSed. |
|
Test PASSed. |
Disabled the LAPACK functions that take too much memory
5 participants
They still error if called, but now they'll error in a way that says "Hey look at me. I'm a stupid function that allocates a few dozen kB of stack even though I hardly need any of it."