Controlling COM Port Generation

Support Wixel
1

Hello,

I have a situation where I use Wixels as part of a solution. I purchase wixels every time someone wants one of these systems. However, each time I load my program onto a Wixel it generates a new COM Port on my computer. I’m up to COM56 now. I thought I could simply delete the COM Ports from the computer but that has proven to be more of a challange then I would have thought.

Does anyone know how I can do one of the following?

1.) Modify my program so that that Wixels do not create a COM port.
2.) Delete old COM Ports from a Windows 7 system

Thanks in Advance.

Tim

2

Hello, Tim.

You could remove all of the USB-related code from your Wixel app. That will get rid of the COM port, but will make it harder to get the Wixel into bootloader mode.

Another idea is to change your Wixel app so that the app reports the same serial number to the computer no matter which Wixel it is running on. That way Windows would not be able to distinguish the different Wixels and would let them each have the same COM port number (as long as they are not plugged in at the same time). That will probably make it harder to use our Wixel bootloading software though.

Unfortunately, I am not sure how Windows assigns COM port numbers and I do not know any way to affect its behavior.

–David

3

Hi David,

Thanks for the response… So where would I begin to look for this comment?

“Another idea is to change your Wixel app so that the app reports the same serial number to the computer no matter which Wixel it is running on.”

Is there some place in the code where you can see what serial number is being sent to the computer?

Tim

4

The following lines in usb_cdc_acm.c define the string descriptors. The last one in the array is the serial number. The symbol “serialNumberStringDescriptor” actually points to a location in the Wixel’s bootloader that holds the serial number of the Wixel. You could change that spot in the array to refer to some other string descriptor, after defining it above.

uint8 CODE usbStringDescriptorCount = 4;
DEFINE_STRING_DESCRIPTOR(languages, 1, USB_LANGUAGE_EN_US)
DEFINE_STRING_DESCRIPTOR(manufacturer, 18, 'P','o','l','o','l','u',' ','C','o','r','p','o','r','a','t','i','o','n')
DEFINE_STRING_DESCRIPTOR(product, 5, 'W','i','x','e','l')
uint16 CODE * CODE usbStringDescriptors[] = { languages, manufacturer, product, serialNumberStringDescriptor };

–David

5

Thanks David,

I’ll poke around and see what I can figure out. Thanks for the tip.

Tim

–

6

TRStone_00…

I’d appreciate what you learn doing this, and I’ll poke around too because I have a similar concern. Although Polulu recommends not using the wixel directly in a final product app, it seems most sensible to at least test market a product using the wixel building block “as is” before attempting to duplicate its functionality, and so I’m in the same boat. I envision many dozens of wixels in my solution, and I’m stuck with windows XP for at least the coming year or so. That means in addition to adding unending com ports, I have to go through the set up time to re-install drivers every time I plug in a new wixel. That is simply NOT scalable!

Perhaps if Polulu tests this proposed solution, they could retain some product control by assigning certain strings to designers in this situation. That might also avoid conflicts, so that given fixed serial numbers are at least linked to a registered product database? Just a thought.

7

OK, Dave’s suggestion has merit, but its only a partial solution, and I’d still recommend Polulu offer some guidelines here for folks like us doing things this, who need to test market a product with the wixel “as is”.

In this lines of code Dave mentioned, in the file called usb_cdc_acm.c within the SDK, this example replaces the serialNumberStringDescriptor string with a hard coded hex serial number “01020304”, without disturbing the original “serialNumberStringDescriptor” aggregate.

