Open source GM OBD2 flash tool using a ELM327 device

[pgbpro2.0@gmail.com]

I think you mean J2534 rather than J2537? The PDF you linked to is certainly all about J2534, and J2537 doesn't appear anywhere in it...

J2534 is what Tazzi and I are talking about. I think it has a lot of promise. At this point we're exploring a lot of options, and we'll see which one(s) work best.

Which hardware are you thinking of, specifically?

Sorry I meant J2534, edited. Hardware I was thinking the VXDiag VCM Nano

[Tazzi]

Sorry I meant J2534, edited. Hardware I was thinking the VXDiag VCM Nano

As Antus has shown. If its not genuine, its going to be shit.

But it seems to be the most professional yet affordable option currently.

[pgbpro2.0@gmail.com]

Hey Tazzi,

Working with GIT Branches isn't too bad.

It basically works like this
in your git directory you'll be on - by default - master
so instead of working on that do this

create a new branch
$ git branch tazziBranch

then checkout that branch
$ git checkout tazziBranch

Do whatever you're going to do, add the files
$ git add .
do a commit
$ git commit -m "tazzi commit where I did great stuff and will tell you all about it here"

Then push to your branch
$ git push --set-upstream origin tazziBranch

Now the trick is you other people are going to be making changes to their personal branches or maybe to master and you want to merge in those changes to your branch. The way to do that is
$ git fetch --all
$ git checkout tazziBranch
$ git merge pgbpro20Branch

You'll have problems along the way! But with GIT there is a full history of everything going on so there really isn't any chance of you screwing anything up - you just might get stuck for a few minutes.

[jay woo]

This website was mentioned as an ok way to learn about git. https://learngitbranching.js.org

[antus]

I like the git theory. It'll be important with multiple people working on the codebase. Gitflow is a good reference but probably overkill here. What nsfw suggests is a good balance.

[NSFW]

create a new branch
$ git branch tazziBranch

then checkout that branch
$ git checkout tazziBranch

Do whatever you're going to do, add the files
$ git add .

This is the preferred approach, but it requires thinking ahead, which I'm not always good at. Most of my experience with git has been in solo projects where I was generally just committing to the main branch, but occasionally I'd do something like:

Do a bunch of work.
Decide to commit.
Realize that I should put this in a new branch. (Usually just because I wasn't sure about what I was doing...)
Realize I should have switched to a private branch before I started.
Google...
Read...
Aha!

git checkout -b NameOfNewBranch

That creates a new branch and moves your current changes to it, leaving the original branch untouched. It's handy if you realize you've been working in the wrong branch.

Then you continue as before with the same add / commit / push commands.

One catch with "git add ." is that it will add whatever it finds, so if you've got Foo.cs (which is part of the project) and Foo.cs.bak or Foo.HalfBakedIdeaThatIMightNotKeep.cs (not part of the project) then it will try to add those other two files to the git repository. Whereas "git add Foo.cs Bar.cs" will only add the files you specify.

"git status" will show files that you've created or modified and will indicate whether they've been added, so it's good to run that before "git add ." (and maybe after) to see exactly what's going on.

[Tazzi]

Im using the github gui... so this shall be amusing.

[antus]

Nothing wrong with that. We generally use a locally hosted gitlab at my work, some things are easier in the gui over the cli. But i still create branches from the cli. The visual studio 2017 integration with git is quite good.

[NSFW]

I'd like to propose that we use pull requests as well. After you create a branch, commit changes, and push those changes up to github, when you're ready for those changes to be integrated with the main branch, go here... https://github.com/LegacyNsfw/PcmHacks/branches ...and click the "new pull request" for your branch. That will give everyone a chance to comment on changes and suggest improvements before things get integrated with the main branch.

Also, if you're working on changes, please post to this thread to let the rest of us know what you're working on. If we're all working in different areas, this should all go pretty smoothly. If two or more people are working in the same areas, things could get awkward. As far as I know, this is what's in progress now:

MainForm.cs - I'm adding file-open and file-save dialog boxes for the read and write operations.

ScantoolDevice - I'm going to add support for the Scantool SX device, intially just trying to get VIN and OS queries to work.

Avt852Device.cs - Antus is adding code here to support the AVT 852.

MessageFactory.cs and MessageParser.cs - Antus is adding code to send and parse more kinds of messages. And probably fixing my existing stuff.

J2534Port.cs and... VcxNanoDevice.cs? - Tazzi is adding support for VCX Nano devices. (I'm just guessing at the name of the new file...)

Most of that stuff should be able to proceed in parallel without any trouble, however the stuff Tazzi is working on will likely spill over into other files, because the app only just barely had any foundation to build on for J2534 stuff. And at some point I'll probably want to rename the Port classes as described an earlier post in this thread. Those changes might be kind of disruptive so when they're ready I suspect we'll want to work together to make them go smoothly.

[160plus]

ScantoolDevice - I'm going to add support for the Scantool SX device, intially just trying to get VIN and OS queries to work.

I would recommend using the enhanced command set to prevent someone from trying to use a normal Elm cable that does not have the capabilities needed for any read/write.

Using the following command with the Sx - it will give you a 1975 byte buffer on the Tx and 1807 byte on the Rx side - this also removes the need to manually set or change headers with the normal ATSH commands.

STPX parameters:
H - header (hex)
D - data (hex)
L - data lengh (dec) [prompted for data]
T - timeout (dec)
R - number of expected responses (dec)
X - extra data (hex)

You can include the data in the example below:
STPX H:6C10F0, D:112233445566

Or you can specify the length and you will be prompted for the data with "DATA>":
STPX H:6C10F0, L:4
DATA>2800

You should specify what protocol you want to use rather then using the "Auto" setting, in auto mode it will often give you the message "searching". You have 2 choices to do this, you can use AT SP2 or STP12. If you choose to use the St command you also are able to use the Open & Close protocol commands as well then. To Open STPO and to close STPC

Virtually every AT command can be replaced with the same ST command. A couple of commands you may find useful for this would also be...

STPCB(0 or 1) - Turns On/Off automatic checksums
STE(0 or 1) - If you want read back the command sent before you receive your response data