I don't have your problems ;-)
And I too use 2 different Xtals, 6 and 20 MHz.

What do you mean "by the the MAX232 is on"? If there's no computer
connected to it, everything gets lost, wheter MAX232 in on or not.
Do you power the FT232 form the USB ?
Do you power the PIC from the USB ?
If so, do you use a FET to power the PIC ?
If not, you could use this FET to control the MCLR line.
AFAIK the settling time of the FT232 is mainly determined by the windows
operating system, establishing an USB connection.

Stef Mientki

Ian McLean wrote:
> Hi guys,
>
> I small but annoying problem with the FT232BM chip I am hoping someone has a
> clever solution too ...
>
> Unlike the MAX232 chip, the FT232BM is not "on" unless a USB connection is
> established with the chip.  This means that it misses the first couple of
> receive bytes and garbles the first couple of sent bytes when you first plug
> it in, assumably this is because the chip needs a little time to settle, the
> crystal to stabilise, etc, etc.  Everything starts working fine after the
> first few bytes.
>
> I realise I am probably exacerbating the issue by not using the same crystal
> for the PIC as for the FT USB chip, but I need to run my PIC at 20Mhz, and
> the USB chip requires 6MHz, so I am using two crystals.
>
> I have seen circuits where the DTR line from the USB chip is inverted and
> tied to MCLR on the PIC, holding the PIC in reset whenever there is not a
> USB cable plugged in, but this is not acceptable when you want to have the
> PIC running regardless of whether or not a USB cable is plugged in or not.
>
> What would be the best way to incorporate this settling time for the chip in
> a software based solution.  I could always tie the DTR or another suitable
> serial pin (maybe RTS or CTS for example) to another PIC pin and monitor the
> pin, not sending anything and just ignoring the receive buffer and clearing
> any overflows, etc., until that pin goes high, but I am short of PIC pins
> and would prefer to try and find a way that does not require such a pin
> connection.
>
> Any suggestions anyone ?
>
> Rgs
> Ian.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.