USB help.
RicardoP
Posts: 13
Well I'm working on a rather complex project and I hope I can explain it clearly enough to get some help. I'm posting this here since I would love to use the properller for this, I've been working with it for a bit now and I've gotten familiar with it.
So I have a USB host and a device to go with it. The device is very similar to a HID device. They are both closed systems (the host is not a PC) that I can't modify in any way. They communicate with each other via a full speed USB connection. What I would like to do is create a software bridge between the two. When the host initiates a query to the device, I would like to analyze the request and take one of two actions based on if this is a packet 'of interest':
a) Simply pass the packet along to the device, then read device reply and pass that to the host. This is the 90% case where the packet is of no interest.
b) Create my own packet using logic in the properller and send that as a response and never asking the device for a reply. I could have 1 cog creating responses ahead of time.
Previous attempts to get some help with this yielded the following responses:
a) You can't do that.
-- Well, I know it is possible, because there are other such devices on the market, unfortunately they do not offer some functionality that I need.
b) There isn't enough time to modify the data on the line.
-- Isn't time relative to the speed of the processor you are working with? Isn't the propeller fast enough to do this?
So I have a USB host and a device to go with it. The device is very similar to a HID device. They are both closed systems (the host is not a PC) that I can't modify in any way. They communicate with each other via a full speed USB connection. What I would like to do is create a software bridge between the two. When the host initiates a query to the device, I would like to analyze the request and take one of two actions based on if this is a packet 'of interest':
a) Simply pass the packet along to the device, then read device reply and pass that to the host. This is the 90% case where the packet is of no interest.
b) Create my own packet using logic in the properller and send that as a response and never asking the device for a reply. I could have 1 cog creating responses ahead of time.
Previous attempts to get some help with this yielded the following responses:
a) You can't do that.
-- Well, I know it is possible, because there are other such devices on the market, unfortunately they do not offer some functionality that I need.
b) There isn't enough time to modify the data on the line.
-- Isn't time relative to the speed of the processor you are working with? Isn't the propeller fast enough to do this?
Comments
The Propeller can synchronize multiple cogs for high rate VGA generation. The same technique might be doable for higher rates of data transfers. It's not easy to do and I don't recommend it. You might look into the SX processor. It has a higher raw execution rate, particularly where only byte or bit data is handled and the processing involved is very simple. An SX-28AC and two MAX3421E should be able to do what you want.
Mike is absolutely right about the timings, and time available, but don't forget you have at most 7 bit times after the host EOP until the device starts sending its reply.
You have to analyse the request in that time, switch the lines and start your own reply. If you are late, you will cut the device off mid reply (and it'll probably be upset about that)
Not saying it can't be done, but I've had a couple of goes at doing full speed USB on the propeller, and the timing requirements just outstrip the capabilities of the device.
It's not just the on-the-wire stuff, but also the protocol handling and generation. I'm struggling to do low-speed within the requirements of the spec.
Oh, yeah, you will also need to properly ACK the reply that the device sends also, even if it goes off into never never land.
Time is tight!
Mike, I'm afraid I'm more of a software guy I'm not sure I can put together a PCB with 2xMAX3421E and a SX-28AC and the rest of the hardware together. But I did do a bit of digging around and came across this http://www.crownhill.co.uk/product.php?prod=1590, do you think I can hook this up to a propeller demo board? It has 2x USB ports which is what I need ... assuming the port usage is not exclusive of one another. Then again, you said the propeller might not be fast enough ... when are we getting the 160 MIPS propeller? I bet the whole thing could be done in software then!
Two of the MAX3421E OEM boards and an SX-48AC Protoboard would only need some hooking together (the SX-48 has twice as much memory as the SX-28 and would make things easier). You'll need the programming key and TTL oscillator (and try the 50MHz resonator as well ... that may or may not be fast enough) as well as downloading the software and "how to" guides.
If the overall (throughput) speed isn't that critical, the Propeller may be easier to use than the SX. Just substitute a Propeller Protoboard for the SX-48 one. You might as well get the Accessory Kit which will let you use a VGA monitor for a status display to help with debugging.
Post Edited (Mike Green) : 10/23/2007 11:00:05 AM GMT
Mike I wish I had the skills to put together what you propose, even if it is simple I neither have the skills nor the equipment to do it. I will need to find a ready made solution (I'm talking hardware hookups I can figure out the software) or pay somebody to do it for me, know anyone?
Rayman, it is possible it would run at low speed but I would prefer if it worked at full speed as it was designed.
full-speed support is mandatory for hosts, so there is no sense in any kind of fallback for the devices. A low-speed only host would violate the spec badly.
Easy enough to tell what your device is, just measure the polarity on the bus. Low speed will be D- +ve and D+ -ve
and full-speed will be the inverse.
This varies with data transmission, but most meters will average it out nicely. You should see close to 0-250mv on the -ve and up around 2.7-3.0v on the +ve (rough and ready empirical measurement)