Working full-speed (12 Mb/s) bit-banging USB Host controller

[scanlime]

This is something I've been wanting to try for a while, but I finally had an excuse...

I've been wanting to build more devices that can communicate wirelessly. Sensors, ambient information displays, that sort of thing. To reduce the infrastructure needs, I'd like to use Bluetooth, or preferably Wifi. Problem is: I want these things to be cheap, and it's still fairly expensive to buy a Bluetooth or Wifi adapter that's microcontroller-friendly. I'd much rather stick a $5 USB bluetooth dongle on my Propeller and have a solution with simple/cheap hardware and software which is merely not impossible to write :)

Anyway.. I'm still working on writing USB class drivers for it, but I have a working full-speed host controller. So far it supports Control, Bulk IN/OUT, and Interrupt IN transfers. There are a couple simple demos included: Device enumeration and descriptor parsing, a very simple HID demo, and an even simpler mass storage demo.

As you'd expect, there is a huge list of caveats for something that pushes the limits of the Propeller and the USB spec to this extent.. It uses four cogs, requires overclocking the Prop to 96 MHz, and even though the line rate is 12 Mb/s the actual usable data throughput is significantly lower.

But, this lets you talk to a lot of fun new peripherals that were previously unavailable to the Propeller. So it should be fun :)

The hardware is really simple: Four resistors and a USB socket. If you try it out, let me know how it goes. Compatibility with different devices still isn't perfect. It works with most of the devices I've tried it with, but some don't work at all, and some work intermittently. But on the devices it does work with, transfers seem to be quite reliable.

My next goal is to write a simple proof-of-concept USB storage class driver ('cuz why not?) then see if I can get Bluetooth working.

--Micah

Post Edited (Micah Dowty) : 4/6/2010 6:30:59 AM GMT

[heater]

It's a constant source of amazement to me. The number of things it's obviously beyond the Props capabilities or too hard to do that end up getting done anyway. Excellent work.

Unfortunately I don't have a project that can spare 4 COGs for the addition of USB host.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

[Cluso99]

Micah,
Congratulations, this is great news indeed. Even if we have to sacrifice 4 cogs it is still excellent news that it can be done.
FWIW, the prop can be overclocked reliably to 104MHz (6.5MHz xtal*16) with the correct layout and I am soon to prove 108MHz (13.5MHz xtal*8).

I am sure there are ways to speed things up. Kuroneko is excellent with counters so he may have some ideas.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

[TonyWaite]

Congratulations!

Another barrier smashed!

T o n y

[Toby Seckshund]

Indeed, very well done. Many others just said it can not be done.

Now it will be interesting to see what will play nicely.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point

[Ahle2]

This is great news! :)
It will open up a lot of possibilities.

[Bill Henning]

Excellent work!

The only down side I can see is that it uses four cogs - however for some applications that is fine, and one can always add another Propeller...

Micah Dowty said...
This is something I've been wanting to try for a while, but I finally had an excuse...

I've been wanting to build more devices that can communicate wirelessly. Sensors, ambient information displays, that sort of thing. To reduce the infrastructure needs, I'd like to use Bluetooth, or preferably Wifi. Problem is: I want these things to be cheap, and it's still fairly expensive to buy a Bluetooth or Wifi adapter that's microcontroller-friendly. I'd much rather stick a $5 USB bluetooth dongle on my Propeller and have a solution with simple/cheap hardware and software which is merely not impossible to write :)

Anyway.. I'm still working on writing USB class drivers for it, but I have a working full-speed host controller. So far it supports Control, Bulk IN/OUT, and Interrupt IN transfers. There are a couple simple demos included: Device enumeration and descriptor parsing, a very simple HID demo, and an even simpler mass storage demo.

As you'd expect, there is a huge list of caveats for something that pushes the limits of the Propeller and the USB spec to this extent.. It uses four cogs, requires overclocking the Prop to 96 MHz, and even though the line rate is 12 Mb/s the actual usable data throughput is significantly lower.

But, this lets you talk to a lot of fun new peripherals that were previously unavailable to the Propeller. So it should be fun :)

