.Net 8, cross platform, and Windows 7/8

[NSFW]

I want to take a shot at combining the flashing and logging apps into one, and creating the new UI using Uno: https://platform.uno/

But there's a catch: It would require upgrading to .Net 7 or 8, both of which require Windows 10 or later. No more support for Windows 7 or 8.

How much does that matter?

One of the advantages of switching to Uno for the UI is that we could, at least in theory, support smartphones and Linux. Making it really work on those platforms would require some extra effort to get serial ports working on each platform, since the .Net serial port API only works on Windows right now, but I think that's probably do-able.

But even if Linux/Android/iOS doesn't pan out, I still like the idea of using PCM Hammer on a cheap Windows tablet with a touch-first UI. Or even just on my laptop, with a UI that lets me do everything via touch.

In theory it's probably possible to build the core code for .Net 4.6 and Windows 7/8, with separate csproj files in the PcmLibrary directory, but it kinda sounds like a headache to maintain both builds at once, and both versions of the UI.

What do you all think about cutting support for Windows 7/8?

[NSFW]

BTW, I already updated everything to .Net 8 on my laptop while working on some logger improvements, before I realized that it was going to break Win7/8 support.

If there are no objections I'll just open a pull request with what I have now. Otherwise I'll undo the changes to the csproj files first.

[Tazzi]

Being the latest and greatest is not always the best, but in this circumstance, it is.

Moving to .net 8 would also open the world to a smartphone application. While I am not trying to push the agenda to be smartphone, it is always an option.

I would focus on supporting windows 10 and 11, since most computers accepted a free upgrade (And still do).

On a slight side note while Im thinking of it about PCMHammer edits, I believe the 'read' button should be in the button options. Iv had several customers send their ECU back in to get a fresh file put into it since they have not understood how to read their current ECU tune, and thought you had to find a bin file off the net to flash in

[antus]

Smartphone would not be usable for J2534, which is what I suspect at least 50% of the userbase are using. The scantool obdlinks are the slowest and most problematic and suck, AVT is no longer produced. OBDXpro has serial and J2534, but there a lot of vx-nano users (and other interfaces) on J2534.

I am usually skeptical of new UI products. They often die in the 2-3 years. None the less I do see the benefit and for me personally GUI is always the hardest so help is appreciated if you want to go that way. I'd love to talk the UI over with you and make some improvements now the product has grown and the original GUI requirements don't 100% match the tool if you have the time. For example many of the targets cant do a calibration flash, and I am not even sure calibration flashes make sense now we only flash sectors that need to be updated anyway, so it doesn't make sense that is the only write option on the front page of the app.

It'd also be good to put the can bus support in the logger in to the main driver class in a generic way. Thats not a priority, but it would be a nice to have if the two tools continue to share the same repo.

Are you tracking this branch in the new repo? https://github.com/PcmHammer/PcmHammer/ ... 240908-wip P04 is stable and done now, and E54 is working but not for one tester. A bricked E54 (which was working until we wrote the bin from the problematic test E54 to it - so strange one that) is in the post to me and I intend to figure out the BDM when it arrives and recover it then stabilize the E54 kernel with it then shoot for release of PCMHammer 2.0. Note that that branch in the pcmhammer organisation repo, rather than your personal one.

I am not sure about win 7/8. I think most tuners would have several laptops of different generations for different tools, or be virtual. If we were to drop win 7/8 it'd be nice to get pcmhammer 2.0 out with the new platforms, then update the libs so at least those on win 7/8 version can continue to use the old gui for the most common pcms, including the new ones.

[NSFW]

I like the idea of doing full writes by default, with CRC checks being used to determine which blocks really get written.

I worry about the lifespan of UI libraries, too. Microsoft abandoned WPF, then UWP, now MAUI is what they want everyone to use... I kinda like the fact that Uno is not a Microsoft thing. No guarantees of course, but I'd rather gamble on the open source community to keep supporting Uno than gamble on Microsoft to keep supporting MAUI.

I don't honestly have a clear picture of what the UI is going to look like. I plan to just create an app with buttons that do nothing, make it up as I go along, imagine myself using it, and iterate. I'll push the code up to GitHub and share screenshots as I go, to get feedback.

--

