pcmhacking.net

Thats a good start. I'd be tempted to swap the first and second row buttons, so you have "get pcm info" as the first button, and "read pcm" as the next on the top row. Next file would then be settings and write pcm (so that read and write are next to each other, on the right hand side of the screen.

For the write page, there is some more to think about now we support more PCM targets. Not all PCMs support calibration only, or param blocks, or dont use param blocks. At the moment the pcmhammer 2 code records this in PCMInfo against the PCM types, and throws an error if you do a calibration write / param block write and tells you that you have to do clone, if that is the only option for a certain PCM. It works, but its not a great user experience.

One idea is to have a 'connect / disconnect' button that identifies the PCM, and then greys out incompatible options.

The other thing I have been thinking about is a way that user can pick the PCM type from a list. It could default to Auto which could use the OSID query and lookup as we do now, but if you pick a certain PCM type from the list, then it skips the OSID check, and internally makes a pcm object of a certain type. Just need to think about what it uses as an OSID placeholder, or if we allow it to be null and make sure nothing will crash when that is the case.

For CAN, yes the block transfers/protocol is different. I think that is a different problem to the device drivers though and can be solved at a different time. If we were to implement CAN flashing, then we'd probably use a completely different read or write function, and a later style protocol which is closer to a streaming transfer with many packets than 1:1 request/response. In my head I am loosely thinking one day we might want an internal PCMHammer API with logical functions such as identify, unlock, read, write etc and those functions can look at the protocol and call the same or different function to do control depending on what its talking to and that protocol specific function would limit the size of writes to what the protocol supports. The TX and RX can still be handled in the device drivers and will never be asked to send an invalid packet. Its only a rough thought though for much later development if we ever go that far.

I have a P05 on the way (my 3rd one after I bricked the first with bad software, and the second was DOA) and once that works CAN bus might be on the cards.

BTW I just merged the latest changes and your logger zoom changes, I think we are in a good place for a PCMHammer 2.0 release, last release for older windows maybe...? This would get assembly kernels, various fixes, P04 early and late types, P08, 98+ 4 connector Black Box and E54 read and write out to the public and P05 and/or UI improvements can be considered for the next release?

Yeah, let's do a release with the code we have now.
There's no way to predict how long it will take to get the new UI ready.

For button order... my thinking was that settings should be first because users will need to configure that stuff before they do anything else, but it just hit me that the first time the user runs the app, we should just take the user directly to the settings page. Or better yet, take them to a wizard sort of ui where the first question is 'what kind of OBD2 interface do you have?" where the answers are OBDX, ObdLink, AllPro, AVT, VCX Nano, Other J2534 device... and only ask for COM port if they picked a serial device. Then ask if they have the Seeed Canbus interface, and if so ask which port to use for that. And then put the settings button at the bottom, because most users will rarely need it after the initial setup.

And we need a place to put VIN-change, Crank Relearn (discussed a while back, not implemented), Read Codes, Clear codes, etc...

And wanted to put read and write side-by-side, but that didn't work out well with the settings button on the first row, but if we move Settings to the bottom, then we could do:

Row 1: Read, Write
Row 2: Special Functions, Data Logging
Row 3: Settings, Help

I want to have the app poll the OS ID and voltage a few times per second when the user is on the main screen, so the top right corner can indicate whether we have a connection to the PCM. (Also, turn the voltage box red if it's below some threshold.) That initial polling would also pave the way toward showing the appropriate set of flash options on the write page, or a "choose your PCM type" step if the OS isn't recognized.

If the user clicks Special Functions we could read and display the properties on the next page, and below that have buttons for Read Codes, Clear Codes, VIN Change, Crank Relearn.

Yeah ok, polling and displaying OSID and PCM Type as soon as we get a response is nice. We'll need to review the timeout and retry code. I think some interfaces will take possibly up to 2 seconds to respond if there is no reply. This could even be a reason to implement a communications state machine, where transmit sets a state and receive occurs independently discarding unexpected data and waiting for the correct response. This wont work well for elm/scantool/allpro and might mean they have to be dropped. But it will work well for J2534/Xpro/AVT and mean in car read and write would be much more reliable on a much wider range of vehicles.

Special function - "Set PCM type" where user swaps it from Auto and sets a particular type could stop it polling OSID (or stop it useing OSID to update the PCM Type).

I like the idea of having get properties as a button on the main screen, but if we get and display at least OSID and VIN, then move Serial Number, MEC, Calibration IDs under special functions, that would work, as most people don't need to know those things most of the time.

Couple think rolling off my head, although I am bias since its just how I do my own stuff.

1) The average joe doesn't understand if they need to do a full OS write, calibration only or anything in-between.
Having the application automatically just update what it needs to is the easiest solution. From what I have seen over the years, most people are grabbing random bins off the web and just writing them to their ECU, they do not understand about misconfigurations between OS/Cals/Param section.

2) Most people don't understand what the procedure is for doing anything.
A single button to connect to scantool and auto detect ECU is ideal. If the ECU cannot be detected, a popup with a dropdown of supported ECUs could be displayed.

3) As for CANBus implementation, ignoring the requirement of rewriting the scantool classes to be ready for CAN, I believe the bigger concern is setting up the ECU classes so they all support a template implementation (As Antus suggested).
At a minimum, the template should have Security algorithm, read PCM details, Read Flash, Write Flash ect.

This allows a bit more versatility in the event certain ECUs do not support requesting certain options and allows splitting the routines since they do differ once moving towards ECU that already have internal kernels that handle both read/write.
This also helps when moving towards adding features like Crank Relearn, clutch pedal learn ect where the required command changes between years.

I have it basically working with the Uno Platform UI now. It still has a lot of rough edges, and nothing about the UI is pretty, but it's able to select an interface, read, write, get properties... and I hope to get crank relearn working this weekend. Data logging is going to take a lot of work though, so it's going to be slow going from here.

The screenshots below show fake data, but only because I'm too lazy to go upstairs and connect to a real PCM.
And I just noticed that it's showing RPM in degrees celsius...

I still have a lot of work to do, but the UI rewrite is almost usable now. Windows only - I haven't even looked at any other platforms yet.

If you want to try it, you'll need to use this tool to install the dependencies, and be prepared to wait a while, as it takes forever to download SDKs for iOS and Android: https://platform.uno/docs/articles/exte ... bs=windows

Then switch to the nsfw/net8-uno-ui branch, build the solution, and set the PcmHacking.UnoUI project as the startup project.

Can I get an approval for this pull request?
https://github.com/PcmHammer/PcmHammer/pull/8
It's pretty small, it just moves the VIN validation code into PcmLibrary so that I can call into it from the new UI.

Thanks!

BTW, I used the Uno UI to flash my car about a dozen times over the last couple weekends, and to do a bit of data logging, and it's pretty solid.

I'll post a test build after I finish the VIN-change logic and give the data logger some UI to add and remove parameters. It's getting close. The only drawback is that it takes a while for the app to load.

Looks good, merged

Thanks!