I would think that from an empirical stand point that it is using the FPU. There are many many floating point math's. I would expect this would have been a performance issue if it was not using the FPU. Did you find a setting in the ChibiOS config or something similar which leads you to believe it is not using the FPU?
Yes, it did not do exactly what I first though, but there's definitely performance to be gained by switching to the "hard" FP ABI.
Also if you want to use LTO with GCC 5/6 you will have to use ChibiOS 3. Using git submodules would be perfect for that.
GCC 6 Available here: (binaries no longer on launchpad, that's why there's only 5.4) https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
I have Makefile I am using for command-line and build server, and I have my eclipse arm plugin project I use for gdb debugging.
With newer gcc, Makefile works and seems to work even if I add -g which is not there by default. But arm eclipse commands cause gcc linker to crash with internal error if I am using -g or -g3
Trying to figure out which different in gcc command lines makes the difference but I hate chasing things like that
About code optimization compiler flags, keep in mind that the code optimization flags will typically break the ability to step through code. I understand the russian doesn't use this as live messages across the serial line are typically considered better. However bozo's like myself who aren't fluent enough to find the bugs with live messages, find it handy for finding typo's. Also keep in mind that bozo's like myself don't contribute much to the code base. So if performance is an issue, then by all means optimize with the compiler flags. But if it's not required, it would be handy for bozo's like myself.
This is messing with line endings on linux...
It's best to set it to LF (or autocrlf true) and let git do the conversions.
Because of this I won't be able to merge the changes unless I fix a *lot* of files.
I never had to touch these settings for my projects (I code on linux and windows) and never had any line ending issues.
This is messing with line endings on linux...
It's best to set it to LF (or autocrlf true) and let git do the conversions.
Because of this I won't be able to merge the changes unless I fix a *lot* of files.
I never had to touch these settings for my projects (I code on linux and windows) and never had any line ending issues.
trust me, I hate the whole eol subject with passion
Please excuse my ignorance, I am not sure where to apply core.autocrlf = true exactly. Would that be a line in git repository or a setting on end user computers? I am not excited about a requirement for end users, myself included, to remember to change anything locally.
Would core.eol=SOMTHNG in .gitattributes help?
Are there specific file extensions you are having troubles with? I am temped to mention more extensions explicitly.
What happens for my projects is that they are always ended with LF.
There have been rare cases where I had to fix the CRLF crap, but I only had to do it once and never had any issues again.
float L = log(resistance);
if (L==resitance) {
crash("ERROR DETECTED);
}
originally this code is there because if compiler options are not right log() method returns the parameter, not log. Question: there should never be false positives, x never equals log(x) does it?
Can you limit the possible range of values, or do you know the possible range of values? For example on boot, is it 0? Is it FFFF? Looks like 0 is an error condition.
You do not have the required permissions to view the files attached to this post.
