Linux & Ecuflash

[Nuke]

Will there ever be a linux version of ecuflash?
I've just switched to Ubuntu from Windows and would like to just use Ubuntu to do all my flashing

[radsdau]

In the short term, can't you run a Windows VM under Linux? (this would be only one of a small number of reasons you'd ever want to do this)

[Nuke]

i wouldn't mind, just wondering if ecuflash will be straight on linux.

[salex]

Who is going to make the tactrix cable drivers under linux?
The biggest problem is the distributions which pop-up like mushrooms.

[Nuke]

I believe some of the guys at enginuity did something for the linux drivers

[Thrill]

The drivers are really not an issue. The drivers are already part of linux and bsd and the only thing missing is the product and vendor id's (so the kernel can use the appropriate driver on the cable). This is really easy to fix as I have done it for FreeBSD (currently it is on CURRENT but it should be in the next major release). I'm not shure for linux but I had copied from linux patches submitted by some guy on this forum so at least we know it works but it might not be in the main branch.

I understand not a lot of people care about portability but if the EcuFlash code was released, interested people could port it by themselves.

[gteclass]

I understand not a lot of people care about portability but if the EcuFlash code was released, interested people could port it by themselves.

Sorry, i have to disagree with you there.

Everyone, even if they dont realize it, is interested in portability. I bet everyone wishes they could have openecu drivers for their PDA. Imagine being able to log without waiting for the laptop to start or being able to flash and log without asking your passenger to sit in the back seat. I noticed that colby included Eclipse.org in his credits. That means at least part of the development was done using java. Java is basically platform independent, that is, universally portable.

I think the reason the source has not been released, and probably wont be public, is that people are evil and they will not just modify it, they will then distribute the modified versions. This leaves colby to blame for if their modifications cause havoc.

If we want to change the way ecuflash works, we will probably have to build it the way we want from the ground up. Which of course takes forever.

[radsdau]

I noticed that colby included Eclipse.org in his credits. That means at least part of the development was done using java.

Not necessarily. Eclipse can be used to develop in many languages.

[logic]

Not necessarily. Eclipse can be used to develop in many languages.

The latest changelog references Qt, which suggests C++ as the base language.

I'd like to echo Thrill's request for source availability: some of us are VERY interested in getting this working on Linux, and actually have the ability to do it. (I probably wouldn't have picked Qt, but that's neither here nor there. )

Plus, without the source, we're all screwed if Colby gets bored of working on EcuFlash some day (or gets hit by a bus, or gets hired by Ecutek, etc). It doesn't take long for software to bit-rot; after one or two OS releases, you'll be struggling to get it working, especially when special hardware is involved.

[jamest]

I have been logging for awhile now using my own python scripts as there was nothing out there really. I haven't even tried any reflashing code as of yet because I didn't want to "play" with my daily driver.

What's really neat is using Support Vector Machines to do a bit of machine learning on the log data. For example, being able to predict knock based on learned model of you car's engine cuts down the time it takes to tune a lot.

However, having the flash program on a different laptop has been a big PITA since I don't have access to it all the time. If anyone could get me docs on the flash procedure I could write something up fairly quickly.