The hardware is really simple: Four resistors and a USB socket. If you try it out, let me know how it goes. Compatibility with different devices still isn't perfect. It works with most of the devices I've tried it with, but some don't work at all, and some work intermittently. But on the devices it does work with, transfers seem to be quite reliable.

My next goal is to write a simple proof-of-concept USB storage class driver ('cuz why not?) then see if I can get Bluetooth working.

--Micah

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

[Timothy D. Swieter]

I like the idea of using cheap usb bluetooth dongles.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.
www.brilldea.com - Prop Blade, LED Painter, RGB LEDs, 3.0" 16:9 LCD Composite video display, eProto for SunSPOT, PropNET, PolkaDOT-51
www.tdswieter.com

[jazzed]

@Micah

Thanks for taking up this challenge. Being able to use cheap dongles instead of costly special modules is definitely worth losing COGs. It would be sweet if Propeller has room left for a port of a linux USB host driver for one of those cheap-o WIFI dongles ....

Ooo-rah!
Added: Hope this isn't an April Fool:) Doesn't look like one.

Post Edited (jazzed) : 3/31/2010 3:37:59 PM GMT

[scanlime]

Thanks, everyone :)

@jazzed: Not an April fools, though that would have been hilarious!

Regarding the four cogs- there might be ways to reduce this, or at least to repurpose these cogs for other things most of the time. Only one cog is needed to transmit, but I'm using two interleaved cogs for receive, and one just to send ACK packets at exactly the right time.

It would be possible to go to 1 receive cog rather than 2, if you're okay with limiting the maximum received packet size to what will fit in cog memory. The interleaving is necessary so I have time to stream the data back to hub memory.

There also might be a better way to do ACKs, so I don't need a separate cog. The main reason for that is that when I need to send an ACK, the other cogs are all busy- the RX cogs haven't necessarily detected end-of-packet yet (they only get a chance once every 32 bits) and the TX cog is busy babysitting the RX cogs.

It would be possible to have the TX cog send the ACK, but I'm using waitpeq to find the end-of-packet condition- so if the packet never arrives, we're stuck. But I could have the RX cogs take responsibility for waking up the TX cog after a timeout...

That might work. I'll try to remember to give this a shot, it might reduce the number of cogs by 1 at least. Only downside I can see is that the ACK code would take up space in the TX cog that could be used for transmit buffer, so the max transmitted packet size will be smaller.

--Micah

[Philldapill]

Micah - No, an april fools joke of this magnitude would be down right mean. There are sooo many people on this forum that have dreamed of a USB Host controller in the propeller, only to be told that it's impossible. If you can get a USB thumb drive to work fairly reliably with this, I'm sure you will have people bowing at your feet.

[Kye]

Why not just support low speed USB? Then you should be able to fit everything within one cog.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

[scanlime]

Kye said...
Why not just support low speed USB? Then you should be able to fit everything within one cog.

That would work for low-speed devices only. All high-speed (USB 2.0 480 Mb/s) and super-speed (USB 3.0 5 Gb/s) devices still have backward compatibility with USB 1.1 host controllers in 12 Mb/s full-speed mode. So, a low-speed host controller would work with very few devices (mostly mice and keyboards) whereas a full-speed host controller will work with the vast majority of USB devices.

If someone combined both a full-speed and low-speed host controller in one module, we'd have a fairly complete USB 1.1 controller that theoretically would work with any USB device. If there's a good reason to do this, it shouldn't be too hard. The same transmitter can be used with a lower clock rate. And a much simpler receiver cog would work. The rest of the code can be shared between both speeds.

--Micah

[jazzed]

Micah Dowty said...
but I'm using waitpeq to find the end-of-packet condition- so if the packet never arrives, we're stuck ...

I've found using a 2 instruction test loop is often just as effective as using waitpeq. Depends on how long the incoming event is available of course.

[scanlime]

jazzed said...

Micah Dowty said...
but I'm using waitpeq to find the end-of-packet condition- so if the packet never arrives, we're stuck ...

I've found using a 2 instruction test loop is often just as effective as using waitpeq. Depends on how long the incoming event is available of course.

