at STEIM
- ATmega328 16Mhz 5V// to have more array space(buffering) for incoming wireless data
- D4(PD4) connects to tactile switch // configure mode
- D5(PD5) connects to CTS(active low) pin of FTDI // for hardware flow control
- MCP1700 volatage regulator // 250mA, enough for Xbee pro
- fits in Hammond enclosure(50x50x20mm)
D5 should have been connected to RTS pin, not CTS
How does RTS/CTS flow control work in an FTDI chip?
FTxxx RTS# pin is an output. It should be connected to the CTS# input pin of the device at the other end of the UART link.
If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.
If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.
RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.
FTxxx CTS# pin is an input. It should be connected to the RTS# outout pin of the device at the other end of the UART link.
If CTS# is logic 0 it is indicating the external device can accept more data, and the FTxxx will transmit on the TXD pin.
If CTS# is logic 1 it is indicating the external device cannot accept motre data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.
This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis.
Word to the wise. Not only do RS232 level shifting devices (e.g. MAX232) level shift, but they also invert the signal.
