Musings on a slow USB standard
Dr_Acula
Posts: 5,484
There is something very convenient about the way USB has power as well as data and everything works so easily. So much better than RS232 and all the myriad of standards.
But the downside is that creating a USB host is not easy (I know something has been done recently with the propeller) and even if you do have a host, you then need to code a wide variety of drivers for devices.
So I have been pondering a "RS232 plus power" solution, with the propeller acting as the host. Some general ideas:
1) 4 wires - 5V, Tx, Rx, Gnd - like with USB.
2) Some sort of common plug where the cables are cheap. 10 way headers. SIL headers. S video. But I'm inclined towards cat5 using the 4 unused wires because the premade cables are so widely available.
3) Robust electrical connections so chips don't get zapped. All pins should be short circuit proof/miswire proof etc. Probably the RS232 voltage levels. But there might be an argument for TTL levels with a 1k series resistor.
4) A 'smart' hub with multiple I/O. Plug in a device and it should detect the current consumption of the device being plugged in, and then initiate a very simple handshaking protocol to determine the baud rate. Thus making RS232 more 'plug and play'.
If there are 4 wires including power, then it is very simple to think of an adapter board that converts this protocol to standard RS232 - just a RJ45 socket to a D9, and don't connect the 5V to anything.
Thus a subset of devices that can use this protocol includes all existing RS232 devices.
But then you can add another group of devices. I'm thinking of things like Arduino and Picaxe chips that might only have 100 lines of code in them, and might only be an 8 pin chip.
There could be a very simple protocol - plug in the Arduino/Picaxe, and the first thing the propeller hub does is send out a byte at a certain baud rate (try 1200 first). If there is a reply, then this becomes the baud rate. If no reply, then try other baud rates.
More complex protocols could experiment with higher and higher baud rates to get the fastest rate possible, much like fax machines do.
The Propeller could act as a smart hub. With a few handshakes, it would know what it is connected to. So a peripheral could ask "can I send this packet to device x", and could get back a reply "packet sent" or "no such device on the network".
I have a number of ideas where this could be useful, eg the propeller acting as a "mouse to serial" device, or "keyboard to serial", or "SD card to serial" or "ethernet to serial".
The hub could also act as a baud rate converter between two standard RS232 devices, and even as a way of interfacing to 'mystery' RS232 devices without having to get out the CRO.
I'm also thinking of how fast you could push the data rate, eg for a propeller based video driver like Baggers/Coley are making. If the peripheral is also a propeller, then there could be smarter handshaking at much faster baud rates.
Thoughts and ideas would be most appreciated!
But the downside is that creating a USB host is not easy (I know something has been done recently with the propeller) and even if you do have a host, you then need to code a wide variety of drivers for devices.
So I have been pondering a "RS232 plus power" solution, with the propeller acting as the host. Some general ideas:
1) 4 wires - 5V, Tx, Rx, Gnd - like with USB.
2) Some sort of common plug where the cables are cheap. 10 way headers. SIL headers. S video. But I'm inclined towards cat5 using the 4 unused wires because the premade cables are so widely available.
3) Robust electrical connections so chips don't get zapped. All pins should be short circuit proof/miswire proof etc. Probably the RS232 voltage levels. But there might be an argument for TTL levels with a 1k series resistor.
4) A 'smart' hub with multiple I/O. Plug in a device and it should detect the current consumption of the device being plugged in, and then initiate a very simple handshaking protocol to determine the baud rate. Thus making RS232 more 'plug and play'.
If there are 4 wires including power, then it is very simple to think of an adapter board that converts this protocol to standard RS232 - just a RJ45 socket to a D9, and don't connect the 5V to anything.
Thus a subset of devices that can use this protocol includes all existing RS232 devices.
But then you can add another group of devices. I'm thinking of things like Arduino and Picaxe chips that might only have 100 lines of code in them, and might only be an 8 pin chip.
There could be a very simple protocol - plug in the Arduino/Picaxe, and the first thing the propeller hub does is send out a byte at a certain baud rate (try 1200 first). If there is a reply, then this becomes the baud rate. If no reply, then try other baud rates.
More complex protocols could experiment with higher and higher baud rates to get the fastest rate possible, much like fax machines do.
The Propeller could act as a smart hub. With a few handshakes, it would know what it is connected to. So a peripheral could ask "can I send this packet to device x", and could get back a reply "packet sent" or "no such device on the network".
I have a number of ideas where this could be useful, eg the propeller acting as a "mouse to serial" device, or "keyboard to serial", or "SD card to serial" or "ethernet to serial".
The hub could also act as a baud rate converter between two standard RS232 devices, and even as a way of interfacing to 'mystery' RS232 devices without having to get out the CRO.
I'm also thinking of how fast you could push the data rate, eg for a propeller based video driver like Baggers/Coley are making. If the peripheral is also a propeller, then there could be smarter handshaking at much faster baud rates.
Thoughts and ideas would be most appreciated!
Comments
-Phil
The flat cable version can be hand crimped in seconds, unlike the fiddling sometimes needed with cat 5 cables. (hope thats not just my sticky fingers!)
See Post #33 on my thread http://forums.parallax.com/showthread.php?132769-Cluso-s-miniature-stackable-and-pluggable-boxable-propeller-boards-(1-quot-x1-quot-etc)
This has 5V, -D, +C, GND where
* -D is the USB -D pin; the Data pin for PS2, Data pin for I2C; RX (input)pin for serial; and connects to the lower prop pin
* +C is the USB +D pin; the Clock pin for PS2; Clock pin for I2C; TX (output) pin for serial; and connects to the higher prop pin
I can also use this (or multiple connectors) for a pair of prop pins.
From the prop pin pair, each pin has a series resistor (usually 150 ohm as this should work in most apps). Each then has a 10K that can be pulled up or down (pulled up for PS2 and I2C, pulled down for USB master, and nc for USB slave). A single 1K5 pulled up to 3V3 can be connected to either pin (USB slave LS=low speed when connected to -D, and FS-full speed when connected to +D/+C).
This gives me a small footprint ( and low profile) connector that can be used for a multitude of connections, with readily available cables and adapters.
I'm also thinking this would be generally used with short cables, much like USB is. So the voltage drop with thin wires would not matter for the supply volts. That leads to "small wires, small footprint".
In some ways the actual connector may not be important, and you could actually have all of the above. Just define what the pinout is whenever you use for each of these connectors. These all have advantages eg
RJ9 - the wires are very flexible and 4 core cable is as cheap as.
USB - everyone already probably has a cable. Just make the Gnd,Tx,Rx, 5V the same pins as USB?
And the servo standard - that is a great idea. You could use one 3 wire cable for one-way comms, and another 3 wire cable for duplex (which would parallel up the 5V and 0V which would be a good thing too).
I'm still in two minds about RS232 signal levels (-12V/+12V) vs lower voltage levels. I started off thinking RS232 levels were better, but it would add a max232 at both ends which sort of seems overkill for a picaxe to a propeller, or a propeller to a propeller.
Open-drain sounds interesting. How would that work - pull up to either 5V or 3V with a 10k, define 2V or more as "high". Maybe a 100R to 1k series resistor to protect against accidental shorts to 5V in the cable or device?
Let's see - if you had open drain, pulled up to 5V in the "hub" with 10k.
Peripheral devices running on 5V would be fine.
Peripheral devices running at 3V - they will be fine too because 10k is well under the current that the internal chip diodes can handle.
Actually, PhiPi, you might be onto something interesting there, because you could have a bi-directional link with 3 wires and each device could talk in turn, or if you needed a formal duplex link, you just have two of these. Adapters are easy too - eg two "three wire" cables to a 4 wire USB socket is a tiny PCB with just sockets. Ditto "3 wire" to RJ9.
So all these (and other standards) can be accommodated with a series of tiny PCBs.
Hmm - say you had a duplex link, and used two "3 wire" connectors, and you connected the tx and rx round the wrong way - the propeller could be smart enough to work out which it is receiving data on, and reconfigure itself.
I love this idea that there can be many plug standards.
Ok, what is the vibe on signal levels:
* +12V/-12V
* 5V TTL
*3V TTL
* Open drain, weak 10k pullup
-Tor
What sort of distances?
As I recall, USB is recommended maximum 5meters....
If this is just a protocol type of idea, then surely the 3v or 5v could be interchangeable... I mean provided both ends are running the same, then this same "standard coupling" could be used. As you say, the +12 -12 would involve additional hardware...
That raises an interesting point, as one of the benefits of USB is the 5V, which you can use to supply power. But what if both devices were 'equal' and both tried to supply power?
Or maybe keep it simple - eg a jumper that can be removed that disconnects the 5V which you would remove on one device.
Or it could be a bit smarter than that. I'm thinking of a current sense resistor (1 ohm?) in the 5V supply, and an op amp to convert to current to volts, then measure the current drawn. (maybe a prop can do that directly off the 1 ohm resistor?). A device is not detected until it draws a minimum current, so if both devices had 5V then no current would flow until you removed one of the jumpers (which then starts the handshaking).
The current detection part of USB is largely hidden from the user, but I gather there are chips that do this.
Aside: I just discovered that placing a 3 meter USB extention cable between my PC and Android phone has the effect of crashing the phone so badly it needs a battery out reboot to get going again.
Did I ever mention, I hate USB?
Oh no, I don't want to do that!
But I guess the aim is to try to take some of the good bits of USB and replicate it for microcontrollers.
But not every micro can act as a hub. Many of the picaxe chips for instance, 'hang' while waiting for serial data, so can't monitor more than one line at a time. On the other hand, the prop is ideally suited as a hub controller.
See the attached pdf.
At the very simplest level, for a single way serial link, it is just a 10k pullup and a 150R series resistor to protect the propeller pins from shorts etc.
Then we can add a current sense circuit to detect if a device has been connected. That starts up the handshaking to work out the baud rate.
And the hub might want the ability to reset a peripheral device in case it has hung, so there are a couple of transistors to do this. It isn't quite as sophisticated as the USB supply drivers but ought to suffice.
I put in three types of physical connectors - RJ9, USB and two 3wire servo headers.
I noticed something similar this week when using a prolific USB<>RS232 device at 460kbps, adding the 2m extended to the 1.5m adapter cable would cause the terminal program (PST / Teraterm / Realterm ) to hang after a few minutes. Perhaps non compliant cable or connections? Don't know, but highly reproducable.
Interesting ideas, Drac.
And yes, USB is complex.
In the old days (mid 80s) we went from complex synchronous comms to simple Async (often incorrectly referred to as RS232 because sync was also RS232). Now we have come full circle and use synchronous comms with very complex protocols on top of that. What happened to simplicity???
For the record, I wrote synchronous comms including 2780, 3270 bisync, SDLC (to IBM mainframes), etc, etc. Async was a walk in the park.
Use the same async data protocol as rs232 and rs485 uses.
Allow the use of 3.3V, 5V, and 20mA current loop signalling for full duplex.
Allow the use of 3.3V, 5V, 20mA current loop, and +- 3.3V or +-5V signalling for half duplex/RS485 bus.
Use a default setting of 9600 baud, 1 start bit, 8 data bits, no parity, and one stop bit in cases where the actual parameters are negotiated.