rusefi.com

PS: this is related to Proteus 0.6 with specific F7 where we are still having issues with incremental firmware update

@andreika has implemented ISO 15765-2, or ISO-TP in both rusEFI firmware and rusEFI console. rusEFI console part uses ELM327.

I have a random ELM327 which uses https://github.com/rusefi/rusefi_external_utils/tree/master/ELM327 CH340T USB driver let me now try it

So far zero response from unreliable KKmoon ELM327 USB Auto Scanner
I have this kind of KKmoon ELM327 which is v1.5 probably not original ELM. Those require +12v to run according to @andreika got some response now need to fix some bugs in rusEFI code.

Another unreliable ELM327 comes in tomorrow

Lua can now read and write both CAN buses on _all_ designs with two CAN buses.

@dron_gus has added stm32f429-disco compilation target which would be first usage of external SDRAM by rusEFI. 8MB on this specific board, could go a bit higher if needed.

No specific plan to use that RAM as of today but very shiny and very cool.

Just bumped ChibiOS to version 20.3.4 / RT 6.1.4 for no good reason, just prefer to keep up with ChibiOS major releases.

Next frontier https://github.com/rusefi/rusefi/issues/3794 again no specific reason for priority.

Am I the only one that keep gettign these kind of errors every time I update firmware?
Problem:
Can't set "Number of lobes (lobes/cam)" to zero. This keeps the HPFP feature enabled, and I get the same error regardless of what I do to the table. Load an old .MSQ from a previous firmware version where "Number of lobes (lobes/cam)"=0 disables the HPFP and fixes the problem.

tmbryhn wrote: ↑

Fri Jan 21, 2022 2:25 pm

Am I the only one that keep gettign these kind of errors every time I update firmware?

That's a vague question. Are you getting same message always about HPFP? I doubt that.

Firmware update often comes with new mandatory settings.

"Problem:
Can't set "Number of lobes (lobes/cam)" to zero. This keeps the HPFP feature enabled, and I get the same error regardless of what I do to the table. Load an old .MSQ from a previous firmware version where "Number of lobes (lobes/cam)"=0 disables the HPFP and fixes the problem."

Iow; I'm unable to disable HPFP feature by setting "Number of lobes (lobes/cam)" to zero unless I load an old .MSQ for a previous firmware version that already had this variable set to zero.

Please post a link to your tune on https://rusefi.com/online

tmbryhn wrote: ↑

Fri Jan 21, 2022 2:25 pm

Can't set "Number of lobes (lobes/cam)" to zero.

Why? what prevents you from setting number of lobes to zero? Please provide more details screen shots error messages etc.

Thank you! I've just pushed the change we shall have new snapshot in about 20 minutes

I think https://github.com/rusefi/rusefi/issues/3806 is a show stopper - anything after Jan 18ish might have performance degradation in it, technically that includes latest release.

Oh we should have implemented this usability change a while back. Well, progress!

Does not work for analog inputs but at least works for something

Matt has made https://github.com/rusefi/rusefi/issues/3912 console connectivity bugfix


Very upsetting to be wasting time on https://github.com/rusefi/rusefi/issues/3923 BS Ordered a new to me used laptop as replacement primary device

Mitsubishi update: two crank and one cam trigger wheels

_someone_ should check that I got the rotation direction right, also VVT wheel was a bit ball parked would need real vehicle validation.

https://github.com/rusefi/rusefi/wiki/All-Supported-Triggers#mitsubishi

Status update: I have no idea what to work on, too many random desires without any way to sort those by priority. So I keep playing with my test mules.

There a few things that i think can add to the overall rusefi experience , the engine protection side of things that ties in with the sensors fuel and oil pressure and the launch control/ flat foot shifting, if you can grab it from the speeduino code it would make your product nearly complete

007adr wrote: ↑

Wed Aug 03, 2022 2:09 am

if you can grab it from the speeduino code it would make your product nearly complete

rusEFI and speeduino are completely unrelated codebases so we cannot simply grab code. For new functionality to be added into rusEFI please articulate a feature request with much, much more detail.

Sorry buddy, ill post it in the feature request section, or do i do it here sorry for the confusion

Problem or not with instant RPM?

https://rusefi.com/online/view.php?log=961
compare to https://rusefi.com/online/view.php?log=955
Do we see a bug? Do we see an opportunity for any engine metric? Do we see totally expected behaviour?

@mck1117 i believe that we are not in a good place with newparse. Two months ago we've made the first step towards using it for real https://github.com/rusefi/rusefi/pull/4219 but no progress since, the current unfinished status creates more harm than good in my opinion.

Please find either a way forward or backwards under https://github.com/rusefi/rusefi/issues/4441 - one way or another we have to end up with a consistent clear implementation of this layer, not a combo of sad legacy and unfinished fancy.

Console usability progress https://github.com/rusefi/rusefi/issues/4625 hopefully works on all relevant version of Windows.

With the wmic win32_pnpentity magic I've discovered above startup frame can now be a bit smarter about firmware update.

https://github.com/rusefi/rusefi/issues/3985 progress - SD card has way more data points now, and I am not done yet!

They have gcc12-beta so we've at least migrated from gcc9 to gcc10.

AndreyB wrote: ↑

Wed Oct 19, 2022 1:16 pm

They have gcc12-beta so we've at least migrated from gcc9 to gcc10.

@nmschulte has just upgraded us to gcc 11.3 which is current release!

Sad story: rusEFI did not compile with 11.2

Once in a while we randomly get "Error: RDP level is set to 1, try using Read UnProtect (-rdu) command in order to remove the Read Out Protection."

Root cause unknown

Work-around:
in console\STM32_Programmer_CLI\bin folder of your bundle you have stm32-remove-read-out-protection.bat action to address that

Now failing to read a byte from k-line k-line is supposed to be just a case of uart but something is not going well.

https://github.com/rusefi/rusefi/blob/master/firmware/hw_layer/kline.cpp