rusefi.com

https://github.com/rusefi/rusefi/issues/374 fixed

That's four hours of banging my head against a wall. Few years ago 400K for firmware size seemed like it would be forever enough. Not anymore

This fix changes the location of settings in flash - so full settings reload would be needed, should be easy with TS.

Maybe it's time to use LTO and switch to -Os instead of -O2

I also see that you don't use the FPU, is there a good reason?

mobyfab wrote:I also see that you don't use the FPU, is there a good reason?

I was under the impression that rusEfi uses FPU, does it not?

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?

https://github.com/rusefi/rusefi/blob/master/firmware/Makefile#L62

You're using softfp in the Makefile, so it's not fully used.
It has to copy register data from regular to FP registers everytime you need FP.

see http://www.gurucoding.com/en/rpi_cross_compiler/diff_hardfp_softfp.php
https://wiki.debian.org/ArmHardFloatPort/VfpComparison#A.22softfp.22

mobyfab wrote:https://github.com/rusefi/rusefi/blob/master/firmware/Makefile#L62

So yes, softfp is not exactly "FPU is disabled" I see you've edited that, but still a great question why softfp - https://github.com/rusefi/rusefi/issues/375

for some reason the latest posts in this thread make me smile

does it mean that a lot of processing power was concealed under the hood?

russian wrote:

mobyfab wrote:https://github.com/rusefi/rusefi/blob/master/firmware/Makefile#L62

So yes, softfp is not exactly "FPU is disabled" I see you've edited that, but still a great question why softfp - https://github.com/rusefi/rusefi/issues/375

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

mobyfab wrote:Also if you want to use LTO with GCC 5/6 you will have to use ChibiOS 3.

Why? Is that a Chibios 2 bug? What's the relationship between LTO, GCC 5+ and ChibiIS 3?

Migrating rusEfi to ChibiOS 3 is a bit more involved than just pointing at the right version of ChibiOS git.

Fixed https://github.com/rusefi/rusefi/issues/375 - do not see much change in performance, see https://github.com/rusefi/rusefi/issues/375 for detailes. Method durations in the bottom comment there are in CPU ticks.

russian wrote:

mobyfab wrote:Also if you want to use LTO with GCC 5/6 you will have to use ChibiOS 3.

Why? Is that a Chibios 2 bug? What's the relationship between LTO, GCC 5+ and ChibiIS 3?

Migrating rusEfi to ChibiOS 3 is a bit more involved than just pointing at the right version of ChibiOS git.

Yes it's a ChibiOS bug as far as I remember.
LTO only used to work with GCC 4.8 on ChibiOS 2 in my case.

Moving to ChibiOS 3 is not that complicated but there's a lot of refactoring involved since you'll be moving to oshal.
This can be automated.

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.

You are already using code optimisation, else it would probably not fit in the flash.
LTO is just a better type of optimisation.

I'm having a look at the ChibiOS 3 port.

mobyfab wrote:I'm having a look at the ChibiOS 3 port.

that would be great help!

See also https://github.com/rusefi/rusefi/issues/72 - it has a reference to my old attempt with 3.0 branch

https://github.com/rusefi/rusefi/blob/master/.gitattributes#L6

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.

Work in progress, for some reason the linker cannot find the C references, even when linking with G++.
https://github.com/fpoussin/rusefi/tree/chibios-update

arm-none-eabi-size build/rusefi.elf
text data bss dec hex filename
237776 3984 181824 423584 676a0 build/rusefi.elf

That was the "Smart build" that was preventing to compile all the files since the configs are in a different folder.

https://github.com/rusefi/rusefi/pull/379

mobyfab wrote:https://github.com/rusefi/rusefi/blob/master/.gitattributes#L6

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.

You can add the "* text oel=lf" in .gitattributes

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.

This is what I'm talking about:

mobyfab wrote:You can add the "* text oel=lf" in .gitattributes

Done, also .mk is now explicitly text.

mobyfab wrote:You can add the "* text oel=lf" in .gitattributes

eol stands for End Of Line, so eol not oel

Also I believe it's a bit brutal to declare "*" to be text

I am now trying another version of the magic file, let's see...

russian wrote:I am now trying another version of the magic file, let's see...

https://github.com/rusefi/rusefi/blob/master/.gitattributes

Hard to say, maybe progress? At least now my brand new copy of git repository is not modified by itself right away.

That annoying "page 0 burn error" looks to be rusEfi but, to be continued - https://github.com/rusefi/rusefi/issues/336

super annoying bug https://github.com/rusefi/rusefi/issues/336 fixed!

russian wrote:super annoying bug https://github.com/rusefi/rusefi/issues/336 fixed!

That's awesome news. It was indeed quite annoying. On to the next bug?

stefanst wrote:On to the next bug?

Current highest priority is https://github.com/rusefi/rusefi/issues/4

I have an intermittent bug
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?

Maybe I am not hanging NaN resistance right.

What is the range of resistance?

kb1gtt wrote:What is the range of resistance?

Pretty much anything? That's "low point" resistance, CLT parameter - not resistance I ready from the sensor.

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.