pcmhacking.net

I've got an extremely preliminary, completely untested, totally not ready for more than a cursory glance, probably introduces more problems than it solves, set of changes that removes the response object in favour of using the exceptions.

I will need to go get another PCM before I can test the vast majority of this because I can't be toying with the one in my truck right now, but I think I'm heading in the right direction. If anyone cares to have a look at the changes and either tell me I'm headed in the wrong direction or point out things that could be problems, I would appreciate the input. The changes can be seen here: https://github.com/patrickmcquay/PcmHac ... exceptions

A lot of the changes involve removing cases where failure is checked for after calling something, in favour of just letting exceptions from the called thing pass through to be logged in the frontend. This will change how the messaging for errors happens, so making sure that still makes sense will have to be a step in testing. That said this does remove about 1000 lines of code, so things will get at least a bit simpler.

I do see another thing that can be optimized a bit as well, I think. There are a _lot_ of cases of hand coded retry loops that could be refactored into helpers that take lambdas. Some of these cases are multiple loops deep as well. I'm not entirely sure that that sort of thing is needed, but my point isn't to say those should be removed. My point is that this logic happens a lot, so IMO it should be centralized and standardized. There is a lot of good commentary and examples in this thread: https://stackoverflow.com/questions/156 ... etry-logic (also a lot of people saying don't do it, which tells me they've never worked with flaky serial connections before...)

From a quick skim I can see a lot more code coming out than going in, which is usually a sign you are on the right path.
Just watch out for the fact that I plan to merge antus/p08 branch in to develop as soon as I hear back from NSFW and he is able to approve the merge. I havnt seen Gampy for a while and so I need him to approve the merge which does not exist yet.
i wonder if it'd be possible for you to rebase off antus/p08 before you get too far ahead?

From what I can see this will not be terrible to rebase. I have a lot on the go for the next week or two, so its no big deal for my work here to wait for yours to merge.

OK Cool. I did a rebase off develop at some stage so there want too much divergence. It might not be a big deal but there are still some heavy changes, which are mostly PCM data and some usability improvements pending.

If your git foo is strong you can probably compare the branches and see if were going to have merge hell or not. Quite possibly not if your mostly in the comms libraries etc whereas I touched the UI logic starting operations and PCM Info/Types.

I mean, most of my work is nearly guesswork at this point. I think that the main part of the merge conflicts here is going to be mainform.cs, and I don't think its going to be a big problem. I'll just wait for your work to be merged, and if it hasn't in a couple weeks, then I'll see about rebasing.

kur4o wrote: ↑Tue Apr 30, 2024 5:47 pm Mode AE command for realtime control, like AFR, spark, engine speed and so no. Some crank relearn logic will be great too. I have some logs for crank relearn and also most of the ls1 AE command set.

It's been over a year, but I just stumbled on this thread again and notice what you said about AE commands... I'm not familiar with those, but it sounds like it would be fun to add support for them.

What can you tell me about them?

Thanks!