PCM Hammer - The Uno UI, Improvements, and priorities

[antus]

Close!

[crowbarmaster]

I do agree - it's time to get this into a few hands for real world testing.

I just opened a PR that will bring all current changes into develop. When you can take a good look down it, make sure things make sense to you all and we should be in good shape. There are definitely a few flaws about, but I can read/write over and over with the same connection and things work well. I even managed to make the OBDX reconnect correctly in both USB and BT (There are still ways it wont, though).

It should be fairly easy to create another alert dialog much like the one used for the countdown... but might be just as well to come up with a full screen landing page that can provide a bit more information. This same page could be used to provide users with a changelog too. Say we keep a reference to last known version on disk, and the presence of a new > old mismatch will trigger it's appearance.

That would be a huge win! I actually had some issues when I was first getting started due to the Uno branch at the time holding outdated kernel source... I spent a couple hours chasing a ghost.

So what does that look like on your end? Increasing delays between comm events? Or is it more a delay between the com layer and its hardware? This is a side of things I could have someday gotten to and never did. Many props good sir, the number of people I know writing ASM today still lands on one hand lol.

I just saw your post. Did you happen to get a request for all files access? Next thing to do will be to browse your storage for PCMHammer/bins folder and see if it's populated with kernels.

[crowbarmaster]

I do not have a device to test with, but all 3 applications fire up and act as they should.
https://github.com/crowbarmaster/PcmHam ... 4260211966

Do not have an android device, vehicle interface or bench pcm? All 3 would be helpful to have

I'll do some bench testing with your artifacts now.

I used AI for a bit of experimentation on a non-public build and added serial and bt support but I had a bunch of trouble with usb devices dropping out and comeing back from movement in the otg connector and I did see the BT device come alive for a moment and get some vehicle comms but it was just as I clicked another port and I have not been able to get it to talk again. I'll see if your stack is working better, but I think in general we are going to have some trouble with the uno interface being more of a real time flow with background tasks while settings can be changed.

I do have some suggestions up front. The back arrow on the settings page is very small and hard to see, and also hard to click. The front page haveing a write button but not a read button is not real. We definately want users to read a bin before they try to write anything incase they need to recover. On the settings page it might be helpful if there is enough screen realestate (responsive design?) to have some debug info so you can see what's happening as devices try to initialise. Also the form doesn't save changes until you get a successful connection. In the case of BT devices its likely that someone would connect the device without the car connected and then go and plug it in. So I think it is valid to allow the device picker to save without the vehicle connection, otherwise its extra clicking once your on the car and not intuitive like other apps where device picker is independent of app usage.

I only had my phone at that time

The back arrow on the settings page is very small and hard to see

That definitely needs a change, I have trouble with it constantly. We will need to think of ways to handle that. I almost wonder if we can't override a handle to the native Android back swipe/button and opt to all together hide that in an effort to save precious space there.

The front page having a write button but not a read button is not real.

This pretty much goes hand in hand with what was said previously. I almost think it wouldn't be a bad move to work with a single Read/Write button that can be found in the other functions button. Then relabel "Other functions" to "Flashing menu" or the likes of. At the very least, we work out a way to rescale and add a button there. I think this leaves us a window of actions that provide similar functionality.

On the settings page it might be helpful if there is enough screen realestate (responsive design?) to have some debug info so you can see what's happening as devices try to initialise.

My demo app had that and I can agree that would be pretty valuable.

Also the form doesn't save changes until you get a successful connection. In the case of BT devices its likely that someone would connect the device without the car connected and then go and plug it in.

Yeah that did seem like it was intentional originally. I can see where it would be reasonable, especially with BT where the selection will be a bit more certain, to just save them and start polling that device. Also, I have recently found that its a could cause some interesting situations trying to switch devices and getting switched back.

[NSFW]

The front page haveing a write button but not a read button is not great. We definately want users to read a bin before they try to write anything incase they need to recover.

That's a really good point.

It seemed reasonable because tuning is basically one read followed by dozens of writes, so the write button should be prominent and the reading can be tucked away where it takes an extra click or two to get to it...

But yeah that totally creates the wrong impression for someone who is just getting started.

[antus]

For the countdown, I'd like to remove it completely and improve the unlock failure handling (if we even need to change it). The response should tell us rejected due to too many attempts or not ready, and I dont think we sleep but we could put a 5 second delay on it so that we dont use all the 3 attempts before hitting the 10 second too many attempts error. Then it'd fail the first attempt. wait 5 seconds, try again which would work if the pcm was on for more than 5 second but not 10, and if it still failed then it'd wait another 5.. something like that. Could even try it every 2 seconds if we don't lock ourselves out and it works at the 10 second mark. It's been a while since I read the spec for this, though I did already clean up the handling a little in the current work branch because it logged some dumb stuff for some the failure conditions. Then its one less dialog so the ones people need to worry about are less likely to get clicked through. People would click read, and maybe it'd take a couple more seconds to unlock, but it would not be a problem.

[crowbarmaster]

I found the issue with your test, Antus.

We both had our own take at adding Kernel assets, but it looks like you win the battle I didn't realize you ended up manually adding those assets to the APK in the workflow file.

I fixed that, and I should see new builds soon!

[antus]

Ok great! Im trying to get my branch merged but having trouble with tooling. Since you rebased from mine, then yours should cleanly land on top also. Both of them are blocking merge due to conflicts from the UI but talking to codex it should be OK to do a FF merge and that will be clean. Problem is I cant see a way to do that from the UI, and the API is fighting me with access issues to my PAT. Hopefully will have that sorted shortly, before guests arrive in 30 minutes.

On the kernel changes, I dont know what to change yet. My theory is that after one of the DLC operations things are on the edge of stability and if you smash it too hard eventually you crash the DLC and the PCM. So the idea is to compare to other kernels and see if we are missing a delay around DLC operations, or if our delays are significantly shorter (I think they are...) as some kernels use 1000 loops of nop and I think ours only runs about 4 opcodes, which might be 4 or 16 clock ticks. So I'll try putting 1000 loops in or something like that once I know what/where I'm looking and send to Ron as he can reproduce the failure reliably on his P11s.

[crowbarmaster]

New builds can be had here:

Edit: I got too hasty and missed one string change. Give me another 15 minutes!

Interesting stuff! Sounds like it's truly some trial and error when it comes down to it.

[NSFW]

Uno app button proposal:

First row: Settings / Data Logging
Second row: Read PCM / Test Write PCM / Write PCM (three buttons, because why not)
Third row: Other Functions / Help

I like the idea of keeping Test Write on the front page as a reminder that writing has risk, so people should test first.

While reading also counts as a test, it's not obvious that it's a test that you should do before a write. And it takes a long time compared to a test write.

[antus]

I had to use a squash merge but it is safely merged. please do send more pull requests on top of it for smaller changes and features and I'll try and do the same.

For buttons I think we only need Read and Write but that should go to another page with a new bunch of realestate to pick options. Test write is not there yet, but it could be. I'm not actually sure how helpful test write is. It can pick up comms errors but then so does a read. And writes generally fail because of low voltage, bad hardware etc. And without doing the write you wont pick any of those up. Personally I never use test write, and always do a read to test those things. The head space is good, but also I have seen reports of people saying "It passed on a test write then bricked on a write" which I think in most failure cases is what is going to happen.