Have been experienced some delays/slowdowns with the arduino ide using Windows?
Specially when you left your bluetooth serial ports enabled?, when starting or clicking on "TOOLS" menu like you can see here?:
http://screencast.com/t/aBsiowgaA3
After a while playing with the Java code of the IDE, I noticed (http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236880178) that the problem is a bit more hard to solve than fixing the Arduino IDE, even when I solved another small problem road to my final solution ::):
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236999449
You can download the "fixed" Arduino 0014 file here (replace this in the Arduino/lib/ path):
http://servicios.ried.cl/arduino/temp/pde_arduino-0015_fixed_2009-03-15.rar
Well, the problem resides in the rxtx serial library, library that Arduino IDE uses to enumerate the com ports and for communication with the board. This library is open source and multi platform: http://www.rxtx.org/
After hours of trying to find the problem, I isolated the problem: the initialization routines are guilty, because even if I don't call the enumeration (clicking on the TOOLS menu) from the Arduino IDE, the delays appear with any sketch upload or turning on the serial monitor.
The problem begin from this code, in the SerialImp.c file:
#ifndef WIN32
pid = getpid();
#else
char full_windows_name[80];
#endif /* WIN32 */
ENTER( "RXTXPort:testRead" );
#ifdef TRENT_IS_HERE_DEBUGGING_ENUMERATION
/* vmware lies about which ports are there causing irq conflicts */
/* this is for testing only */
if( !strcmp( name, "COM1" ) || !strcmp( name, "COM2") )
{
printf("%s is good\n",name);
sprintf( message, "testRead: %s is good!\n", name );
report( message );
(*env)->ReleaseStringUTFChars( env, tty_name, name );
return( JNI_TRUE );
}
(*env)->ReleaseStringUTFChars( env, tty_name, name );
return( JNI_FALSE );
#endif /* TRENT_IS_HERE_DEBUGGING_ENUMERATION */
#ifdef WIN32
strcpy( full_windows_name, DEVICEDIR );
strcat( full_windows_name, name );
ret = serial_test((char *) full_windows_name );
ret = serial_test((char *) name );
(*env)->ReleaseStringUTFChars( env, tty_name, name );
return(ret);
#endif /* WIN32 *
For each com port, we call "serial_test((char *) full_windows_name );" to check if we can open that port. In Windows each com port, device, etc is a file too (like in Unix, but Windows does not allow us to see this directly using a "class-device" approach, not a file-based one), ports as any other device are part of the "//./" namespace, for example "//./COM12" is the path for my LOCALHOST "." COM12 port. If the system can open this port/file, I will treat this port as valid, in the termios.c file:
unsigned long *hcomm;
hcomm = CreateFile( filename, GENERIC_READ |GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );
if ( hcomm == INVALID_HANDLE_VALUE )
{
if (GetLastError() == ERROR_ACCESS_DENIED)
{
ret = 1;
}
else
{
ret = 0;
}
}
else
{
ret = 1;
}
CloseHandle( hcomm );
Opening a file... yeah right but there is a small issue with this method. We want to check a lot of port quicky (each time that the Arduino/Tool menu is shown, uploaded a sketch, etc) so we need a non blocking operation, something like Synchronous vs Asynchronous (Synchronous and Asynchronous I/O - Win32 apps | Microsoft Learn), but for this task CreateFile is very buggy. It delays if the "file" does not respond until a timeout, so if my bluetooth dongle is connected and there are some virtual bt com ports, the process is very laggy and time-consuming.
Thanks to EnumSerialPorts v1.02 - Enumerating Serial Ports - CodeProject I discovered another way to check ports. It is only for Windows NT, so we need to keep the compatibility backwards. Even when the new function is a lot faster, its very dirty (not as the old solution) because to keep the compatibility I just overwrite the "serial_test" function, and this function only works for one port at once. But in fact, using the QueryDosDevice API (for NT) I have the full list of devices at once, not one by one (so in the future the next release of this rxtx library will be a lot quicker).
Here is the brand-new ultra fast serial_test ;):
/*----------------------------------------------------------
serial_test
accept: filename to test
perform:
return: 1 on success 0 on failure
exceptions:
win32api: CreateFile CloseHandle
comments: if the file opens it should be ok.
----------------------------------------------------------*/
int serial_test( char * filename )
{
int ret = 0;
// Getting the Windows Version
OSVERSIONINFO osvi;
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
BOOL bGetVer = GetVersionEx(&osvi);
// Using the QueryDosDevice API (on NT)
if (bGetVer && (osvi.dwPlatformId == VER_PLATFORM_WIN32_NT))
{
// This solution is based on http://www.codeproject.com/KB/system/enumports.aspx
TCHAR szDevices[65535];
DWORD dwChars = QueryDosDevice(NULL, szDevices, 65535);
if (dwChars)
{
int i=0;
for (;;)
{
//Get the current device name
char* pszCurrentDevice = &szDevices[i];
if (strlen(pszCurrentDevice) > 3 && strcmp(pszCurrentDevice,filename)==0)
{
ret = 1;
break;
}
// Go to next NULL character
while(szDevices[i] != '\0')
i++;
// Bump pointer to the next string
i++;
// The list is double-NULL terminated, so if the character is
// now NULL, we're at the end
if (szDevices[i] == '\0')
break;
}
}
}
else
{
// Buggy way to test if we can open the comport (on Win9x)
unsigned long *hcomm;
hcomm = CreateFile( filename, GENERIC_READ |GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0 );
if ( hcomm == INVALID_HANDLE_VALUE )
{
if (GetLastError() == ERROR_ACCESS_DENIED)
{
ret = 1;
}
else
{
ret = 0;
}
}
else
{
ret = 1;
}
CloseHandle( hcomm );
}
return(ret);
}
And the new and fixed compiled library is here (for all those have problems with delays and slowdowns in their arduino IDE, startup, uploading or displaying the TOOLS menu, any build, just replace the file "rxtxSerial.dll")
http://servicios.ried.cl/arduino/temp/rxtxSerial-2.2_fixed_2009-03-17.rar
Hope it helps for your problem/ or as experience to solve other problems. The key is a whole night, Pepsi and reading the README files!