No difficulties to download on Windows

[WMXZ]

I 'm reading from time to time that with windows there were difficulties to download programs to teensy

This happened to me also when usb-serial was implemented.

I cannot talk about TeensyDuino, as I'm using the command-line loader, but using cli I could make some changes to the code so this does not happen anymore.

It turned out, that after setting the baud rate to 134 , the baud rate was restored to the original (or 115 kBaud in case of TY)
as shown in the two code snippets.

Edit: first snippet is not from original command line loader but imported into my custom version from teensy_reboot.c that I used to augment the functionality of the original command line loader

int send_break(void)
{
	COMMCONFIG port_cfg, port_cfg_134;
	DWORD len;

	if (port_handle == INVALID_HANDLE_VALUE) return -1;
	len = sizeof(COMMCONFIG);
	if (!GetCommConfig(port_handle, &port_cfg, &len)) return -1;
	memcpy(&port_cfg_134, &port_cfg, sizeof(COMMCONFIG));
	port_cfg_134.dcb.BaudRate = 134;
	if (!SetCommConfig(port_handle, &port_cfg_134, len)) return -1;
// WMXZ:
// on my windows 8.1 and running T3.1 at 144 Mhz the following line
// was removed to guarantee that HalfKay started (entered pid 478 mode)
//	SetCommConfig(port_handle, &port_cfg, len); 

// following was removed by Paul
	//SetCommBreak(port_handle);
	//Sleep(50);
	//ClearCommBreak(port_handle);

	return 0;
}

    case TY_DEVICE_SERIAL:
        r = ty_serial_set_attributes(iface->h, 134, 0);
        if (!r) {
            /* Don't keep these settings, some systems (such as Linux) may reuse them and
               the device will keep rebooting when opened. */
            ty_serial_set_attributes(iface->h, 115200, 0);
        }
        break;

I put Koromix TY code here as it states the reasons for setting baud rate high again

Well, on my Windows 8.1 system, all problems were gone after I commented the line that restored the baud rate back to the original.

I let it up to Paul and Koromix to assess the validity and generality of this observation and if modifications to TeensyDuino and TY are needed, but for me the change solved the problem.

 

[defragster]

On Windows as long as I stick with the IDE and One connected Teensy 3.1 the system seems to run flawlessly. Trying to have two 3.1's or LC's in combo ends up with code going to a pre-determined one of whatever can be seen - this is ugly when 3.1.vs.LC code transfer happens. With 2+ Teensy's live I started using outside monitors to take the ports to force a button request and with 2 teensy's is when I started to see problems. Also with two Teensy active it is nice to see output from both and the IDE only supports one active Monitor.

 

[WMXZ]

On Windows as long as I stick with the IDE and One connected Teensy 3.1 the system seems to run flawlessly. Trying to have two 3.1's or LC's in combo ends up with code going to a pre-determined one of whatever can be seen - this is ugly when 3.1.vs.LC code transfer happens. With 2+ Teensy's live I started using outside monitors to take the ports to force a button request and with 2 teensy's is when I started to see problems. Also with two Teensy active it is nice to see output from both and the IDE only supports one active Monitor.

I have three T3.1 on a usb hub, which should receive all the same program. With the mentioned modification all three teensies react one after the other and get the program from the loader.

I nearly forgot, the code snippet I modified is originally from teensy_reboot.c (copied by me into the command-line-loader). Consequently, it may be used in the official upload command sequence.