RomRaider

FastECU is the only open source GUI flashing tool that I am aware of. The author (MiikaS) has paused development for the time being. However, some other folks are keen to step in to keep FastECU moving forward.

The purpose of this thread is to provide a common location for the folks working on FastECU enhancements to communicate and collaborate. Of course, anyone with an interest can also contribute.

Current ‘work underway’ includes:
- make the Hitachi (and other) processors (work mainly done by SergArb) as new modules so they can be selected like all the other modules
- attempts underway for a client / server version. Not sure of status and how much rewriting of core code might be required? If rewriting is required, is this something we do first before any other enhancements?

Also need to figure out most efficient ways to make changes within GitHub repo/branch system. Open to ideas?

Hello.

I'm not very familiar with GitHub. So, I will continue contribute by sending my corrected module files to rimwall.
Then team can add or make the changes/updates in a Git.

Most of Hitachi ECU's now is tested. I'm bricked few ECU's while testing. But still a lot of work with old Hitachi ECU's.
Because we didn't know how to unbrick them without expensive tools. And I don't have a dozen tones of this ECU's.
I have to buy them again and again, waiting for delivery and so on.

Hi!



I think that in current situation we should choose what repository will be the main. It means that everyone who wants to contribute should contribute to that repo. One of the options is to keep https://github.com/miikasyvanen/fastecu-oem as main repo. Although Miika has paused the development, with collaborator access to the repo it's possible to do most of things, including approving pull requests and many more.

The other option is to use some other repo as main. In this case it would be harder to keep all forks consistent, especially upstream.

Anyway, all forks should be 'synced' before development starts - I saw some forks are behind and ahead of Miika's repo.

Next forks and branch usage rules should be introduced. Usually simple rules are enough:

• Development branch in main repo created
• All developers creates separate branch for each feature (for example, named 'develop/feature-cvt-support'), issue (develop/fix-123), refactor etc. No changes in fork's 'main' branch should be done.
• A branch should have human readable name
• Developer make pull request (PR) to main repo when the work on feature/issue/etc is done.
• One feature/issue/fix/etc at a time. If PR consists of several loosely coupled changes, if should consists of several commits (one for each change), but as less as possible.
• All unfinished work should not go to the main repo. It should stay in developer's local repo. Any branch from main repo should build.

Repo owner or person with collaborator access then checks PR, approves it, merges with develop or main branch or any other if needed.



I have wrote proof of concept that works over secure WebSocket broker and also it works over local named pipes\sockets. To implement it, refactoring is required.

A couple words of what I propose.

A client is a small app that gives access to read/write equipment only, no or minimum user interaction. FascECU starts in server mode. It is hidden a little bit and is activated though CLI parameter. They both connects to broker that runs on public IP. Then FastECU works as if connection to device was direct.

What changes I propose.

All work with ECU is done via SerialPortActions class. I propose to make a wrapper class, that hides direct work with SerialPortActions class. That wrapper class will use getters/setters/member calls only, without direct access to class fields. This would hide implementation and will allow to make changes (including change of network transport) with minimum impact to other components.

That wrapper detects mode in which FastECU was started and calls local SerialPortActions instance or remote.

For remote connection Qt Remote Objects framework is used. It allows to call remote class instance as if it were local. Qt Remote Objects could work over network and over local sockets/named pipes, which makes possible to migrate FastECU to 64-bit leaving small part responsible for OpenPort support 32-bit.

I think wrapper class should be implemented first but without remote support. It's because it will affect most part of software. And then all client/server development will be isolated.

To avoid merge conflict all developers' repos should be synced before these changes.

Also I am opened for other ideas and proposals.

It's easy enough. There's excellent graphic tool called Github Desktop. All you have to do is to fork a repo, create a branch for development (usually it's called 'develop'). Than you work as usual and when the work is done, you commit your changes and then pushes your changes to your fork. And then you could create pull request (also called PR) to include you changes in upstream. It's all intuitive enough. Please don't hesitate to ask me. I'm certainly not an expert, but I'll do my best.

Hi all!

As rimwall said, for some time I have had very limited time for development things and I can't say for sure does it take few months or a year to get back to normal state...

I'm still here if anyone have any questions about software or anything else. And if there is people who are willing to participate this, I can give collaborator access to the repo. First things maybe could be merging rimwalls changes to repo in the right way so there is solid base to start making changes. There is many new TCU and ECU modules/protocols to add and they should be sorted out. Also it would be nice to have other opinions also if there is other things that should be done other/better way, cause I think there is. And many

Which Hitachi ECUs still need work? I have a collection of old Subaru ECUs and have a few Hitachi's that should be reflash-able (MY98+):

UJ WA12212930WWW (M32151F8T) 98-02 USDM Impreza 2.5RS
UJ WA12212970WWW (M32176F4) 03-04 USDM Impreza 2.5RS

Hi, great to see we've got the ball rolling!

On the GitHub side of things I am happy for MiikaS to give me collaborator access to his FastECU repo. As an aside, I am certain alesv's coding abilities far exceed mine, so I'm also more than happy for alesv to have the collaborator access instead of me!

In terms of Hitachi processors, we should already have UJ30 and UJ70 covered, but I'm not entirely sure. SergArb has been coding various access methods by writing different versions of the existing modules. I've gone through the various files SergArb has sent me over the last few months in multiple emails and attached them here. It's rather confusing digging back through the emails where we were figuring out the access methods. Could SergArb please check that I have the correct details and files and update any missing info. Am I missing any files? Also, for each file, what settings were used for the flash blocks?

Once we are clear on these details, I can do the coding to make these separate modules (instead of various versions of the same module).

Thanks!

All old Hitachi K-Line WA12212920-70WWW with AF security access method. Need to find a non expensive way for unbricking.

Mitsubishi MH8104:


Mitsubishi MH8111:


Hitachi SH7058:


Mitsubishi M32R:


Hitachi SH72543R:


Hitachi UJ70 512kB:


I didn't done AF access methods for old Hitachi.

Super, thanks SergArb. I’ve got a lot of catching up to do!

Kline UJ20/30/40/70 - note that this access method is known, just not coded & tested. MiikaS started, but maybe didn’t finish…?

Hi MiikaS, alesv has kindly offered to help with the repo, so can you add both alesv and me as collaborators? Thanks.

Anyone else who wants to help - feel free to jump in on this thread…

Yes, also need to code encryption method and last block write command.

Hold your horses, guys. We have a problem. rimwall's and miikas's repos have gone too far apart. MiikaS added many changes at the same time as rimwall did. We need to sync them before we could commit to upstream.

What we need to do:

1. Sync rimwall's development branch with MiikaS's development branch.
2. Test this branch. We should ensure that it works as expected.
3. Merge synced branch into development branch.
4. Then you could resume work and I will push rimwall's changes to upstream.

I created synced repo and I did initial checks. It compiles, starts and finds OpenPort. Now I need to push changes to rimwall's repo. Rimwall, could you please create a new branch in your fork and call it somehow, for example 'development-sync'? I'll create PR to that branch and after you approve it, we could check if everything works as expected.

Also please create one more branch and call it like 'development-froze-before-sync'. We will leave it untouched to have point of return.

Ideally, every supported ECU should be tested. But I understand this is impossible. Please test as much as you can.

Thank you!

This changes at "serial_port_actions.cpp":

Broke new developed CAN modules. I had to remove it.

Got it. I'll try to track down all files added by MiikaS, adopt them to support old method and revert changes in SerialPortActions::read_j2534_data. I think I understand what's going on. Thank you for very detailed info!