Using the FT232R after startup

Seairth

Peter Jakacki wrote: »

...but why can't you put a switch or jumper in between the NPN and reset to disable it unless you need it?

Duane's particular needs aside, this seems like such a straight forward approach.

Actually, I'm curious about taking this a little further. I'd like to be able to detect when the USB is actually plugged in, so that I can conditionally start the FDS (and associated code). Similarly, I need to be able to shut the FDS (and associated code) back down when the USB is unplugged. But I'm not seeing anything else on the FT232R that simply indicates "USB connected/disconnected". Suggestions?

To reiterate, I want the following behavior:

• When the switch is set to PGM (DTR# connected to RESn), the circuit behaves just like it does on the Propeller Demo Board.
• When the switch is set to RUN (DTR# is disconnected from RESn), the connection status of the USB is conveyed to an input on the Propeller.

Note: I don't want to detect a USB connect/disconnect event. I just want to be able to poll a pin and see if the USB is connected.

The overall intent here is to have the device I'm designing to work in two basic modes:

1. Record data (in particular, the output of the MEMSIC 2125) to SPI Flash (I've decided to not go the SD card route). Similar to Peter's suggestion in another thread, I intend to use a sentinel value to indicate the start of each recording session.
2. When USB is connected, use the serial connection download the recorded data (and clear the flash memory).

And, while I am at it, does anyone have experience with using the FT232 in conjunction with a USB charging circuit? In the long run, I intend to run my project off a rechargeable battery. It would be nice to use the same USB jack to both charge and download. In this case, it would be nice if the use of a USB wall wart didn't trigger the Propeller to think that USB was connected.

Phil Pilgrim (PhiPi)

You could use one of the status pins, like /PWREN to tell if the USB is connected. But that will not tell you whether anyone is listening on the other end. It might be better if the listener program acted as master and sent prompts to the Prop for data.

-Phil

Seairth

Phil Pilgrim (PhiPi) wrote: »

You could use one of the status pins, like /PWREN to tell if the USB is connected. But that will not tell you whether anyone is listening on the other end. It might be better if the listener program acted as master and sent prompts to the Prop for data.

That's my intent. The device will be commanded by the master. I just want to know when I can start up the serial driver and associated code, as well as shut it back down again. Most of the time, the device will not be plugged into USB, so I want to minimize power consumption by not running any of the USB-related code.

I'll look at /PWREN more closely. I thought that was a control signal from the MCU, so i ignored it when I was reading through the documentation.

Tracy Allen

To work with what you've got, assuming the reset is the standard transistor circuit,

dira[2]~~     ' LED on p2
repeat
    outa[2]:=ina[31]   ' LED follows USB connection

For best results, leave tx (pin 30) as an input or low output so that it can't supply parasite power to the FT chip.

Another simple option is a 1MΩ resistor from the USB 5V line to a prop input pin. Detect when the 5V is present.

Tracy Allen

The FT231X is more modern than the FT232R and is more capable as a compliant battery charger. As with the FT232, the pwren# signal goes low once the usb port is enumerated and will allow the requested current above 100mA and up to 500mA. The FT231X adds the BCD# signal (battery charger detect) which goes low when it detects a compliant battery charger (data lines shorted together). That pin can provide a signal to the microprocessor or it can pull down a resistor connected to a charger IC, to allow a higher charge rate. The FT231X data sheet includes more charger info and there is also an app note with design examples.

Seairth

Tracy Allen wrote: »

Another simple option is a 1MΩ resistor from the USB 5V line to a prop input pin. Detect when the 5V is present.

This would also happen when plugged into a USB wall wart, which I don't want.

Tracy Allen wrote: »

The FT231X is more modern than the FT232R and is more capable as a compliant battery charger. As with the FT232, the pwren# signal goes low once the usb port is enumerated and will allow the requested current above 100mA and up to 500mA. The FT231X adds the BCD# signal (battery charger detect) which goes low when it detects a compliant battery charger (data lines shorted together). That pin can provide a signal to the microprocessor or it can pull down a resistor connected to a charger IC, to allow a higher charge rate. The FT231X data sheet includes more charger info and there is also an app note with design examples.

I'll look into the FT231X instead. It sounds like the the PWREN# pin is what I need.

jmg

Seairth wrote: »

That's my intent. The device will be commanded by the master. I just want to know when I can start up the serial driver and associated code, as well as shut it back down again. Most of the time, the device will not be plugged into USB, so I want to minimize power consumption by not running any of the USB-related code.

I'll look at /PWREN more closely. I thought that was a control signal from the MCU, so i ignored it when I was reading through the documentation.

/PWREN does not signal Serial ready, so perhaps a handshake line is better for that ?
You might want to check the USB device disconnected-idle power, as that is likely to be significant -or, if you power that purely from USB, then the pins will likely float somewhat low on unplug. If they do not get below ~ 0.5V, you can get additional Icc in CMOS parts.
How low do you want to drive the Power ?

Seairth

For the first version of my project, I don't intend to use the power from the USB connection, except to power the FTxxx chip itself.

My primary concern right now is accurately detecting at the Propeller when USB is connected. For future purpose, I would like to be able to distinguish between a wall wart and a PC, so that I can conditionally run the FDS (and related) code.

Put another way, I was hoping to use the USB connection to switch my code between "recorder" mode and "playback" mode:

* Disconnected: recorder
* Connected (wall wart/ext battery) : recorder
* Connected (PC) : playback

The fact that I am focusing on the distinction between USB power vs USB data now (as opposed to later) is that I would prefer to not have to redesign that part of the circuit later on when I do add USB charging (or being able to run the device for an extended period off an external USB battery).

Tracy Allen

For your future purpose, it is the BCD# signal on the FT231X that you want. Combine that with the state of the prop rxd p31 to distinguish computer from dumb charger/external battery pack, so long as there isn't anything else that pulls up rxd.
rxd high, bcd# high = computer
rxd high, bcd# low = USB charger/battery pack
rxd low, bcd# low = neither
I do what you are suggesting all the time for data loggers and it works well. The debug port is active only if someone plugs in.

The FT231 has to be configured using the FT-PROG untility to assign the BCD# function to one of the CBUS pins. I use the LTC4054 3.7V LI-poly charger IC, reference FTDI app note AN-175. The charge current under various conditions of the USB port is set by current-sinking resistors from one pin of the '4054 to various pins of the FT231X.