by i-Bot » Mon Dec 27, 2010 12:51 pm
by i-Bot
Mon Dec 27, 2010 12:51 pm
The trick from Jon takes advantage of two key features of using the interface on the AVR rather than a USB interface.
The first as you identified is that he has full control over the receive path and the receive software. So he can either disable the receiver while transmiting, or discard the transmited bytes as they are received. With the UM232R there is buffering, so you only have the choice to discard the transmitted bytes. This is OK with your own software, but may not work with existing software.
The second feature of the AVR is the capability to tri-state the transmit output. This allows the dynamixels to safely drive the bus when they want to transmit. For the UM232R it appears the transmit is an output without tristate. Thus when the dynamixel sends the reply both the UM232R output (high) and the Dynamixel output (high with low pulses) are on the bus at the same time. It is likely the stronger low drive of the dynamixel will overide the UM232R, but not with reliable operation. One or other driver could get damaged, but that is not too likely.
This means a minimal UM232R interface must have a tristate buffer on the output, and preferably on the input too if you want to use standard software. The UM232R does bring out the /TXEN signal from the FTDI chip which can be used as the enable for a 74HC125 output buffer to control the transmit, and optionally a 74HC126 output buffer for the receive. These buffers are available in DIP packages and also in SMD as a single gate. If you are happy to use SMD, then the
http://www.fairchildsemi.com/ds/NC/NC7WZ241.pdf is a single TX/RX pair in one package as used on the USB2dynamixel. They can be powered from the 5V output of the UM232R.
If /TXEN output does not work it may be that you need to configure it on the UM232R using FTPROG.
The trick from Jon takes advantage of two key features of using the interface on the AVR rather than a USB interface.
The first as you identified is that he has full control over the receive path and the receive software. So he can either disable the receiver while transmiting, or discard the transmited bytes as they are received. With the UM232R there is buffering, so you only have the choice to discard the transmitted bytes. This is OK with your own software, but may not work with existing software.
The second feature of the AVR is the capability to tri-state the transmit output. This allows the dynamixels to safely drive the bus when they want to transmit. For the UM232R it appears the transmit is an output without tristate. Thus when the dynamixel sends the reply both the UM232R output (high) and the Dynamixel output (high with low pulses) are on the bus at the same time. It is likely the stronger low drive of the dynamixel will overide the UM232R, but not with reliable operation. One or other driver could get damaged, but that is not too likely.
This means a minimal UM232R interface must have a tristate buffer on the output, and preferably on the input too if you want to use standard software. The UM232R does bring out the /TXEN signal from the FTDI chip which can be used as the enable for a 74HC125 output buffer to control the transmit, and optionally a 74HC126 output buffer for the receive. These buffers are available in DIP packages and also in SMD as a single gate. If you are happy to use SMD, then the
http://www.fairchildsemi.com/ds/NC/NC7WZ241.pdf is a single TX/RX pair in one package as used on the USB2dynamixel. They can be powered from the 5V output of the UM232R.
If /TXEN output does not work it may be that you need to configure it on the UM232R using FTPROG.