USB object?

Muncher

I am NOT good with assembly, and I want to create a USB object. I'm guessing this cannot be done in SPIN, so 1) can it be done, and 2) how can it be done.

I'm lazy... (snore)

Mike Green

Do you want to create a USB slave device or a USB master? A slave object for a simple device like a HID class (keyboard, mouse, etc.) should be doable in SPIN. A USB master is much more difficult since it has to know how to drive all kinds of devices. On the other hand, getting a new slave device to work with Windows or MacOS is harder. It's much easier to use a USB to serial adapter like the FTDI FT232R or already assembled modules like their TTL232R-3V3 smart USB cable which is directly compatible with the Propellor's signal levels and can supply 5V at 50ma.

Beau Schwabe

Mike,

How about a "core" example file of a HID class slave object?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Mike Green

Beau, That's way way down on my priority list. After looking again at the USB spec, I think the low level stuff will have to be done in assembler (decoding and encoding the bit stream, calculating a CRC, looking for special conditions). Everything else can be done in Spin. I've got a USB based PIC programmer that looks like a HID. Microchip includes source listings and they looked very straightforward to convert to Spin, but I forgot about the built-in USB engine that does the bit assembly/disassembly. It's probably not too much more complicated to do than a full duplex serial object, but I don't have the time now.

Here are some references though:
<http://www.edn.com/article/CA243218.html&gt;
<http://www.usb.org/developers/devclass_docs/HID1_11.pdf&gt;
<http://www.usb.org/developers/devclass_docs/Hut1_12.pdf&gt;
<http://www.usb.org/developers/docs/usbspec.zip&gt;
Also look in the Circuit Cellar archives. They had a series of articles several years ago on making your own USB devices.

Cliff L. Biffle

Keep in mind, of course, that without a hardware UART or any sort of buffering, you'll have to bit-bang at least 1.5mbps (USB's "low" speed). The "high" 12mbps speed will not be reachable on the current Propellers without a lot of trickery (and without info on when the instructions latch INA, I don't know if such trickery is possible).

Kaos Kidd

...Just for the record about USB Master devices....
I have pumped many, many hours into this. From times before the propeller on my bs2, and I can honestly say the following:
A USB master does not need to know about all devices that you can attach to it, only the ones you do attach to it.
#1: if you plan on only ever hooking a mass storage device, then you only need that aspect of a driver.
#2: All you really need to know is :
......A: The actual cmd protocall needed to access the default endpoint
......B: The method of reading the device(s) power requirements and then setting it.
......C: (Only if more then one is connected) -> Change the default address (which is zero) to something un used.
......D: Access and store the prefered endpoint.
......E: What to do with the data when it arrives

THis link to a forum discussion holds lots of links needed to make it work: http://forums.parallax.com/forums/default.aspx?f=25&m=127446
I was working on a USB Master for mass storage devices. My propeller programming skills are still womewhat weak, but they are improving.
Next, because of the power switching and enumeration (step B & C) and understanding the data returned in step D, I was going to move to a chip implimentation.
This is very simular to the product USBWIZ, and it's abilities. The advantage of the $59 USD USBWIZ is that is comes complete with 12/16 & 32 FAT on chip!
(Meaning you don't have to code a file system). For now, until my skills improve (and I know many users here have skills way better then mine), I am placing the project on hold. Never the less, just understand it like it is:USB is popular because the master can load a driver and access any kind of device without any special hardware.
If you know the devices you project is going to use, you don't need vast code to support things your not going to use.
Within the links I supplied on USB above is the command struct, timing and actual C code implimenting a usb master.

Yes, the propeller can be a USB Master, I'm 100% sure of it, and I'm not the only one who knows this.
BUT: It's not going to be like a PC with USB host and lots of different things you can attach, and, it will consume resources.

Sorry if this sounds like I'm preaching, grumpie or just a binge, I'm really not.
Before you blow off creating a USB Master, think about it, breaking down into it's smallest parts and building it up from there.
A USB Master is some hardware and lots of code following a very percise protocall. that's it; nothing else.
There are chips that will tend to all of the nitty gritty, including the sending / recieving of the data, the checksums, error protocalls, and even the power switching, leaving only the implimentation of the commands and the end device needing to be coded.

The only reason it needs to be coded in assembly is to achieve the top end speeds of USB 2.0. If speed isn't the issue, and the device(s) you plan on using are either mass storage or HID, low speed USB 1.0 is fine, and the propeller can maintain that speed with no problems. This assumes you use hardware to impliment the usb spec.

Thank you for reading...
This post is not ment to come off in a negitive way, against anyone or anything. This post summerizes what I have learned from reading, what I know from doing, and its a small attempt at opening the eyes of others at a different way of looking at things, something the propeller must force you to do as well.
My sorries to anyone how may be offended, again, it's not intented.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Mike Green

Thanks, Kaos Kidd. Your comments are all very true except that I still think a Spin program would have trouble doing the NRZI decoding and bit un-stuffing even at low speed (1.5 MBit/s). The transmit end might still work in Spin, but would probably be easier in assembly. I didn't mean to ignore the idea of a USB bus master, but it is much more complicated than a USB slave. The other piece is the issue of drivers on the master side. Mass storage devices and HID devices are now pretty generic and Windows, MacOS, and Linux all provide for user access to both without specialized low-level drivers.

Kaos Kidd

Mike.
Very true. I was refering to using one of the dedicated chips, it handles all of the data xfers, it delivers and takes data in parallel.
But, in all, your most likely very correct about needing assembly; I'll sum up my propeller assembly skills here: "" [noparse]:)[/noparse]
Once I get some more propeller programming exp, I"m going to hop back onto this project again.
And you are 100% on it about a slave being much easier to impliment then a master... way much easier.
The mass storage drivers simply tie into the file system drivers, ie the data gets piped through that type of driver, which is why most systems don't need a driver for the mass storage and hid devices. My idea was to create a usb master object just for mass storage, for like the thumb drives and stuff. Again, I'm in a holding pattern.

THanks..

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Muncher

A slave object is what I need. It needs to be able to communicate with a computer, too. So, SPIN will work?

Oliver H. Bailey

The speed at which the USB master will acquire data is dependent upon the type of device you specify. HID device such a mice and keyboards operate at 64Kps not anything close to 1.5 megs. Microchip has a reference design on their site for building an HID keyboard. That will provide you with the needed information on how to make the Propeller look like a standard HID device. Spin does work for certain types of devices. No, yo can be a streamng media device or hard disk but you can be a modem without a problem. The HID modem has baud rates that comfortably go up too well over 200 Kbs. You can also attach a couple pins to an FTDI chip and use the DLL drivers (if they work) to get 1 Megabits per second throughput. I'm just finishing a product that layers over the FTDI direct drivers for security so I know this throughput speed works fine.

Oliver

Muncher

Thanks for the input, Oliver. I'll look that up.