It's kind of hard to articulate why I don't think it makes sense to unify the CAN logger with the existing device classes... The main thing, to me, is that the existing device classes are all wrappers around devices that support OBD2. The Seeed CAN interface does not know that OBD2 exists - it wasn't made for use with ECUs, it just converts serial data to CAN and vice-versa. That's fine for listening to data from wideband O2 sensors, but I don't know how to use it to talk to an ECU.

Another way to look at it is that if we wanted to support flashing ECUs that use CAN, we'd use the same hardware that we support today, and the same Device classes - we'd just pass a different flag to Device.Initialize() to tell them to speak CAN instead of VPW.

If someone wants to use the Seeed interface as an OBD2 interface, they could create a new SeeedDevice class for it... but that would require learning how to convert OBD2 messages to CAN messages, and vice-versa. I'm sure it's possible, but I don't know how that works, and I don't think it makes sense for anyone to invest time in that when we can just use the same OBDX / Scantool / AVT / etc devices and send them a different command during initialization that tells them to use CAN instead of VPW.

For Elm devices, for example, this is the step that would need to change:

await this.implementation.SendAndVerify("AT SP2", "OK") // Set Protocol 2 (VPW)

I'll admit that I might be overthinking this.

[NSFW]

Also, no, I hadn't see the new branch in the new repo. That's really cool.

I'm totally on board with doing another release that uses .Net 4.6 and supports Win 7/8. I'll undo my .Net changes and create a pull request with just the logger changes, probably this weekend.

[kur4o]

I vote for legacy version too, that can expand to .net 4.0 if possible.

Initial CAN support using ISO15765 protocol will be easy implemented, just setup filters, headers and start sending message with slightly different overhead, just like vpw protocol and let the tool do the hard work

If there isn`t any j2534 android support it is kind of useless to expand it. And pure serial raw CAN will bogg down any modern android device in seconds.

[NSFW]

It took longer than I expected, but I just created a pull request with the logger changes, without the .Net changes:
https://github.com/PcmHammer/PcmHammer/pull/3

Lesson learned: when Visual Studio says "Your project does not reference ".NETFramework,Version=v4.6.1" framework. Add a reference to ".NETFramework,Version=v4.6.1" in the "TargetFrameworks" property of your project file and then re-run NuGet restore" what they really mean is "delete the bin and obj directories." I'm only a little bit grumpy about the amount of time I wasted before I found the answer on Stackoverflow.

But anyway... Regarding "let the tool do the hard work" - yes, that works for OBD2 interfaces. But, for logging CAN from sensors that aren't on the car's factory CAN bus, like AEM's widebands, oil temp sensor, fuel pressure sensor, etc, I used a non-OBD2 CAN interface (https://www.seeedstudio.com/USB-CAN-Ana ... -2888.html). Since it doesn't support OBD2 it doesn't use the Device classes that we used for the OBD2 interfaces, and I don't think it should.

[antus]

I know it sounds bad but I am glad more experienced visual studio devs also get caught by those kinds of things. I thought it was just my infamiliarity with the platform and it was something you just got used to and could feel your way through where to look for answers or something

For the OBD2 stuff, I don't think that is the problem you think it is. It only affects hardware source and dest filtering, and I think even that interface has that, so I don't see the actual difference you are talking about when you say "non-obd2" compared to the other devices, other than the elm type protocol devices, but for example AVT/J2534 work like the device you have already, I think, so there is a pattern. What's different is the packing of the addresses in the header which is a problem we need to solve if we use the same libs for CAN also for the other existing interfaces.

[NSFW]

The nice thing about Visual Studio is that so much stuff just works.
The awful thing about Visual Studio is that when something doesn't work, it's often impossible to figure out why.

The thing that worries me most about trying to make the Seeed canbus thing work as an OBD2 device is sending and receiving large arrays. For OBD2 messages that fit within a single canbus frame, it's probably trivial, but to send 2k to the kernel? I have no idea. I'm not at all opposed to it, if someone wants to tackle that, but I'd rather spend time on the data logger and/or the new UI.

And speaking of the new UI, I have something halfway mocked up: https://github.com/LegacyNsfw/UnoExperiment1

I want to add icons to the buttons on the main page, and I have no idea what the logger should look like yet, but it's coming along.

PCMHv2-large.png

PCMHv2-small.png

PCMHv2-write.png