Hammer not reading ECU

[Tazzi]

Why get into pcmhammer operating outta SAE but works. Just say yeah I’ll fix it….

Why mention it? Because its wrong.

As I am the one maintaining the OBDX J2534 compliancy, I have to note down every single change and why the change was done so that in the event it affects a main stream software, such as dealership software (Like Techline?).

I am all for helping support software developers, but blindly just putting in changes is how you cause bugs and problems with other programs.

I have tried both and using the serial i get the message " unable to connect to serial com 4"

That error is indicating that com4 is either not available, or is in use with another program.

[Sudsy]

I have tried both and using the serial i get the message " unable to connect to serial com 4"

That error is indicating that com4 is either not available, or is in use with another program.
[/quote]

When i go to device manager OBDX Pro is connected to com 4

[Tazzi]

When i go to device manager OBDX Pro is connected to com 4

Do you have any other programs open at the same time?
Are you also selecting the OBDX Pro as the device?

[Tazzi]

I'd be happy to fix anything to be within spec.

The library itself works fine, the issue is that the way the filter (pattern and mask) are applied is invalid as per the J2534 specification.

I don't expect anyone to be an expert on this matter, but I do know this pretty well

Yes it may be working for some J2534 tools, but its also incorrect which can result in unexpected behaviour or errors since VPW is expecting 3 byte long frames for the pattern and filter.
Switching to the J2534dotnet library could be done but that wont fix the above item.

I would apply a fix.. but all my changes get knocked back

[antus]

Yes there was a bit of that. Unfortunately we dont have ci configured with a linter and we have too many open branches and it gets complicated. I really want to see it fixed and am happy to accept help, but I would like to see sensible white space. That last one just needed white spaces fixed in 2 places. One was comma space instead of space comma, I cant remember the other but It was similar. 2 line breaks instead of 1 after a function I think it was? I cant edit your pull request and its more work for me to accept, branch, fix, commit, merge request again, 3rd party approval (has to be nsfw) then merge again. If you fix, commit, push then I apprive and its done. Much simpler. I would like to get a linter to apply some bigger cleanups. Then eventually get p04 and p08 merged. As it stands though my unrelated day job takes all the energy I have for this stuff and I only get satisfaction out of this. If you wana fix that white space its as good as in, and I'd love to make J2534 compliant too.

[Tazzi]

The white space/comma rejection was a bit of a cop out, the application is full of them which I pointed out.

I’ll wait for a linter to be applied then try again later.

[joukoy]

I converted Hammer to use J2534DotNet library and made pull request (at least I try, not sure how it goes).
Library required small modifications but mostly it is original.

Tested full read and full write with ONE P59.

[antus]

Thanks for that, I saw it come in. I tried to build it but it failed. Hopefully I'll have a chance to have another go over the weekend. Im am not sure how github ci works - if its just data in a yml or similar (like gitlab, which I use for work), or if you need a higher level of access in the project. If it is a yaml you have can edit in the commit, and you are able to get the branch passing the CI, that would be awesome. If not I might need to reach out with a few questions to figure out what it'll take to make it build to test it.

[joukoy]

Pull request closed and new created.
J2534DotNet library must be compiled before other parts, otherwise compile fails.

[antus]

Great, it looks like that fixed it. I just sneakily dropped in the asm kernels on top of your branch, removed the old j2534.dll, successfully compiled, and successfully read and wrote my P01 with my MDI over J2534.

Tazzi picked that line 87 of j2534.cs contained a multiplication of 50 for the size of the buffer, when the size allocated is 4128 and should be sufficient as is. So I removed the *50 and rebuilt and it still works. Do you know why that *50 is there?

If anyone else wants to look in the hammer repo at the merge request from Joukoy and follow it to develop on his repo and let us know if they can test with success or fail I reckon we can merge this.

Thanks, Joukoy! If you want to pull J2534.dll out the project, and remove that *50, I think we can merge after a bit more testing. If without those changes on your side I'll fix it up afterwards, and then think about what comes next.

Maybe asm kernels. Linter is on the back of my mind, but thats going to break other outstanding branches and merges pretty hard. I am thinking solarlint with the config mentioned here: https://dev.to/srmagura/c-linting-and-f ... n-2021-bna I gave it a test last year and it did what it said on the tin and had nice integration with VS, but I would like to get outstanding code in first, and that'll be a time sink of work and testing and cleaning up the rough edges.