Here’s a fresh compile from ‘main’: “PR 139 + if 3 high bits of 2 wire LED frame are set, the global brightness is honored, else it will set the bits and full brightness. + if pin is not available reset and exit mode gracefully (LED only so far)”
I know little of powershell and less of scripts (hardware guy), but looking at the device IDs in device manager, the device instance for COM3 ends in “02” and COM4 ends in “00”. COM4 is the terminal.
It appears that Windows’ assignment of USB interfaces to COM ports is … not predictable. What you indicated is that interface 00 was assigned the higher COM port number, and the interface 02 was assigned the lower COM port number. It’s not clear why Windows sometimes does this. If you happen to discover a root cause, it would be of interest.
The good news: Because the BP hardware has a unique serial number in the USB descriptors, you should now be able to change the COM port to whatever you want, and it will “stick” for that particular buspirate, even if you change which USB port you plug the device into. So, if you change the COM ports to, for example, COM70 for the terminal and COM71 for the binary interface, then unless you uninstall the device from device manager, they will be fixed (unless something else was using COM70 or COM71). Since a conflict would change the COM port, I recommend assigning a relatively high value (e.g., COM70, COM71).
Not really. For example, Linux users can use udev to create symlinks. The symlinks can be based on the USB port the device was connected to, so for a fixed machine (e.g., four USB ports), you could define a rule that creates the symlink /dev/buspirate-1 for the first USB port terminal interface, /dev/buspirate-1-binary for that same device’s binary CDC interface, /dev/buspirate-2 for the second USB port terminal interface, … (etc.)
Or, unless you’re Ian, you likely only have a limited number of them, and can setup udev rules for the specific serial number to always get a specific symlink. For example, I could have:
2GB BP5 → /dev/buspirate5-2gb
1GB BP5 → /dev/buspirate5-1gb
1GB BP5XL → /dev/buspirate5xl
1GB BP6 → /dev/buspirate6
Even with four devices, that’s just listing four serial numbers in the udev rules … so likely reasonable for a linux user?
Each unique serial number results in a unique device in Windows. Device manager tracks all devices it’s ever seen.
At least some versions of Windows apparently try to keep the COM ports for previously-seen devices locked for that device? (Maybe it’s only during a given boot, or where software isn’t releasing the handle to the COM port?)
Regardless, the manufacturing hit the maximum COM port limit in Windows at some point, and thus had to reboot the test machine every N units (e.g., every 126 units tested) when the unique serial numbers are used.
Here’s a fresh compile from ‘main’: “begin conversion to universal inlined PIO idle detection function. Begin implemention of universal power supply and pull-up resistors check, error messages. Fix bug in syntax processing related to repeated operations”
Here’s a fresh compile from ‘main’: “preflight sanity check added to upper processing layers for all protocol modes, as well as protocol commands (when -h flag is not present)”