DEFINE_STRING_DESCRIPTOR(languages, 1, USB_LANGUAGE_EN_US)
DEFINE_STRING_DESCRIPTOR(manufacturer, 18, ‘P’,‘o’,‘l’,‘o’,‘l’,‘u’,’ ',‘C’,‘o’,‘r’,‘p’,‘o’,‘r’,‘a’,‘t’,‘i’,‘o’,‘n’)
DEFINE_STRING_DESCRIPTOR(product, 5, ‘W’,‘i’,‘x’,‘e’,‘l’)
DEFINE_STRING_DESCRIPTOR(mySerial, 8, ‘0’,‘1’,‘0’,‘2’,‘0’,‘3’,‘0’,‘4’)
//uint16 CODE * CODE usbStringDescriptors[] = { languages, manufacturer, product, serialNumberStringDescriptor };
uint16 CODE * CODE usbStringDescriptors[] = { languages, manufacturer, product, mySerial };

Upon recompiling my project and uploading it to a wixel, it once again triggers the typical “new hardware found” which again assigns a new com port, for the new wixel whose s/n appears to be “01020304”. Now…, anytime I load this same code into another wixel and plug it into the test PC, it immediately comes up as that same serial number, and hence same serial port. So presumably, it should be possible to re-point that “mySerial” to some other source within the project.

But this only partially solves the problem and as Dave mentioned creates others. For one thing, you still have to plug in your new wixels somewhere to download your project code, built with the modified SDK. So we’re still back to needing to delete all USB serial port references on one machine or another, to avoid serial ports endlessly piling up. Second, there no way to plug in two identical wixels simultaneously.

Another little gotcha is that at least for me, I’d like to have some way of knowing what the actual serial number, even if its no longer reported to the USB, to have some control over the product. Wouldn’t you want to know if someone is making unauthorized clones? Even if I had to resort to hard coding it would be nice to have some way to read the serial number and compare it to some coded reference. I’m probably am not understanding the “serialNumberStringDescriptor” aggregate because even before this experiment I tried displaying what it pointed to in a USB debug message (through the simulated com port) and it always was “00000000”.

uint8 XDATA report[10];
uint8 reportLength =0;
reportLength = sprintf(report, “%-8.8s”, serialNumberStringDescriptor);
if (usbComTxAvailable() >= reportLength)
usbComTxSend(report, reportLength);

// result is always “00000000”

8

OK well, big foot in mouth here, and now I’m not sure if this is very useful at all. First, my bad for not realizing that you can see the true serial number anytime, in the 4 byte array called “serialNumber[4]” (DUH!!!). Its in reverse byte order by the way in case you need to display it.

But the bigger problem is that substituting your own serial number in the “usb_cdc_acm.c” file is only effective while the app is running. As soon as you stop the application, the boot loader’s USB initialization kicks in, so the PC again sees a new serial number (the original), and will want to install a new serial port.

So unless Polulu is willing to offer or license custom versions of its boot loader, there’s not much more we can do on this level of discussion to remedy the problem.

9

Hello. The Wixel USB Bootloader does not use a COM port. Yes, Windows will need to do some initialization to set up drivers for the new Wixel bootloader. It will add some entries to the registry. In Windows XP you will need to click through the Found New Hardware Wizard. However, the bootloader does not use a COM port so it will not take a new COM port number.

The Wixels we ship only have the bootloader on them, so there is no COM port to worry about with new Wixels.

–David

10

I would also like to point out that your customers will probably appreciate it if the Wixels have unique serial numbers, and I have not actually heard of anyone having trouble because of ridiculously high COM port numbers. I would be interested to know if there is actually a problem with really high COM port numbers, so I would suggest that either Tim or PeterPan just let it happen and share the results with us.

Another alternative is get a Linux machine for programming the Wixels.

PeterPan: What makes you say that “Polulu recommends not using the wixel directly in a final product”?

–David

11

Peter Pan & David,

You both make good points. I appreciate the foot work. I do understand the COM port is not created by the bootloader. And that it is in fact related to the Serial USB connection.

I actually do not need to have USB service at all… And by leaving it out the COM port wil not be created. Only downside is that the utility will not longer see the Wixel for loading any updates. But that said, I could make a simple way to trigger bootloader mode with the P-2_2 pin jumper.

This may work for me but for someone who’s solution “NEEDS” serial communication they are still out of luck.

There is merit to not wanting to load my computer up with COM ports. If not for any reason, it bugs me… I just now purchased 20 new wixels for a large order. I really do not want to have the “Tracks” of these wixels on my computer just because I want to load the program.

I appreciate the support from the site and from other members that share my concerns.

Thank You all for your help.

Tim

12

David,

I haven’t tried to find the limit with XP, but at one point on one version of Windows or another (possibly 2000) I thought there was a 256 max limit on com ports. But for me part of this issue was the hope I could avoid the long “re-install” that happens every time I plug in a new wixel under XP. I know you pointed out this doesn’t happen with windows 7, but I don’t have any machines set up with that OS yet.

But you also asked why I believed Polulu recommended against direct wixel usage in a product. Probably the main reason was this statement on page 7 of the Wixel user guide. If this statement is no longer true, and Polulu is willing to work with designers wishing to integrate Wixels in their products, I for one would much rather do so by mutual agreement.