Shop OBEX P1 Docs P2 Docs Learn Events
FTDI driver == exploding computer — Parallax Forums

FTDI driver == exploding computer

Bobb FwedBobb Fwed Posts: 1,119
edited 2010-06-03 09:50 in Propeller 1
I have a small run of a product I am developing, each of the units has an FTDI chip on it (some of you may have helped me with that resent issue). The problem I am having has to do with the driver. Each time I plug in another unit to program it, another COM port is added to my computer. I am up to over 20 at the moment, but that is going to go way up really soon.

A few different options I imagine should be possible, but ease of implementation may vary.

First, I leave everything as is, and my computer one day blows up because I reached the limit of possible COM ports which appears to be 256. That won't take long, but until then this whole problem is only an annoyance. If this limit wasn't there, I could actually use the COM number to give each Propeller a unique identifier as I program them, but alas, no joy.
Second, an option in the driver (or a different driver) that would put all FTDI chips as a single COM (say COM3). This prevents me from using more than one FTDI chip at any one time, but currently that is not a problem.
Third, and probably already available, is just to go through and delete the COM's that I haven't used in a while (but I do not know the correct way to do this).

Any help/ideas?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Some of my objects:
MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2010-06-02 21:52
    It's not much help, but the topic has come up before and a solution was suggested, but I don't remember it nor do I have a link. AFAIK, this problem is unique to Windows. I've never seen it happen on the MacOS or Linux.
  • Erik FriesenErik Friesen Posts: 1,071
    edited 2010-06-02 22:43
    You'll have to do some legwork on FTDI's website. I believe you will need to create a custom inf. If I have it correct, enabling location ID's may be what you are looking for.
  • David CarrierDavid Carrier Posts: 294
    edited 2010-06-02 23:22
    Some programs have low com port limits hard coded in them, but Windows itself has a ridiculously high limit, if any at all. On our test machines we have gone over 4,096 ports with no problem. If you would like to reset your com port numbering, try this using utility: http://www.ftdichip.com/Resources/Utilities.htm#FTClean, then installing the drivers again.

    — David Carrier
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-06-02 23:32
    I believe, if you use FTDI's MPROG utility, you can assign the same serial number to every device, and the problem will go away. Of course, plugging two such devices in simultaneously may then cause a problem.

    -Phil
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2010-06-02 23:36
    David Carrier (Parallax) said...
    Some programs have low com port limits hard coded in them, but Windows itself has a ridiculously high limit, if any at all. On our test machines we have gone over 4,096 ports with no problem. If you would like to reset your com port numbering, try this using utility: http://www.ftdichip.com/Resources/Utilities.htm#FTClean, then installing the drivers again.

    — David Carrier

    Well, if this is true, maybe I won't have an issue and I can implement the unique identifier thing. I read on a few different websites that windows had the 256 limit, but maybe that was older operating systems. What version of windows does the your test machine have?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    April, 2008: when I discovered the answers to all my micro-computational-botherations!

    Some of my objects:
    MCP3X0X ADC Driver - Programmable Schmitt inputs, frequency reading, and more!
    Simple Propeller-based Database - Making life easier and more readable for all your EEPROM storage needs.
    String Manipulation Library - Don't allow strings to be the bane of the Propeller, bend them to your will!
    Fast Inter-Propeller Comm - Fast communication between two propellers (1.37MB/s @100MHz)!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-06-02 23:46
    There's actually another way to do it, but it's extremely involved and requires editing the registry. I set up the test machine that went to the MoBo manufacturer this way, but I don't remember the details. What you end up with is an assignment of a com port number to each USB port, rather than to the devices plugged into them. I got all the info to do this from the FTDI website. But I had to dig for it.

    -Phil
  • TimmooreTimmoore Posts: 1,031
    edited 2010-06-02 23:59
    one way to delete the ports is

    open up a command prompt (as administrator if needed)

    Set devmgr_show_nonpresent_devices=1
    devmgmt.msc

    view->show_hidden_devices

    then under com ports you will see all the com ports that are not plugged in at the moment and can delete them
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2010-06-03 01:31
    I never had this problem on Windows if I was using a Silabs chip as they all have the same serial number but I know the problem. My main O/S is Ubuntu (Mint actually) and these chips come up as USB0 no matter what. If I plug more than one in even with the same serial number it just allocates the second port as USB1 and so on. Brad's BST works really well on Ubuntu and I develop all my Prop stuff like this including production programming.

    My suggestion then is to load a small linux like PuppyLinux if not Mint into VirtualBox and assign the FTDI port to it. The virtual Linux environment just becomes another program like any other and you never have a problem finding the comport. Better still, just boot into Linux full-blown.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
  • WBA ConsultingWBA Consulting Posts: 2,935
    edited 2010-06-03 04:29
    Ran into the same problem a few years ago while programming Crossbow Motes that used the FT232RL. Windows does have a 256 limit, which we ran into after about 3 weeks of production. We used the FTClean utility to clear out all assigned com ports and start back over. We used this process for the first ~1k units then started programming the MSP430s directly via a gang programmer.

    You can also manually manipulate the com port assignments in device manager so that the com ports are numbered as you wish. I modified a setup that had four FTDI connected devices so that the com ports were in order in the same manner that the devices were physically located on the bench. This made it very easy to use since the test procedure required the operator to select different com ports during the test.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Andrew Williams
    WBA Consulting
    WBA-TH1M Sensirion SHT11 Module
    My Prop projects: Reverse Geo-Cache Box, Custom Metronome, Micro Plunge Logger
  • BradCBradC Posts: 2,601
    edited 2010-06-03 09:50
    I just adore the way the Mac does it.

    Windows allocates a new COM port for every new serial number (short sighted and ugly)

    Linux allocates the /dev/ttyUSBx in the order they are plugged in (pretty silly if you value persistence)

    OSX names each serial port with the serial number of the device /dev/tty.USB.xxxxx serialnumber. (really very elegant).

    One day I'll get around to writing a udev rule for Linux that makes it behave that way (it's not hard, I'm just lazy).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "Are you suggesting coconuts migrate?"
Sign In or Register to comment.