But that will give you a pretty large and variable latency of 8 to 16 cycles, right? I think waitpeq gives you single-cycle resolution.

But yeah, I probably overdesigned that. I was trying to make the ACKs really robust so I didn't have to worry about debugging them and everything else at the same time- but it could be that it's okay to tolerate a little bit higher latency.

--Micah

[jazzed]

If I understand it correctly:
A waitpeq can take up to 15 cycles (7 in your example) to detect a condition less than 4 (1???) to exit.

' according to the data sheet, either of these would takes 8 cycles to detect and exit.
cmp cond,ina wz
if_nz jmp $-1 ' 8 cycles if no jump ... except that it's a nop when cond equal ina
cmp cond,ina wz
if_nz djnz timeout, $-1 ' 8 cycles if no jump ... except that it's a nop when cond equal ina

From my experience, the 2 methods are equivalent, except that timeout latency is more and a pulse < 8 clocks will be missed.

Post Edited (jazzed) : 3/31/2010 7:29:21 PM GMT

[Bill Henning]

You know what would be perfect?

A low speed host (1.5mbps) that worked at 80,96 and 100MHz, and supported USB keyboard and USB mouse in as few cogs as possible - ideally one cog.

I know... I am dreaming... probably not feasible.

Micah Dowty said...
This is something I've been wanting to try for a while, but I finally had an excuse...

I've been wanting to build more devices that can communicate wirelessly. Sensors, ambient information displays, that sort of thing. To reduce the infrastructure needs, I'd like to use Bluetooth, or preferably Wifi. Problem is: I want these things to be cheap, and it's still fairly expensive to buy a Bluetooth or Wifi adapter that's microcontroller-friendly. I'd much rather stick a $5 USB bluetooth dongle on my Propeller and have a solution with simple/cheap hardware and software which is merely not impossible to write :)

Anyway.. I'm still working on writing USB class drivers for it, but I have a working full-speed host controller. So far it supports Control, Bulk IN/OUT, and Interrupt IN transfers. There are a couple simple demos included: Device enumeration and descriptor parsing, a very simple HID demo, and an even simpler mass storage demo.

As you'd expect, there is a huge list of caveats for something that pushes the limits of the Propeller and the USB spec to this extent.. It uses four cogs, requires overclocking the Prop to 96 MHz, and even though the line rate is 12 Mb/s the actual usable data throughput is significantly lower.

But, this lets you talk to a lot of fun new peripherals that were previously unavailable to the Propeller. So it should be fun :)

The hardware is really simple: Four resistors and a USB socket. If you try it out, let me know how it goes. Compatibility with different devices still isn't perfect. It works with most of the devices I've tried it with, but some don't work at all, and some work intermittently. But on the devices it does work with, transfers seem to be quite reliable.

My next goal is to write a simple proof-of-concept USB storage class driver ('cuz why not?) then see if I can get Bluetooth working.

--Micah

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system

[Hanno]

Great work Micah! I would love to be able to stick a "DealExtreme" $2(including worldwide shipping!) bluetooth dongle: www.dealextreme.com/details.dx/sku.11866 on the Propeller. Opens up many options!

You win an ultimate license for 12blocks or viewport if you can get it done!
Conditions: I can communicate to/from the Propeller at 100kbps+ with just some passives and a USB bluetooth dongle. 4 cogs is fine, overclocking is fine, limits on datasize is fine, code is MIT license)
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Co-author of the official Propeller Guide- available at Amazon
Developer of ViewPort, the premier visual debugger for the Propeller (read the review here, thread here),
12Blocks, the block-based programming environment (thread here)
and PropScope, the multi-function USB oscilloscope/function generator/logic analyzer

[jazzed]

It seems that Micah has created an "enabling technology" that allows others to produce on the growing wish list. We shouldn't rely on him for everything else too :) If I wasn't knee deep in something else now, I would contribute.

[Tubular]

Micah, outstanding work, congratulations! This really opens up a whole new world of cheap expandability to the prop.

Thankyou also for commenting the code so well, and more than that, adding a great background preamble at the start

tubular