Page 1 of 19

PCM Hammer Suite development

Posted: Mon Mar 09, 2020 7:06 pm
by Gampy
I'll start using this thread for PCM Hammer Suite development to remove the clutter from the PCM Hammer - new ls1 flash tool thread ...

I've copied two posts from the thread PCM Hammer - new ls1 flash tool here.

Re: PCM Hammer Suite development

Posted: Mon Mar 09, 2020 7:08 pm
by Gampy
(Copied from the thread PCM Hammer - new ls1 flash tool)

I cannot comment on Github, so here it is ...

PR #151
It is of my opinion there is a misunderstanding here ... It's looking for a 'PortName' that starts with 'COM' and does not have '(LPT' in it.
That is always going to be true ... else I believe it would violate MS PortName naming convention.

It doesn't stop the,
Unable to get port number for 'ECP Printer Port (LPT1)' / 'ACPI\PNP0401\4&3157C303&0' with port name 'LPT1'
I get if that is the purpose.

If I'm understanding correctly, what is trying to be accomplished would be like so,

Code: Select all

            if (!string.IsNullOrEmpty(this.PortName) &&
                this.PortName.StartsWith("COM") && 
                this.PortName.Length > 3)
            {
                int number;
                int.TryParse(this.PortName.Substring(3), out number);
                this.PortNumber = number;
            }
            else
            {
+                if(!this.PortName.StartsWith("LPT"))
+                {
                    logger.AddDebugMessage(
                        string.Format(
                            "Unable to get port number for '{0}' / '{1}' with port name '{2}'",
                            this.Name,
                            this.DeviceID,
                            this.PortName));
+                }
            }
That would silence the LPT debug messages.
However, I do have some other thoughts on this issue involving 'PortDiscovery.GetPorts(...)', I have not yet sussed out, will do so later tonight or first thing AM.
Or, maybe I'm just misunderstanding ... Please help me to understand!


PR #153
Definitely have to write the Boot segment with Os on the P01/P59 for sure, else things go bad, learned that the hard way, not so with newer Pcms as I understand it.

OsPlusCalibration and Boot is for future use, I have been watching Tazzi and daniel2345 threads.

As for the 'Os' addition, it completes the Segments and I was hoping to encourage someone to make the enum OR'able to handle multiple segments, thus the ability to remove the 'Plus' types ... I was not confident on (the math) how to do it.
Thus we could do the following for example.
currentWriteType = WriteType.Os | WriteType.Calibration | WriteType.Boot
I will remove them.

Re: PCM Hammer Suite development

Posted: Mon Mar 09, 2020 7:08 pm
by Gampy
(Copied from the thread PCM Hammer - new ls1 flash tool)

Speaking of BlockType ... Wouldn't that enum be better in FlashChip.cs??
Seems a bit out of place in Vehicle.TestKernel.cs.

I dunno know ... :oops:

Re: PCM Hammer Suite development

Posted: Mon Mar 09, 2020 9:45 pm
by Gampy
I did push the removal of WriteType's OsPlusCalibration, Boot, and Os for PR#153 ... :thumbup:

There is also the following PortDiscovery.GetPorts(...) technique using ManagementObjectSearcher.
This returns all ClassGuid objects except Service type 'Parport'.
It's barely a tick measurably faster, however it does smooth the screen look out on some machines, the original technique loops through all 'Win32_PnPEntity' objects, this is 150 to 200 objects on my systems depending, thus there is some screen flickering as it's looping.
Not a big deal.

Just thought I would post this up for brain food ... I can push the branch if it's wanted.

Code: Select all

        public static IEnumerable<SerialPortInfo> GetPorts(ILogger logger)
        {
            List<SerialPortInfo> result = new List<SerialPortInfo>();

            ManagementObjectSearcher Ports = new ManagementObjectSearcher(
                "root\\CIMV2", "SELECT * FROM Win32_PnPEntity WHERE ClassGuid = '{4d36e978-e325-11ce-bfc1-08002be10318}' AND NOT Service = 'Parport'"
                );
            foreach (ManagementObject portManagementObject in Ports.Get())
            {
                var portInfo = new SerialPortInfo(portManagementObject, logger);
                if (portInfo.PortName == null)
                {
                    continue;
                }

                if (portInfo.PortNumber == 0)
                {
                    continue;
                }

                result.Add(portInfo);
            }

            return result.OrderBy(x => x.PortNumber);
        }

Re: PCM Hammer Suite development

Posted: Tue Mar 10, 2020 6:20 pm
by antus
This is how I did it in ls1flash. Never had a problem with it missing ports or listing ports of the wrong type.

Code: Select all

using System.IO.Ports; // to get port list

            //show list of valid com ports
            int i = 0;
            foreach (string s in SerialPort.GetPortNames())
            {
                ComPort.Items.Add(s);
                ComPort.SelectedIndex = i++;
            }

Re: PCM Hammer Suite development

Posted: Tue Mar 10, 2020 8:35 pm
by Gampy
That is basically the same technique that was there originally and is the typical Microsoft recommended technique.

However it only returns the "PortName". ie: COM<n>.

NSFW added a WMI technique that gives the "FriendlyName" like in Device Manager. ie: Communication Port (Com<n>)
Albeit slow, it does provide a nicer looking Port Selection list.

It is actually something Serial Programmers have been bitching to MS about for as long as I can remember.
MS does not think (or understand why) the General Programming public needs/wants access to the "FriendlyName" and that we only need/want the "PortName".
Yet they use the "FriendlyName" themselves! ... Dumb F's.

WMI runs like molasses on a cold day!
It sucks at best, however there is a boatload of information available through it.

Re: PCM Hammer Suite development

Posted: Tue Mar 10, 2020 8:56 pm
by antus
Thats interesting. I cant see why you would need it either, i have never needed or used friendly name. Com doesnt mean anything useful, but its short so doesnt pollute the interface
and the port is just a number. Even if friendly name is shown, if 4 ports all say FTDI, it doesnt add much. Maybe it helps someone, but i'd say less is more in this case. Being able to search all ports and find the interfaces by throwing protocol init down there and seing if a sain response comes back would be nice.

Re: PCM Hammer Suite development

Posted: Tue Mar 10, 2020 9:37 pm
by Gampy
My minimalist ways agree with you ... The good ol KISS adage I'm very fond of.

However I do like the FriendlyName list, how much??, I'm not going to complain either way, it is what it is.

Probing ports on Winblows can be very hazardous to ones mental health!
Don't get me wrong, it's doable ... things do tend to go south at times when doing so.

Re: PCM Hammer Suite development

Posted: Sun Mar 15, 2020 5:10 am
by RoninDusette
Meh. They have always been like that. Won't change. Especially when it comes to the "open-source" or just gp altogether. If you ain't turnin' them a profit, you can get bent. :/ Hell, their OS still relies on age-old bugs to function because they cannot be bothered to refactor (though they have been making huge strides in breaking up the monolithic nature of Windows lately). It always trips people out when I tell them that they use *nix all the time. Microsoft has the only OS that is like Windows. Ahhhh, the 90s. What a golden age for them... Ha.

Re: PCM Hammer Suite development

Posted: Fri Apr 10, 2020 4:53 pm
by NSFW
Sorry I've been out of the loop for so long, but I just fixed the LPT issue and merged a bunch of pull requests.

The only PR I didn't merge is the one that removes a bunch of WasteTime calls, because Antus had a PR that might also be sensitive to timing changes, so I want to test before and after first.

The others all looked straightforward so I figured I'd merge first and test later. :)