NotFastEnuf
Enable ARM GCC-8 to build the project
- Merge the makefile script with the one for Keil. USE_GCC controls which compiler to be used. by default, KEIL C is used. make USE_GCC=1 will choose gcc as the compiler suite. or export USE_GCC=1 works as well.
- Integrate qfplib math library for gcc to replace built-in match lib, which is too large to fit in 16kb.
- Disable Gesture for now in order to fit into 16KB. there are still some optimization need be done so that gesture support can be reenable again.
based on #12 as fabs function call have to be replaced with fabsf to fit into 16KB.
I don't have a workable drone for me to test. If anyone can test and let me know if this works, I will be happy to know.
GCC-8 for ARM can be downloaded: https://developer.arm.com/-/media/Files/downloads/gnu-rm/8-2018q4/gcc-arm-none-eabi-8-2018-q4-major-linux.tar.bz2
I am curious why we have to fit inside the 16kb limit. Don't we have space up to 32kb? I know the spec says 16 but I thought we have always been able to flash up to 32. It would certainly solve a lot of problems if this is the case.
I didn't try that but the spec for stm32 says only 16KB
On Mon, Mar 18, 2019 at 10:58 AM NotFastEnuf [email protected] wrote:
I am curious why we have to fit inside the 16kb limit. Don't we have space up to 32kb?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/NotFastEnuf/NFE_Silverware/pull/13#issuecomment-473752004, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuzRE-GdPXuKadOnWq2CtXIZggQcJhxks5vXwC6gaJpZM4b309C .
-- -Howard
The chips we use are 32kb. Specified at 16kb but Silverxxx found that on the whole they're all at the higher whole capacity. I can't find the exact post
That's what I thought too. I'm successfully flashing past the 16kb spec anyway. I know this just created additional work for you squeezing it down just to add stuff back but should be worth it for the end result.
We can give user such an option to compile as 32KB. But it is at own risk type of thing. chip manufacturer doesn't grantee it will always work beyond the spec. This is exactly like over-clocking CPU. As far as for my own usage, I have devoTx. so I can map more options to channels. so lack fo gesture is not a really big problem for myself. But I can enable it for sure.
For qfplib, I'd like to keep it as it is more compact and fast from its own website. As it is widely used, I believe it is reliable. GCC version of silverware is not wide adopted anyway.
Apart from the fitting into 16kb discussion, fixing the fabs call to fabsf makes sense if we are only working with floats no?
