I'm using an FT232RL to interface to the UART on a 1284P, I'm not using a bootloader so I don't feel I need to use the reset pin from the 232RL to reset the Atmega. The below is my schematic, how I intend to include the 232RL in my design.
Looking around, it seems 5V is the correct voltage level for the Atmega UARTS - correct? The datasheet says connect VCCIO to VCC to drive out at 5V TTL.
I do not need to use the CTS and RTS pins for handshaking do I? I'm not even sure what handshaking is, the 232RL datasheet just talks about it in it's 232RL to MCU example. Are the RX & TX pins enough by themselves for the chip to talk to the Atmega?
I'm using an FT232RL to interface to the UART on a 1284P, I'm not using a bootloader so I don't feel I need to use the reset pin from the 232RL to reset the Atmega. The below is my schematic, how I intend to include the 232RL in my design.
Looking around, it seems 5V is the correct voltage level for the Atmega UARTS - correct? The datasheet says connect VCCIO to VCC to drive out at 5V TTL.
Correct. If however you ever have one of the arduino type boards that operates with a Vcc of 3.3vdc then you would connect VCCIO to the 3v3out pin on the FTDI.
I do not need to use the CTS and RTS pins for handshaking do I? I'm not even sure what handshaking is, the 232RL datasheet just talks about it in it's 232RL to MCU example. Are the RX & TX pins enough by themselves for the chip to talk to the Atmega?
Yes, no handshaking signals need wiring to anything for the FTDI to operate. Lefty
Correct. If however you ever have one of the arduino type boards that operates with a Vcc of 3.3vdc then you would connect VCCIO to the 3v3out pin on the FTDI.
Thanks for this - however, this is being embedded in a final design PCB, so will not change. I'll keep that in mind for the future however!
I see, the datasheet shows no pull up on the reset line to 5V, and the pin descriptor says it is not required - leave unconnected or pulled up to 5V. However - I shall trust your experience.
No resistor on the pull up? Is the reset line high impedance in itself then?
That cap, C10, combined with the reset pull up circuit, is the decoupling cap for the power pins yes - not actually anything to do with the reset circuit in itself?
I don't see in the datasheet that it says the Reset is actually pulled up, but it does say in several places that if not used, the pin may be left open or be connected to Vcc. I'm with Graynomad, no floating inputs, especially control signals.
Just a thought, the 5V and GND shown on my schematic is not the 5V supply from the USB port, but rather 5V from the same regulator that powers all over 5V devices on the board.
Not using the 5v supply from the USB cable itself shouldn't be a problem should it?
Also be aware that your Tx pin may actually power up the FTDI chip depending on how it is constructed. IE if the FT232 has ESD protection diodes a logic high on the FT chip's Rx can try to power up the chip.
I don't know if this is the case with this chip, but I've just designed it into something in a similar way to what you are doing and I've added some circuitry to stop that.
The other thing to do is make sure your processor's Tx pin is tristate when the USB is not plugged in, if you can know that.
Also be aware that your Tx pin may actually power up the FTDI chip depending on how it is constructed.
That's not a problem - I'm not sleeping the '232 - just leaving it powered up the whole time.
The other thing to do is make sure your processor's Tx pin is tristate when the USB is not plugged in, if you can know that.
Why is this? Do both RX & TX go high when USB is unplugged? I know previously I've seen 1k series resistors on the RX and TX lines, but I believe the 232RL has internal series resistors?
It's the TX of the processors that is a problem. It will happily power the 232 IF it has ESD diodes (I don't know if it does or not). On the Arduinos I assume the 1k resistors pretty much solves the problem.
I always thought the 1Ks were to limit the FT232 to 5mA of drive current and to let the Arduino or external devices overdrive that if the pins were used for other purposes.
Yes I think that is the case, I suppose a nice side affect may be that when the USB is not plugged in it helps with the above issue, if indeed it is an issue with this particular chip, I know it is with most.