This topic is related to the thread on over-the-air (OTA) programming for Teensy 3.x/4.x. I am trying to automate the process of flashing updates to a Teensy 3.5 using a BT link (HC-05 probably). I use VS2019 with the Visual Micro (VM) extension for all my Arduino/Teensy programming, so my plan is to use VM's post-build command feature (board.txt) to launch a custom C# console app and pass the information needed to find and then transmit the updated HEX file to the Teensy. So far in my development I have been using a wired serial connection - not an RF one.
The VM post-build command looks something like this:
The arguments in {} are expanded to the actual values present in the build properties for the project. This worked fine sometimes, but other times the second argument didn't get expanded - it appeared in my C# console app as the literal string '{serial.port.label}' instead of something like "COM11 (Teensy 3.5) Serial".
When I investigated this further, I discovered that the build properties advertised to VM change significantly depending on which port is selected in the drop-down menu in VS2019, and whether or not a physical device is actually connected to the other end of the serial connection.
When a port is selected that shows as available, but doesn't actually have anything at the other end, the build properties available for post-build use are something like
But if a T3.5 is connected to the other end of the serial connection, selecting the same port number (COM11) shows:
And, if I select the 'other' port item that always shows up with a Teensy connection, i.e. 'usb:10000/0/0/2/4/9' then I get the following as available build properties
So, if I need the port number so I know what serial port to use to transmit the HEX file, I can use {serial.serial.port.label} if the Teensy isn't actually connected, OR if I had selected the alternate port naming convention (usb:10000/0/0/2/4/9). But, if I select the normal COMxx item in the drop-down list, I have to use {serial.Name} or {serial.port.caption} or {serial.Caption}. As you can see, there is NO overlap in available build properties that contain the serial port number between the two 'connected' cases - yikes!
I'm making the rash assumption here that the relevant build properties reported by VM when I select 'show build properties' must be provided by the Teensy device when it physically connects to the serial port. If so, it sure would be nice if at least the two 'connected' cased advertised the same set of build properties. Ideally, all three cases would offer the same {serial.port.num} property that is available for other devices, but if that isn't possible, then at least {serial.serial.port.label}.
I realize that its possible this actually doesn't have anything to do with Teensy, and so I apologize in advance if I'm barking up the wrong tree here
TIA,
Frank
The VM post-build command looks something like this:
Code:
recipe.hooks.postbuild.2.pattern=cmd.exe /c "C:\Users\Frank\Documents\Visual Studio 2019\Projects\TeensyFlash\bin\Debug\netcoreapp3.1\TeensyFlash.exe" "\"{vm.runtime.build.final_output_path}"" {serial.port.label}The arguments in {} are expanded to the actual values present in the build properties for the project. This worked fine sometimes, but other times the second argument didn't get expanded - it appeared in my C# console app as the literal string '{serial.port.label}' instead of something like "COM11 (Teensy 3.5) Serial".
When I investigated this further, I discovered that the build properties advertised to VM change significantly depending on which port is selected in the drop-down menu in VS2019, and whether or not a physical device is actually connected to the other end of the serial connection.
When a port is selected that shows as available, but doesn't actually have anything at the other end, the build properties available for post-build use are something like
Code:
serial.serial.port.port=usb:10000/0/0/2/4/9
serial.serial.port.label=COM11 (Teensy 3.5) Serial
serial.serial.port.protocol=TeensyBut if a T3.5 is connected to the other end of the serial connection, selecting the same port number (COM11) shows:
Code:
serial.port.caption=COM11 - USB Serial Device
serial.Caption=USB Serial Device (COM11)
serial.ClassGuid={4d36e978-e325-11ce-bfc1-08002be10318}
serial.CompatibleID.value0=USB\Class_02
serial.ConfigManagerErrorCode=0
serial.ConfigManagerUserConfig=False
serial.CreationClassName=Win32_PnPEntity
serial.Description=USB Serial Device
serial.DeviceID=USB\VID_16C0&PID_0483\3016580
serial.HardwareID.value0=USB\VID_16C0&PID_0483
serial.Manufacturer=Microsoft
serial.Name=USB Serial Device (COM11)
serial.PNPClass=Ports
serial.PNPDeviceID=USB\VID_16C0&PID_0483\3016580
serial.Present=True
serial.Service=usbser
serial.Status=OK
serial.SystemCreationClassName=Win32_ComputerSystem
serial.SystemName=FRANKNEWXPS15
serial.vid=0x16C0
serial.pid=0x0483
serial.vidpid=16C00483
serial.vid_pid=0x16C0_0x0483
serial.iserial=3016580
serial.port.iserial=3016580And, if I select the 'other' port item that always shows up with a Teensy connection, i.e. 'usb:10000/0/0/2/4/9' then I get the following as available build properties
Code:
serial.port.file=usb:10000/0/0/2/4/9
serial.port=usb:10000/0/0/2/4/9
serial.port.port=usb:10000/0/0/2/4/9
serial.port.label=COM11 (Teensy 3.5) Serial
serial.port.protocol=Teensy
extra.time.local=1632690140
extra.time.utc=1632704540
extra.time.dst=-14400
extra.time.zone=14400
serial.serial.port.port=usb:10000/0/0/2/4/9
serial.serial.port.label=COM11 (Teensy 3.5) Serial
serial.serial.port.protocol=TeensySo, if I need the port number so I know what serial port to use to transmit the HEX file, I can use {serial.serial.port.label} if the Teensy isn't actually connected, OR if I had selected the alternate port naming convention (usb:10000/0/0/2/4/9). But, if I select the normal COMxx item in the drop-down list, I have to use {serial.Name} or {serial.port.caption} or {serial.Caption}. As you can see, there is NO overlap in available build properties that contain the serial port number between the two 'connected' cases - yikes!
I'm making the rash assumption here that the relevant build properties reported by VM when I select 'show build properties' must be provided by the Teensy device when it physically connects to the serial port. If so, it sure would be nice if at least the two 'connected' cased advertised the same set of build properties. Ideally, all three cases would offer the same {serial.port.num} property that is available for other devices, but if that isn't possible, then at least {serial.serial.port.label}.
I realize that its possible this actually doesn't have anything to do with Teensy, and so I apologize in advance if I'm barking up the wrong tree here
TIA,
Frank
