USB secrecy is going to drive me insane.
AdVirMachina
Posts: 6
All, I've been through the postings here and on several other sites and I can't find (or don't know how to look) for some information on using a TTL-232R-3v3 USB to TTL cable to make my Propeller act as a USB device. I connect the cable and my PC creates a VCP. I can enumerate the device with D2XXX. So, I know the cable works. What I don't know is what do I have to do within the Propeller proper to have it respond correctly to being manipulated by the D2XXX .DLL? The vast majority of the documentation I've found keeps talking about using the VCP. I am trying to create an embedded controller solution to handle a PixelNet data stream. The program I will use to drive is opens USB devices using D2XXX. So, I am flat stuck with this model. Any ideas or clues?
The FTDI documentation is probably the worse source for what I should be doing. It focuses on the PC side of the conversation and not the TTL side. I don't know if I am supposed to be sampling TX/RX, looking for CTS or RTS to change states or what.
Thanks.
The FTDI documentation is probably the worse source for what I should be doing. It focuses on the PC side of the conversation and not the TTL side. I don't know if I am supposed to be sampling TX/RX, looking for CTS or RTS to change states or what.
Thanks.
Comments
On the computer side, you just treat it as a serial port...
There are fancier ways to use the FT232RL to connect to the Prop, but this is the most common and simplest way.
You just open the port, setup the parameters and send and receive data.
On the Propeller side you just send serial data to pin 30 and read it on pin31 using the baud rate and such that the PC setup.
The only problem I have is if the code has a problem before the port is closed, then I cannot open it again. I am forced to unplug the USB cable and plug it back in.
Bean
Have you written any serial code before ?
A good place to start is with simple loop-back (TX connects to RX) and check you can read what you send.
Next, you can work with two serial ports, to have one emulate what your remote end will do, and the PC host runs as normal.
This can be two separate programs.
For example, if the USB side of the cable presents a low speed endpoint, does the Propeller have to read the TTL side (tx/rx_ at 1 mbs? If so, is that framed by some specific timing sequence? Or, is it just sampled based on clock ticks? Or, am I over thinking this entire thing?
See
http://en.wikipedia.org/wiki/Virtual_serial_port
The idea of VCP(virtual Com Port) is it looks just like a serial port.
That means this call in FreeBasic will Open Com12, with 38400 baud and handshakes
(just like you'd expect for decades)
If Open Com ("com12:38400,n,8,1,cs100,ds100 bin" For Binary As #1)try
http://en.wikipedia.org/wiki/Asynchronous_serial_communication
There are buffers in all USB-Serial devices, if your unit is merely going to echo on request, of a known size, then you may be able to dispense with HW handshakes.
The baud rate matters less than it used to, but it does need to match your remote HW.
There is a function FT_SetBaudRate in the DLL.
If you don't have the baud rate set properly how can you expect to send and receive data on the MCU side ???
All of the comm settings ARE for the MCU side, the PC side all works through the DLL. It doesn't care what the baud rate or anything is.
The PC side is the "smart" end, the MCU side is the "dumb" end. You need to tell the FTDI chip what to expect at the MCU side.
I truly think you are making this a lot harder than it really is...
Here is how I open the port in VBA
Dim FT_Handle As Long Dim FT_Status As Long Function IO_Init() As Long FT_Status = FT_Open(0, FT_Handle) If FT_Status = FT_OK Then FT_SetBaudRate FT_Handle, 9600 FT_SetFlowControl FT_Handle, FT_FLOW_NONE, 0, 0 FT_SetDataCharacteristics FT_Handle, 8, FT_STOP_BITS_1, FT_PARITY_NONE ' Set DTR (DTR high to low causes propeller board to reset) FT_SetDtr FT_Handle End If IO_Init = FT_Status End FunctionBeanThanks! I went back and ran a dependency checker against the .EXE I'm dealing with and bigger than life, FT_SetBaudRate. So, something obviously has been miscommunicated between myself and this other developer. Add on top on of that the thickness of my skull, and well, you can see the confusion in action!
So, I need to simply run a half duplex (it's receive only on the MCU side) 1 mb serial routine. Correct?
If "1 mb" is 1 MegaBaud then make sure the propeller object you use can handle that speed.
Bean
I mean 1 megabits per second. And, I'm aware that's going to be pretty difficult to achieve. Any suggestions?
1.5Mbaud is not too hard to do on the propeller. I don't know if any of the objects support it, but with PASM it can be done. I think I used 2 stop bits to give the code time to store the values.
That would be 1.5M / 11 * 8 = 1.09M bits/second.
More the issue is can the propeller process the data fast enough ? What are you doing with the received data ?
Bean
IIRC, there are serial drivers in the OBEX that can handle 1Mbps - can't remember their names of hand.
That idle time during the stop bits is exactly what I was going to target for storing to the Hub. As far as what the data is for, I am going to use that information to drive a 16x32 LED panel from Adafruit. I am not looking for video speed, I am going to use it to replace a four color wheel for our family's aluminum Christmas Tree.I'm going to drive the color stream from my PC with HLS. I only get 20 frames of 4097 bytes a second (1 marker byte and 4096 bytes of RGB). To be honest, I could probably get away with 10 frames a second for this particular application.
Mike,
Thanks for the heads up. I'll look around for that article.
The FS FTDI parts struggle to sustain high baud send, they start to insert extra stop bits at the highest speeds.
( so the baud is correct, but the bytes/sec is less than you might expect)
To hit 1.5MBd sustained, you will need a HS FT232H / FT2232H
For Baud choice, the newer FS parts have a virtual Baud clock of 24MHz and the HS parts have a virtual baud clock of 96MHz, so that gives you some flexibility on the Baud choice trade off.
eg the Prop has 20Mhz SW granularity, (80Mhz @ start edge) so one solution is
1.3333' Mbd, for /15 on Prop and /18 in FT232
( also 1Mbd and 800kbd etc )
I am receiving only, so I should be alright. I'm not following what you are saying about the Prop having a 20mhz granularity. If I've done my math right, I should be spending more time in waitcnt than actually reading the bit. Especially if I am dealing with COG RAM for the temporary storage. Am I missing something?
WAITPNE would typically be used for Start-edge sync, which can resolve to 12.5ns.
It is a good idea to check the start-bit is valid, 1/4~1/2 bit time later, to give noise immunity.
From there, you do not have to use WAITCNT for bit-pacing - since you have to sample/shift/store anyway, you can just use the 20MHz opcode rate (80MHz/4) for sample-spacing, and the highest baud rates will likely do this.
( avoids the housekeeping delays, and there is an effective Min-valid WAITCNT time)
As already mentioned, 2 stop bits helps give time between bytes, for a higher baud choice.
SW pacing does constrain the baud-choices a little, but the numbers I gave above, show it is not much of a restriction.
( ie you can choose 1.3333' Mbd / 1Mbd / 800kbd etc with opcode timing, and a FT232 device)