Windows 7 users - how long does reprogramming take?

PaulStoffregen

Well-known member
I'm working on the Keyboard+Mouse+Joystick support for Teensy 3.0.

Today I started testing on Windows 7. After clicking Upload in Arduino, I noticed there's a long delay from the moment the code is compiled to when the Teensy Loader actually starts reprogramming the board. I tested on Teensy 2.0 and the same thing happens.

If you're using Windows 7 and have a Teensy 2.0, could you please do a quick timing test? Set Tools > USB Type to "Serial", then upload a couple times, and then measure the time taken from the end of compile until the Teensy Loader begins doing the programming. Then change Tools > USB Type to "Keyboard+Mouse+Joystick", do a couple uploads (do *not* measure the speed on the first upload after a change.... do a couple uploads first) and then measure the delay again.

On my test system, there's about a 1 second when using Serial, about about 9 seconds when using Keyboard+Mouse+Joystick! I wiped the system and restored a clean image, but got the same result. Does anyone else see these results?

Mac and Linux have no noticeable delay.
 
Windows 7 64 bits SP1
Teensyduino beta7
Teensy Blink
Teensy 2 without anything soldered to it

Serial : more or less 1s between end of compile and start of upload
K+M+J : 12s
 
I'll look at testing as above later,(edit - oh you were wanting tests with T2, nevermind there hten) not sure if this is related, but I've noticed a significant (several seconds) delay on my win7(pro) 64 box while doing stuff in the arduino IDE, ie. clicking the sketch and tool menus, serial, etc.
my win7(stater) 32bit netbook does not have this problem at all.

Edit: actually what I suspect is causing the problem on mine is the 11or so COM ports all labeled BT PORT these have something to do with the built in Bluetooth my motherboard has. might have to play around with drivers.
 
Last edited:
Edit: actually what I suspect is causing the problem on mine is the 11or so COM ports all labeled BT PORT these have something to do with the built in Bluetooth my motherboard has. might have to play around with drivers.

Yhis is one of the things that Arduino ERW fixes, compared to the stock Arduino install. Unfortunately, ERW is not compatible with Teensyduino.
 
Am I really the only one having a T2 and W7 here ?
Maybe making this thread sticky maybe would draw more attention. Don't let Paul down when he ask for help !
 
Windows 7 32 bits SP2
Teensyduino beta8
Teensy Blink
Teensy 3
Around 2/3 sec max via usb.

Teensy 2
Around 3 sec.
 
Windows 7 64 bits Home Premium SP1 (US English with UK English keyboard)
Teensyduino beta8
Teensy Blink
(all via powered USB hub)

Teensy 2.0
Serial : less than a second
K+M+J : 5s
S+K+M+J: 5s

Teensy ++ 2.0
Serial : less than a second
K+M+J : 3s
S+K+M+J : 3s

Teensy 3.0
Serial : less than a second
K+M+J : 4s
S+K+M+J: (not implemented)
 
Hi Paul, hopefully my findings may help in nailing the issue here. I just found this thread whilst searching for a solution to a linked issue that has just arisen. I am suffering the same delay as you between compile and download, though i am sure this did not used to happen. It just started one day and I have no idea why or what actions lead to it.

However, I now have another issue which appears to be linked. I am currently working with a Teensy 2.0++ and I am using the USB serial to communicate with a serial protocol I have written. All of a sudden today I now have the same lag as seen when programming whenever my program tries to enumerate the Teeny using WMI. I have a project on the Teensy that listens for messages from a C# project executing on my PC. The messages are sent over USB serial and I am using harware serial for debugging. I have been working on this for nearly a year in total and have never suffered this issue before. All of a sudden, as of today, when my PC program attemts to enumerate the Teensy using WMI I get a lag of between 16 & 21 seconds !

An abstract of my C# code:

using System;
using System.ComponentModel;
using System.Diagnostics;
using System.IO.Ports;
using System.Management;
using System.Text;
using System.Timers;

ManagementObjectCollection queryResults;
ConnectionOptions conn = new ConnectionOptions();
ManagementPath path = new ManagementPath(@"\\.\root\cimv2");
ManagementScope scope = new ManagementScope(path, conn);
ObjectQuery query = new ObjectQuery("SELECT PNPDeviceID, DeviceID FROM Win32_SerialPort");
query = new ObjectQuery(string.Format("SELECT PNPDeviceID, DeviceID FROM Win32_SerialPort WHERE PNPDeviceID LIKE '%{0}%'", this.PNPDeviceSubstring));
ManagementObjectSearcher searcher = new ManagementObjectSearcher(scope, query);
queryResults = searcher.Get();
Stopwatch delayTimer = new Stopwatch();
delayTimer.Start();
if (queryResults.Count > 0)
{
delayTimer.Stop();
if (tsMain.TraceVerbose) Trace.WriteLine(string.Format("Delay was {0}ms", delayTimer.ElapsedMilliseconds));
queryResults.GetEnumerator();
string deviceID;
string pnpDeviceID;
foreach (ManagementObject result in queryResults)
{
deviceID = result["DeviceID"].ToString();
pnpDeviceID = result["PNPDeviceID"].ToString();
if (tsMain.TraceVerbose) Trace.WriteLine(string.Format("DeviceID: {0}, PNPDeviceID: {1}", deviceID, pnpDeviceID));
if (pnpDeviceID.Contains(this.PNPDeviceSubstring))
{
if (tsMain.TraceVerbose) Trace.WriteLine(string.Format("Found MicroController serial port: DeviceID: {0}, PNPDeviceID: {1}", deviceID, pnpDeviceID));
m_PortName = deviceID;
return true;
}
}
}

The PNPDeviceSubstring used in the format string is "VID_16C0&PID_048"

The program gets stuck at the line "if (queryResults.Count > 0)" and this is why you see that line wrapped with a stopwatch to measure the delay.

It seems to me that these 2 things, the delay between compilation end and programming and my new WMI enumeration delay, must be linked and I am guessing it has something to do with the way Windows sees USB devices as different entities for each different USB port they are connected to. I am currently backing up my PC with a view to stripping out all references to the Teensy from the registry at :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB

Hopefully this will prove my theory either way.

I am using USB type:

Serial + Keyboard + Mouse + Joystick

I know the port is currently COM7. If in my program I replace the above code with this:

_PortName = "COM7";
return true;

. . . the delay has gone. This proves the issue is the enumeration of the port, not the connection to the port. If I get any further I will update this thread but it feels like this must be a huge pointer to the problem.

Please let me know your thoughts.

Edit:

The compilation to programming delay I suffer is approx 7 seconds
 
Last edited:
Okay so I got rid of my 20 second delay by stripping all references of devices with Vendor ID 16c0 using:

USBDeview v2.20 - View all installed/connected USB devices on your system
Copyright (c) 2006 - 2012 Nir Sofer

http://www.nirsoft.net/utils/usb_devices_view.html

This causes Windows to detect it as a new device again and hey presto 20 second delay has gone, still have the programmer delay though
 
Last edited:
Back
Top