pcmhacking.net

Now that I’ve gotten a prototype read kernel working for the E92 ECU I think it would be nice to update PCM Hammer to support CAN BUS communication. That would open up the door for many other ECU’s.

I know this will be a lot of work, and I likely will not be able to do it without support, but I truly do think it makes sense in the long term.

I think I’m going to try to do a lot of reading of the current PCM Hammer code to try to better understand the architecture and flow. I’ll also be taking some courses on C# as I don’t have a great grasp of that vs standard C. I know there is a big push right now to update the kernel(s) for the current VPW based ECU’s and that this effort will likely start after the next release of PCM Hammer, but I wanted to start getting ideas down and let others know that this is an effort that the community could use some support if you are interested and willing to contribute.

If you have ideas please share them.

Can't help, but I want to say thank you.

I'm not smart enough to help with the code, but I do have 2 E40 CAN BUS vehicles that I can do test reading on when you get to that point.

I'm willing to help where I can. If we are able to use the j-2534 sharp dll(not sure on the copyright for that) then I'll be able to contribute more as I'm familiar with that.

bubba2533 wrote:Now that I’ve gotten a prototype read kernel working for the E92 ECU ...

You absolute legend.

There's work underway now (or, last time I checked in, which was an embarrassingly long time ago) to support more VPW-based ECUs, and it would be good to wrap that up before tackling a CAN ECU, but it's not out of the question.

In the meantime, maybe just fork the project and make it work with CAN and E92s, and we'll figure out how to integrate your changes with the main branch later. You'll want to change the way the OBD2 interface gets initialized, so that it uses CAN rather than VPW, and you'll want to change the Protocol class to generate and parse the CAN equivalents of the VPW messages.

A hint for anyone coming to C# from C or C++: Most variables are actually pointers and most . operators are actually -> operators.

We are quite close on the next update. The ASM kernel is working on most targets we want, we are just stuck on getting the DLC code stable on the P04 variation. Once thats done, and we have done some testing, we'll be ready to move on. As that work is 100% in the kernel, it would be possible to branch now to start refactoring comms to code too add hooks for CAN without breaking VPW. The VPW code and message classes were written with future expansion in mind but I am not sure if it'd be enough. There is the assumption that device IDs are 1 byte which wouldn't suit can, and there are probably some other loose ends too.

@NSFW if you would be willing to help us achieve this I think your skill set when it comes to design of the classes would be very welcome.

I'll just leave this here...
There is a lot more work to be done and lots of hacks were done to make this happen.

Very nice! Happy to provide feedback if you want to share a public or private (while in experimental form) branch.

I am planning to overhaul some of the way the data is stored and provided for PCM types, so it'd be good to take this in to account, and even start on that side of it to strengthen can bus support.

bubba2533 wrote:I'll just leave this here...

There is a lot more work to be done and lots of hacks were done to make this happen.

Nice work!!

What was the packet size used for reading? Looks like it took about 4minutes to complete.

antus wrote:Very nice! Happy to provide feedback if you want to share a public or private (while in experimental form) branch.

I am planning to overhaul some of the way the data is stored and provided for PCM types, so it'd be good to take this in to account, and even start on that side of it to strengthen can bus support.

Ok, I'll try to clean it up a little more then I'll push my branch.

Tazzi wrote: Nice work!!

What was the packet size used for reading? Looks like it took about 4minutes to complete.

Thanks!

The packet was 2,060 (0x80C) which I noticed, but I didn't dig into it.

It looks like that's because of line 64 & 65 from "PcmHacks\Apps\PcmLibraryWindowsForms\Devices\J2534Device.cs"
I updated that to 4095 (0xFFF) and got this updated result. I could probably increase that in the kernel if the tool could handle larger packets.
Also, I just realized I left the ECU powered on all night and the kernel was still running...so I guess that's good.