Is it possible to use a bus pirate to interface with a reprap motherboard?
(see http://objects.reprap.org/wiki/Mendel_U ... _connector (http://objects.reprap.org/wiki/Mendel_USB_and_power_connector) )
As you probably noticed that one wants RTS and CTS but bus pirate uart guide only mentions RX/TX
P.S. I have a v2.go if it makes any difference
Not in the current firmware, but the UART does have RTS and CTS abilities that can be placed on the extra pins, and the RTS and CTS pins of the FTDI chip are routed to the PIC.
Ideally, how would you use it? I'm guessing you plan to use it as a transparent UART bridge with the riprap. That's awesome! We'd need to copy the state of the RTS and CTS pins on the FTDI232R chip in this setup because there's no other way to send control signals. That shouldn't be hard.
If you just need it for the diagnostic terminal mode, then maybe you can use the AUX pin to manipulate the flow control from the riprap. We could also add flow control that mimics the state of the uart control commands ([=open, ]=closed), or just implement it fully in hardware (transparent to user).
Let me know what you're thinking, I'd like to add this feature. Thanks for the suggestion.
Glad to hear that you're inspired! I'm just a newbie asking silly questions :D
I'm putting together a reprap and noticed that I don't have a USB-to-TTL converter to get my computer talking to it. Their recommended method is UM232R which is a breakout for FT232R[L]. And then I realized that BP has the same chip and ...one thing led to another ;)
Anyway, I'm just starting to play with BP so I don't know what it can do yet. "Transparent UART bridge" sounds like what I need - not a debugging mode but just letting the pc talk to the chip directly.
I added macro 3 to the UART mode in the 3.3-nightly available here:
http://code.google.com/p/the-bus-pirate ... ghtly/BPv3 (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v3-nightly/BPv3)
(I'm only releasing v1a and v3 firmware now, please use the v3 firmware with your v2go hardware, it should work fine.)
It simply mirrors the input and output flow control signals between the FTDI chip and the external circuit. Please let me know if you have a chance to test it.
CTS is on the CS pin (PIC input from external circuit is passed to FTDI chip)
RTS is on the CLOCK pin (PIC output mirrors output from FTDI chip)
I'd really like to have a picture of the Bus Pirate controlling a rip rap if you get this going, it would be a great example use for the blog.
Ran a quick test earlier today -- no go yet.
Most likely just confused the TX/RX pins
Do I want the default options for inverted signal and HiZ for 1?
It depends on the protocol. Probably not an inverted signal. HiZ should only be used if you're also using the pull-up resistors to interface at at custom voltage (probably not).
So far it's not working :(
The "proper" connector is here: http://objects.reprap.org/wiki/Mendel_U ... _connector (http://objects.reprap.org/wiki/Mendel_USB_and_power_connector)
Looks from their config like it's bus-powered mode and from their TTL cable description, it's 5V
What do you make of VCC there? Is it input to FT232RL or output from it to the remote device?
I think there's a chance I already burned out the motherboard by connecting the pins the wrong way :(
I doubt you could have burned it out, the Bus Pirate only operates at 3.3volts. Looking at the Sauguino version schematic I had a few thoughts. First, I don't think flow control is used. I don't see pin connections for it. Second, yes, it looks like the Sanguino board is powered by the USB converter (maybe there's a jumper on the board?). You can supply the power with the Bus Pirate's 5volt supply. Finally, I think the Bus Pirate will interface the AVR chip UART fine at 3.3volts. I just did some work with Arduino and the datasheet for the chip says high level is 3.0volt minimum, the Bus Pirate has 3.3volt high so it should be fine. The Bus Pirate also has 5volt tolerant pins, so it won't get hurt by the 5volt AVR chip.
Check the speed the reprap expects, it might be changing the FTDI chip speed on the Bus Pirate. Use something like portmon (windows) to watch what the reprap software does when it configures the port. If you paste that here I can help figure out the settings it expects.
Check the UART connections, maybe they're reversed. Make sure RX->TX, TX->RX.
Happy new year!
I think I have everything hooked up correctly right now, but still nothing.
I'm on linux -- and this is the first time when I found it's harder to sniff a port than in windows.
Says here (http://builders.reprap.org/2009/04/ligh ... nting.html (http://builders.reprap.org/2009/04/lightweight-and-fast-g-code-printing.html)) that the baud is 19200 - I've tried it with no luck.
Ok, I'd guess the software you're using is changing the FTDI chip speed to 19200 (the USB->serial chip for the PIC on the Bus Pirate). The Bus Pirate expects the FTDI chip to talk 115200, so you get nothing.
The quickest test is to change the Bus Pirate to 19200, but maybe you can increase the reprap software speed to 115200.
In the Bus Pirate terminal press B to change the baud rate. Select 19200, then adjust your terminal speed and press space.
Now start the UART bridge at 19200 and close the terminal.
Hopefully that will help.
Ideally for this application there would be a pass-through mode to the FTDI chip.. but that's probably too much trouble
I tried setting the baud rate for bus pirate as well as uart but still nothing
Took a closer look at the pins:
apparently, VCC isn't connected and CTS is shorted to ground ...
(see http://www.flickr.com/photos/hoeken/3527845382/sizes/o/ (http://www.flickr.com/photos/hoeken/3527845382/sizes/o/) )
but still doesn't seem to matter
What do you mean by pass-through mode? That the PIC communicates with both UARTs at the same speed? I can do that, no problem.
I have no other ideas about the reprap though, sorry. I hope you get it working. I got help right away in the reprap IRC channel, maybe someone there can help.
Are you trying still using the bridge with flow control? If so, maybe try the bridge without.
Is there any sort of data you'd expect to see from the device in a terminal?
Finally got everything to work. Apparently it wants RTS pin only for auto-reset (when new firmware is flashed).
But the bigger problem was that the firmware it came with was made for MakerBot Cupcake CNC, not RepRap (apparently they use different firmware even though Cupcake is derivative from RepRap). Anyway, I flashed the bootloader through ICSP with BP (as described here (http://http://hintshop.ludvig.co.nz/show/buspirate-avr-programming)) and then flashed the main firmware using P4 serial/TTL adapter (http://http://www.1strecon.org/TheShoppe/pa/index.shtml#P4) with DTR pin (apparently that works with autoreset perfectly).
What's interesting is that P4 doesn't need to know the baud rate, it either auto-switches or forwards everything as-is... Does BP in UART passthrough mode really need to set the baud/etc?
It looks like the P4 is just a voltage level (13volt swing, RS232->TTL, MAX202) converter, it's not actually doing anything with the baud rate, USB, etc. It just converts voltage levels. On the page you link they use it with a USB->serial adapter, when the USB->serial adapter port is opened on the PC it automatically adjusts the speed.
Bus Pirate uart pass-through mode involves two 'serial ports' (UARTs) and you need to set them both. If your PC program sets a custom speed on the Bus Pirate's FTDI chip, then you need to adjust the terminal speed (menu B) or the user-side UART or the Bus Pirate won't match the speed of the FTDI chip set by the PC program. You need to set the speed in pass-through mode or it won't match your target.