Page 23 of 39

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Sun Mar 11, 2018 4:18 am
by NSFW
Thanks! That will help a lot.

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Sun Mar 11, 2018 10:26 am
by Tazzi
I do like that its showing updates for merge/changes. Helps keep ontop of whos done what and when.

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Sun Mar 11, 2018 10:49 am
by NSFW
I added File-Open and File-Save dialog boxes today, and along the way I made some small changes to methods in the Vehicle class so that they return Response objects.

The reason I want Vehicle methods to return Response objects (rather than an int for the seed value, a bool for unlock success, etc) is so that when things go wrong we can put the Response.Status value in the text boxes in the main window. That will help users see what went wrong, and it will help us figure out what's wrong when users report problems.

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Sun Mar 11, 2018 11:00 am
by antus
Sounds good :thumbup:

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Mon Mar 12, 2018 7:13 am
by NSFW
Just for future reference... This device runs open-source software and currently supports VPW at 10.4 kbps, with a 12-byte message length limit: https://www.macchina.cc/m2-introduction

Since it uses the Arduino programming tools and the Arduino Due CPU, support for large messages and 4x / 41.6k should be possible. It also has support for analog/digital/serial I/O though an expansion connector (for wideband O2 sensors, etc), and there's another expansion header for bluetooth, and there's an SD-card slot. Seems like it has a ton of potential.

After we get the app working with the interfaces we've been talking about so far, I want to take a shot at this thing. I've only got a little bit of Arduino experience, so I'm not likely to get too far on my own, but that thing is fascinating so I'm going to have to try. :)

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Mon Mar 12, 2018 7:50 am
by 160plus
NSFW wrote:Just for future reference... This device runs open-source software and currently supports VPW at 10.4 kbps, with a 12-byte message length limit: https://www.macchina.cc/m2-introduction

Since it uses the Arduino programming tools and the Arduino Due CPU, support for large messages and 4x / 41.6k should be possible. It also has support for analog/digital/serial I/O though an expansion connector (for wideband O2 sensors, etc), and there's another expansion header for bluetooth, and there's an SD-card slot. Seems like it has a ton of potential.

After we get the app working with the interfaces we've been talking about so far, I want to take a shot at this thing. I've only got a little bit of Arduino experience, so I'm not likely to get too far on my own, but that thing is fascinating so I'm going to have to try. :)
The Arduino Mega 4x mode is currently being worked on and is getting pretty close however because the macchina is built on the Due platform is makes the existing Arduino code Thaniel's has been working on incompatible. The Due use's a 32 bit arm processor and is significantly more advanced. I have looked into the Due a while back when we were running into memory issues since the Due has a great deal more to work with but there was very little in the existing code that would be reused.

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Mon Mar 12, 2018 10:12 am
by Tazzi
More than enough ram/speed in a due. Its more coming up with a suitable architecture to both negotiate bus activity and also commands from the software. Whether it be interrupt driven, timer or loop based. With the speed of obd2 protocols, theres almost no circumstance where a micro should be waiting more than 300microseconds before moving onto its next task like checking for commands from software or performing other tasks (periodic timers/frame searches ect).

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Mon Mar 12, 2018 10:58 am
by NSFW
The current Macchina VPW code looks like it does the send/receive operations synchronously. To send, the caller passes in an array of bytes, and the function doesn't return until after sending everything, using 'delayMicroseconds' to pause for each bit. An asynchronous approach would be more efficient but would require a good understanding of the Due's timing features. Which I certainly don't have. :)

https://github.com/redheadedrod/j1850/b ... 50-VPW.cpp

I'm going to get a couple of PCMs set up tonight for testing with the Scantool SX, Thaniel's Arduino Mega interface, and an Allpro with Antus' firmware. Those will keep me plenty busy, so it'll be a while before I get around to doing anything with a Macchina.

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Mon Mar 12, 2018 12:39 pm
by 160plus
After I had looked at the Macchina code again tonight I decided to go look at the Allpro code just for kicks. I was going though it and thinking a lot of it looked like Arduino code and libraries; I then noticed that the Allpro and the Macchina both use a Cortex Arm 3 processor....so that explains a lot. It's too bad that the code we are using for the Mega isn't directly compatible with that processor, if it was the firmware would be almost finished.

I'm thinking the work we've been doing with the Mega falls more in line with firmware development then program development. I guess it would take someone that knows both platforms to take a look and see how much of the Mega's code could could be directly ported to the Arm processor's architecture. We already have 4K blocks for transmit/receive and a partially working 4x mode after today. About the only thing it's still lacking still is checksum calculations for the big blocks.

Re: Open source GM OBD2 flash tool using a ELM327 device

Posted: Mon Mar 12, 2018 12:47 pm
by Tazzi
Because of how quick the VPW protocol is, focusing on sending/receiving each frame is more important than basically any other interrupt. Otherwise timing can be thrown out by a fraction which causes the entire vpw frame to be corrupted.
Especially at 4x, where short pulses can be down to as little as 6microseconds!

Definitely sounds like theres enough on the plate as is anyways!