Page 13 of 17

Re: Firmware developent status

Posted: Wed Jan 24, 2018 12:17 pm
by andreika
russian wrote:
Wed Jan 24, 2018 3:44 am
minor issue with it - need to fix
See also:
https://github.com/rusefi/ChibiOS/pull/2
https://github.com/rusefi/rusefi/pull/552

Re: Firmware developent status

Posted: Thu Jul 26, 2018 11:34 pm
by AndreyB
Has been over six months since the last post here :(

Anyway minor defect fixed https://github.com/rusefi/rusefi/issues/598 - this was affecting naked stm32f4 boards which for some reason would read trigger signals probably from EMI? Those ghost random signal were crashing the firmware if some major trigger settings were to be adjusted.

Defect fixed & a recommendation to ground four pins added to https://rusefi.com/wiki/index.php?title=Manual:Try_It#5th_adventure_-_I_have_only_the_discovery_board._What_can_I_do.3F if you are trying rusEfi on just a board without Frankenso.

Re: Firmware developent status

Posted: Sat Jul 28, 2018 10:37 pm
by AndreyB
https://github.com/rusefi/rusefi/issues/517 fixed - Makefile is now compatible with 2017 and 2018 versions of the GCC compiler. Official binaries are now compiled with gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)

Re: Firmware developent status

Posted: Sat Oct 13, 2018 3:04 pm
by AndreyB
rusEfi console now uses fresh OpenOCD 0.10.0 which allowed us to remove this annoying "Older ST-link mode" checkbox - both older and current st-link adapters now work the same. Also startup dialog layout was change in order to make it less confusing.

Re: Firmware developent status

Posted: Mon Dec 24, 2018 5:44 am
by AndreyB
Have you seen https://www.patreon.com/rusefi?

Anyway, question has came up if we can increase fast ADC callback frequency from current 10KHz (which is once per 3.6 degrees at 6000 RPM) so I got curious to gather some CPU utilization statistics. https://github.com/rusefi/rusefi/commit/a549009c99a42c577b8d6b4ab358557908af4f46

Naked discovery on the bench - surprisingly high count of IRQ per second and surprisingly high CPU consumption for IRQ

Code: Select all

2018-12-24 00_22: EngineState: perSecondIrqDuration=39929504 ticks / perSecondIrqCounter=24795
2018-12-24 00_22: EngineState: IRQ CPU utilization 23.767562866%


2018-12-24 00_22: EngineState: perSecondIrqDuration=39016138 ticks / perSecondIrqCounter=24567
2018-12-24 00_22: EngineState: IRQ CPU utilization 23.223890304%
Grounded PA5 & PC6 to reduce effects of weather on Mars

Code: Select all

2018-12-24 00_25: EngineState: perSecondIrqDuration=33897366 ticks / perSecondIrqCounter=24380
2018-12-24 00_25: EngineState: IRQ CPU utilization 20.177005767%
Adding a tiny antenna to PA5 & PC6 to increase effects of weather on Mars

Code: Select all

2018-12-24 00_26: EngineState: perSecondIrqDuration=42725075 ticks / perSecondIrqCounter=25006
2018-12-24 00_26: EngineState: IRQ CPU utilization 25.431594848%

2018-12-24 00_27: EngineState: perSecondIrqDuration=42571610 ticks / perSecondIrqCounter=25247
2018-12-24 00_27: EngineState: IRQ CPU utilization 25.340244293%
At this point i have no clue where are 25000 IRQ every second are coming from, I am only aware of 10000 ADC IRQ. That's a question for another day.

For CPU consumption the values above are for the default "debug" version of the firmware. Here is anicer value for "release" version compiled without internal state validation and without debug info:

Code: Select all

2018-12-24 00_39: EngineState: perSecondIrqDuration=14778874 ticks / perSecondIrqCounter=24172
2018-12-24 00_39: EngineState: IRQ CPU utilization 8.796949386%

Re: Firmware developent status

Posted: Mon Dec 24, 2018 6:03 am
by AndreyB
And now with #define EFI_INTERNAL_ADC FALSE This was supposed to reduce the number of IRQ by 10000 per second but it has reduced it by 20000 a second. I wonder if our fast ADC was in fact running at 20KHz pretty much since forever?

Code: Select all

2018-12-24 00_55: EngineState: perSecondIrqDuration=7315971 ticks / perSecondIrqCounter=4114
2018-12-24 00_55: EngineState: IRQ CPU utilization 4.354744911%

Re: Firmware developent status

Posted: Mon Dec 24, 2018 9:51 am
by kb1gtt
Don't forget ChibiOS software IRQ's. You may have one IRQ for the ADC, and another for the software. As well the software ticks may account for the other 5000 IRQ's. I recall ChibiStudio has an add-on which allows you to pause the code and inspect the CPU cycles consumed by different threads. I think that also indicated the number of IRQ event's as well. It might be worth while to compile this with ChibiStudio just to be able to look at those diagnostics information. That information is already some how embedded in ChibiOS. I suspect it's simply a register some where.

Re: Firmware developent status

Posted: Mon Dec 24, 2018 10:38 pm
by AndreyB
Still debug, witout ADC, with kernel ticks not calculated

Code: Select all

2018-12-24 16_31: EngineState: perSecondIrqDuration=10680357 ticks / perSecondIrqCounter=3271
2018-12-24 16_31: EngineState: IRQ CPU utilization 6.357355594%
(another run)
2018-12-24 16_43: EngineState: perSecondIrqDuration=10232801 ticks / perSecondIrqCounter=3194
2018-12-24 16_43: EngineState: IRQ CPU utilization 6.090952873%
2018-12-24 16_43: EngineState: efiVector6C 23643
2018-12-24 16_43: EngineState: efiVector108 110504
2018-12-24 16_43: EngineState: efiVector148 2
without efiVector108 which is TIM5 which is rusEfi scheduler
2018-12-24 16_55: EngineState: perSecondIrqDuration=1942961 ticks / perSecondIrqCounter=1591
2018-12-24 16_55: EngineState: IRQ CPU utilization 1.156524419%
Next leader is efiVector6C which is STM32_DMA1_CH0_HANDLER - looks like SPI DMI
2018-12-24 17_00: EngineState: perSecondIrqDuration=1278520 ticks / perSecondIrqCounter=1113
2018-12-24 17_00: EngineState: IRQ CPU utilization 0.761023819%

Re: Firmware developent status

Posted: Wed Dec 26, 2018 6:35 pm
by mobyfab
I'm having trouble understanding why you need to sample map/maf/knock at 10KHz continuously, using a timer.

You only need to sample these once per cylinder rotation.
HIP outputs an integral... just sample it once when you are done integrating for each cylinder. (hold mode, pin low level)
MAP/MAF can use sampling windows just like knock, and it's only needed for engines with ITBs (for MAP) or violent cam timings (crossover) that blow air back into the manifold. 1Khz continuous sampling + median filtering would be plenty otherwise.
You can also increase the sample amount to reduce IRQ frequency since you're gonna filter/average it anyway.

If it's really continuous you don't even need to use a timer and can just let it run in circular mode.
If you use sampling windows you would trigger this via a timer or software.

Re: Firmware developent status

Posted: Thu Dec 27, 2018 10:56 am
by kb1gtt
I would expect one sample per rotation to be prone to noise issues. As you mentioned the sample window is a more robust solution. AKA we do not care about the accuracy of the signal, we care about the repeat-ability of the signal. There are crank angles which are mechanically more repeatable. Taking like 5 MAP samples in this crank window, then integrating them together, makes for a more repeat-able MAP signal. As well I understand that sampling for each cyl is beneficial. While one rotation sampling is a good start, you can get significant angular variations per rotation. Especially on low inertia high HP engines. However on heavier OEM lower HP engines, you don't need to be so picky about your MAP. I understand that window sampling at a specific crank angle, per cyl, is one of the better MAP solutions. I also understand that this window may vary slightly as RPM's change. AKA sample window often wants a look up table for when the window starts and stops.

I suspect the MAP was done the way it was done, as it was easy to let ChibiOS deal with the hardware, and it worked good enough for it's primary applications. I understand many OEM's do it this way. Perhaps now that it's been running, this can be an area for improvements, especially for non OEM engines, or heavily modified engines.

Re: Firmware developent status

Posted: Fri Dec 28, 2018 12:47 am
by AndreyB
https://github.com/rusefi/rusefi/blob/master/misc/benchmark.bat tells us that Dell OptiPlex 790 desktop ~2011 "Ohio reformatory for women" takes 90 seconds to compile rusEfi while 2011 laptop not from a reformatory needs 180 seconds. See https://github.com/rusefi/rusefi/blob/master/misc/benchmark_reports.txt for more details. Maybe it's time to start using 2015+ hardware?

What about your device?

Re: Firmware developent status

Posted: Fri Dec 28, 2018 1:06 am
by mobyfab
GCC 7.3
14s with -O0 (default)
13s with -Os
10s with -Os and LTO

GCC 8.2
19s with -O0 (default)
18s with -Os
41s with -Os and LTO

Ryzen 1700@3.8Ghz on an SSD, running Linux

Re: Firmware developent status

Posted: Fri Dec 28, 2018 1:20 am
by AndreyB
mobyfab wrote:
Fri Dec 28, 2018 1:06 am
GCC 7.3
14s with -O0 (default)
13s with -Os
10s with -Os and LTO

GCC 8.2
19s with -O0 (default)
18s with -Os
41s with -Os and LTO

Ryzen 1700@3.8Ghz on an SSD, running Linux
WOW! That's a $190 8 core CPU from 2017?

LTO makes 7.3 FASTER while 8.2 is WAY slower with LTO?

Re: Firmware developent status

Posted: Fri Dec 28, 2018 1:27 am
by mobyfab
330€ back at launch :cry:

LTO has changed a lot in 8.x, they fixed many bugs.
In general GCC 8 makes more checks (and is more picky) but produces better code.

No LTO
text data bss dec hex filename
285012 5196 184704 474912 73f20 build/rusefi.elf

LTO
text data bss dec hex filename
266080 4212 185496 455788 6f46c build/rusefi.elf

Re: Firmware developent status

Posted: Fri Jan 04, 2019 1:18 am
by AndreyB
Unit tests now use fancy https://github.com/google/googletest/ - see https://github.com/rusefi/rusefi/commit/2b8f586276e395cd50ed762bb22ef6d00ceb15ff

Next step to try googlemock as well.

Code: Select all

[       OK ] pidAutoTune.delayLine (2 ms)
[----------] 2 tests from pidAutoTune (208 ms total)

[----------] 1 test from testCJ125
[ RUN      ] testCJ125.todo
[       OK ] testCJ125.todo (0 ms)
[----------] 1 test from testCJ125 (0 ms total)

[----------] Global test environment tear-down
[==========] 3 tests from 2 test cases ran. (210 ms total)
[  PASSED  ] 3 tests.

Re: Firmware developent status

Posted: Tue Jan 08, 2019 6:21 am
by AndreyB
I believe that better automated testing is really needed, we now have first unit test wit mocking.

https://github.com/rusefi/rusefi/commit/60e747481f39da3978c7e9531bdac5db234c4e7c

Re: Firmware developent status

Posted: Sat Jan 12, 2019 9:21 am
by AndreyB
rusEfi console update - frame title bugfix and "preset" pane, most popular engine configurations could now be selected without typing magic commands.

Re: Firmware developent status

Posted: Sat Jan 12, 2019 11:04 am
by kb1gtt
Hmmm, is this setting something that can be either set or checked via the LCD screen?

Re: Firmware developent status

Posted: Sat Feb 09, 2019 9:38 pm
by AndreyB
There will be an invalid configuration soon in light of https://github.com/rusefi/rusefi/issues/688

https://rusefi.com/forum/viewtopic.php?f=5&t=1509 created for such occasions

Re: Firmware developent status

Posted: Sun Feb 17, 2019 7:37 pm
by AndreyB

Re: Firmware developent status

Posted: Wed Mar 13, 2019 12:12 am
by AndreyB
I still like the idea of moving documentation to github. I also still like the https://rusefi.com/s/ approach to short rusEfi URLs like https://rusefi.com/s/howtocontribute

Re: Firmware developent status

Posted: Mon Apr 01, 2019 9:27 pm
by AndreyB
rusEfi is a stinky legacy code base but made some progress under https://github.com/rusefi/rusefi/issues/725 today - the whole console vs TS, text vs binary is a bit less confusing in the code now. Still a mess but a much smaller mess.

firmware folder structure could use some help as well, some minor progress made yesterday under https://github.com/rusefi/rusefi/issues/723 but open question at the moment is what is a nice folder structure :) So far I've at least created https://github.com/rusefi/rusefi/tree/master/firmware/util/containers and https://github.com/rusefi/rusefi/tree/master/firmware/util/math and moved few files there. Oh, and UpperCase file naming is no longer used in firmware folder.

Re: Firmware developent status

Posted: Mon Apr 08, 2019 3:58 pm
by AndreyB

Re: Firmware developent status

Posted: Tue Apr 09, 2019 9:20 pm
by mck1117
russian wrote:
Mon Apr 01, 2019 9:27 pm
rusEfi is a stinky legacy code base but made some progress under https://github.com/rusefi/rusefi/issues/725 today - the whole console vs TS, text vs binary is a bit less confusing in the code now. Still a mess but a much smaller mess.
It would be quite a bit easier to read if each "bundle" of changes to implement a feature like this was executed on its own feature branch, then merged with a pull request and squash merge in to master. Even if you're the only one who contributed, submitted the PR, and approved it, it still helps bundle together commits like these to prevent polluting master with a long sequence of identical commit messages.

It also lets you commit experimental things, todos, etc. and remove/clean up before merging it in to master, in case there was a broken intermediate step during development in there somewhere.

Re: Firmware developent status

Posted: Tue Apr 09, 2019 10:11 pm
by AndreyB
mck1117 wrote:
Tue Apr 09, 2019 9:20 pm
It would be quite a bit easier to read if each "bundle" of changes to implement a feature like this was executed on its own feature branch
Absolutely, those are all the pros of such an approach. I assume we are both aware of few cons of that approach as well, so I have to balance.

Re: Firmware developent status

Posted: Wed Apr 10, 2019 2:16 am
by AndreyB
Minor but annoying https://github.com/rusefi/rusefi/issues/736 bug fixed.

Re: Firmware developent status

Posted: Fri May 31, 2019 1:28 am
by AndreyB
russian wrote:
Thu Feb 16, 2017 4:48 am
russian wrote:$71 dell optiplex quad-core i5 desktop plus a smaller SSD drive i have in my random parts bin.
Ship date: July 01, 2011 end of warranty July 02, 2015 so https://en.wikipedia.org/wiki/Ohio_Reformatory_for_Women has no use for this one.

I am reusing state prison junk, what am I doing with my life.
Got amber light of power supply death :( There would be no builds for some time.

On the bright side there is some cool progress under https://github.com/rusefi/rusefi/issues/808 - we now have rusefi_frankenso.ini and rusefi_microrusefi.ini files which would hopefully improve usability for end users

Re: Firmware developent status

Posted: Fri May 31, 2019 12:03 pm
by AndreyB
russian wrote:
Fri May 31, 2019 1:28 am
Got amber light of power supply death :( There would be no builds for some time.
Update: diagnostics LED 1 and 2 indicate system board failure, not power supply failure :(

Re: Firmware developent status

Posted: Sat Jun 01, 2019 4:28 am
by AndreyB
russian wrote:
Fri May 31, 2019 1:28 am
There would be no builds for some time.
Jenkins already installed on new build server and I was able to recover jobs settings from old HDD, just need to figure hour nasty Mailer configuration issue hopefully tomorrow.

The state of rusEfi is great by the way. We have some intense discussions in Slack https://rusefi.com/forum/viewtopic.php?f=13&t=1198 and that means progress :)

Re: Firmware developent status

Posted: Sat Jun 01, 2019 8:33 pm
by AndreyB