PCM Hammer - The Uno UI, Improvements, and priorities

[crowbarmaster]

Confirmed - Android's back function is now handled by the application. This will give us a really good feature too - A back command at the home screen can bring up an exit dialog, giving us a good opportunity to shut down comms. The OBDX can be left in blocking states under BT, so that would be helpful. I also intend to get a handle to suspending and awake events to better handle this.

Next up will be registering a ForegroundService. I should be able to do something like a progress label too, since foreground services naturally come with a permanent notification. This would make it so even if the mind wanders and someone locks or opens Chrome, the operation should proceed safely. I have to wonder how the UI will respond to all of this however, TBD.

Screenshot 2026-04-12 102101.png

[antus]

Good stuff!

[crowbarmaster]

Tonight's update: We have a Foreground service!

Took a lot of tweaking to finally get things working properly with the notification and progress. I had to re-work progress handling to utilize the IProgress model, as it seems we have a loss of the logger when wrapping that task as a service. I wrote that originally for my demo and works very well. I should be able to use that for strings passed to the log too, why not?

We still have a few things to consider, but I'm over my time limit for today

Link to a build of these works here:

https://github.com/crowbarmaster/PcmHam ... 6400012371

Source for these changes proceed the PR, and can be found on this branch:

https://github.com/crowbarmaster/PcmHam ... ar/develop

Reading works completely as a priority task. I locked my phone to finish the better part of a read, and things worked perfectly. Sneak peak:

Screenshot_20260413-022052.png

P.S. I know I failed spelling here It'll be fixed in the next one!

Screenshot_20260413-022105.png

Screenshot_20260413-022143.png

More to come!

[antus]

Looks good. But, read isnt working here on the P11. Strangely it reads block 0A for the OSID but gets back FFs which is expected on the P11 then trys again on 0B which has the right OSID but it looks like the thread for the UI displays both and doesnt wait for the call to finish and the right ID to come back. Clicking read isnt giving the read dialog. The connected flag is swapping in and out of connected state. Galaxy S24 Ultra, latest patches. XPro GT on BT.

[crowbarmaster]

Interesting. What version of Android are you running Antus? I'm running the absolute latest (Beta opt-in) and there are a handful of ways I can see older software having issues.

I'd be curious to know if your results follow with a P01 read. It plainly just sounds like the service doesn't run on your end. I need to do something for better logging here, if only temporarily we need debugging output.

Sure we will figure that out! My other projects run services fine on 12.1 so it should be feasible.

Edit: A quick google search shows Android 16. Let me dig out my other devices and get something an API level lower. I recently moved to API 37 and I have to wonder if something changed there.

[antus]

Ill send you a pm vith version details. Yes major V16.

[antus]

I went down the git rabit hole again today, tried to get @crowbarmasters's merge 40 request in to develop in the official pcmhammer repo. Doing so I lost the history and the network/insights graph didnt show that crowbarmasters work landed in the official app. So I spent some time figuring out how to fix this. Eventually I determined that it couldn't be done without merge requests. I am not sure if blocking merge requests is default or if it was off for a reason in the official repo, but I have now turned merge requests on. Any feedback about if this is good thing or not is welcome. That did allow me to do another merge that should provide the history connection. Im waiting for guthub to rebuild insights/network, but hopefully we are in a cleaner state now and it'll show that make it easier to track changes again and gotten us past the challenges of so much parallel development over the last 6 months or year.

@crowbarmaster, I also grabbed the code in the head of your development branch to fix actions. I think all of those changes should be required and you are going in the right direction.

[crowbarmaster]

Ahh git - Certainly can become a real head-scratcher at times... Never turns out the way you'd expect it to.

I have been down a rabbit hole of sorts myself - I've been sorting out the UI and functionality to match a few key goals:

First big move is:
* Retooled the WritePage to be a "Setup dialog", driven into read or write by a enum that is set with the button press. This needs some layout considerations!
* Said dialog has the ability to select the writer method, and will offer a hardware type. This combo box is always visible, but only selectable from if an OSID check comes up empty. A total override is not programmed yet, but can be offered.
* Selectable debug output can be toggled before an action. Needs to spread to a global default in settings.
* Retooled the ReadPage to be the actual worker page. It's now just a cancel button, log output, and progress controls.
* Renamed "Other functions" to "Read/Write functions". Removed the "Verify" button, and replaced it with "Write PCM". Resorted so Read and Write come first.
* On the main page, Removed both Write and Test Write, moved Read/Write to the top left, Data logging to the right of that. Help and setting mid level.
* Exit button across the bottom.
* I finally sorted out the PcmInfo class, wrote a test method to compare old vs new on an OSID of each hardware type. Passed. I really wish i had a few of these different types to toy with, more specifically those I wrote as extensions of a base, like a 512k P04_Early just to get some extra verification in.
* I worked on the MockPCM to simulate the read of a P01. This helped with testing what happens when hardware with an unknown OSID is connected. I can override and read it as a P01, tested on actual hardware too!

Many other good things happening too. Right now, I'm trying to sort out that pesky storage permissions request that doesn't always fire... It's ridiculous that this needs some upper level request that can't be easy to call. I can't find any good information on how to provide this in a blocking call. If you come across anything good here, I'd love to hear it. I've tried a number of different cases and they all "work" but not consistently.

Screenshot_20260417-165952.png

Note: The errors above are during the phase of working out emulation of CRC. It works flawlessly now!

Screenshot_20260419-201443.png

Screenshot_20260419-201434.png

Screenshot_20260419-201421.png

Screenshot_20260419-201410.png

Edit: One more image: this one of what it looks like to come across an unknown ID. I plan to build with the correct ID omitted to see how it acts with real hardware yet.

Screenshot 2026-04-19 011344.png

Let me know what you think of all of this, happy to hear your thoughts!

[crowbarmaster]

Updates!

This one was a tough one. I spent way too much time trying to find a happy way to call dialogs up during the pre-flight checks. For whatever reason, I cannot get Invoke to work properly from any calls made in the PcmLibrary project. In every instance, the code would work in UI no matter the call location, but when hitting the ReadManager we would get the dialog but no await. After trial after trial, I finally determined it has something to do with the Dispatcher.

Well, this is actually okay, because we now have a loaded ECUBase reference held by the connection service. With that, we can perform the pre-flight checks before we leave the UI, and a simple switch sent down to skip them later. This whole concept needs more testing yet (Your run-in with that variable OSID comes to mind) but should prove to be a powerful feature. We can disable the Read/Write menu based on the connection status, lock down writing modes for unsupported models, etc.

At this point, I will be working in some warnings here and there, getting the branch cleaned up, do a flow test or two and I should have a new test release good to go!

Screenshot 2026-04-23 013228.png

Screenshot 2026-04-23 005102.png

Screenshot 2026-04-23 013249.png

Screenshot 2026-04-22 002038.png

[antus]

Ok thats cool. I guess this code lives in the arduino ui part of the app and is used in uno windows and android? do we need to try and keep winforms in sync manually?