C860 as usb host by software?

[omega]

Hi,

I have been wondering about this for a while now. Since USB is bidirectional, is there a way to emulate a usb host in software using the client port on the c860?

I understand that there would be no power supply available on the client port, but this could be implemented in a cable. Apart from this though, what other hardware features are missing from a client side implementation of USB? Is there normally a hardware generated clock signal provided by the host?  

The reason i\'m thinking of this is that normally it is not conceivable to use a client usb device as a host - but in this case the client is intelligent and not a passive device like a camera, etc...

[omega]

*** BUMP ***

So any ideas? I was looking around but didn't see anything so far...

[scoutme]

gonna find something on the net..

I'll let you know

[lardman]

I hate to bring this up again... ;-)

I was looking at how usb dongles (the kind of thing you have to use to work some software) work today (fairly random) and came around to this topic again.

Can someone explain once and for all why it's not possible to implement a USB host with the hardware built into the Z (that is my understanding of what people think, but there's always a little chink in the argument exposed by my lack of understanding)?

My understanding is that most of the USB host can actually be implemented in software; therefore is there enough hardware to make this possible (I realise this would require a fair bit of development and number-crunching power in the software, but I'm just trying to get my head around it)?

Of course most of this functionality is normally built into the hardware, but is there even the fainest glimmer of a possibility of being able to run/emulate it in code?

Cheers,


Si

[lardman]

What is the bit of hardware which is the USB client (e.g. is there a USB client chip)? Or is this handled directly by the CPU (I read somewhere that PXA chips have some USB functionality built-in)?


Si

[tz]

I won't go into deep theoretical possibilities (changing the USB ports to digitial I/O, adding RTLinux (real-time extensions) and bit-banging the USB host signals).

The USB controller is in the ARM chip.  AFAIK it does NOT have a host mode, and is USB 1.1 which does NOT have a bidirectional mode.  One of the (IMO) errors of USB is that it wasn't peer-to-peer, it *required* a host, and could only communicate host initiated transactions to a peripheral.

The timing and protocol are different depending on Host/Target.  Some chips (like the one in the Ratoc CF card) can be configured to be either host or target.  Most can't, including the onboard USB controller on the Z.

I don't know if "bit banging" is possible (I use my sound port as a UART for GPS), but the USB "controller" is only designed to handle the target half of the USB protocol.  So it can't initiate, only respond.  The new USB 2.0 chips that can do peer-to-peer have the extra modes and registers to make this work.

So you can't put the onchip USB controller into a state where it would send the correct protocol to communicate to another USB target device.

By "bit banging", I mean implementing a software USB host that sets or clears bits in an output port register within the USB timing specs.

Another problem is power - the host or hub provides it.  You would have to hack in a 5 volt power to both target devices from somewhere.

Theoretically, someone could come up with a USB "null modem" that would be a pair of hosts with some intelligence that would simply echo USB Serial (and maybe network) across the two host ports.

[iamasmith]

Woah,

Don't like the sound of trying to implement the bitbanging stuff for USB.

I had some experience of writing this sort of assembler stuff in my early career. Without clocking hardware to rely on to measure intervals you are into tight assembler, counting cycles to produce timing loops, complete loss of portability etc.
Not a good combination for a Linux driver.

I know the SL-6000 has Host USB HW, so it may feature in a future model.... anyone know if the PXA270 has USB 2 features - There's rumours that's a likely processor for the SL-C9x0 series...

- Andy

[lardman]

The USB controller is in the ARM chip.

Okay, are there any specs for the hardware/api/asm instructions that anyone knows of? And is this the PXA or the SA, or both?

Another problem is power - the host or hub provides it. You would have to hack in a 5 volt power to both target devices from somewhere.

The power's not a major issue - it's always possible to supply that externally, and with a battery powered device this is always going to be a possible issue anyway. I was really interested in what you call "bit-banging" and whether this would be possible.

I've been doing some digging of my own, but still need to learn more; but from what you say it's the timing (or rather being able to provide the timing signals or signals at the correct times, etc.) which will cause the issues?

I agree with iamasmith that if it comes down to having to clock the hardware speed and adjust the assembly accoringly to ensure that the timing is correct it's really a non-starter, but I live in hope that this might not be necessary ;-)

My real issue is that I don't know what the hardware differences are between the host and client chips and their functionality; the same goes for the software (I need to dig out the kernel source and take a look).

The new USB 2.0 chips that can do peer-to-peer have the extra modes and registers to make this work.

Yes, I realise this, but it was my understanding that only basic hardware is actually needed and that the rest can be performed in software (should one so desire - and I'm certainly interested ;-))

Theoretically, someone could come up with a USB "null modem" that would be a pair of hosts with some intelligence that would simply echo USB Serial (and maybe network) across the two host ports.

Or would it be easier to implement the On-the-go part of the USB spec (which can still runa t slow speed iirc), as this should be more similar to the current client setup than a complete host.


Si

P.S.

I won't go into deep theoretical possibilities (changing the USB ports to digitial I/O, adding RTLinux (real-time extensions) and bit-banging the USB host signals).

I'd be interested, as, I'm sure, would others. I'm always happy to learn :-)

[omega]

I would also be interested... I'm bit banging a few io ports on my microcontroller project at the moment... not easy but doable...

We could of course get a serial to usb host chip and try and drive it from the serial port on the zaurus... ah yes i can just see the speed now.  half an hour to download a song from the harddrive! probably enough to read an ebook by though! lol

[lardman]

We could of course get a serial to usb host chip and try and drive it from the serial port on the zaurus... ah yes i can just see the speed now. half an hour to download a song from the harddrive! probably enough to read an ebook by though! lol

I thought about this and dismissed it as I thought exposing the USB host to the kernel would be a pain; however it might not be that bad - anyone have any ideas?

How happy would the kernel be? My reasoning is that the serial port and 'usb host' exist at the same level of abstraction in the kernel, therefore it (the kernel) might not be happy using one to implement the other; perhaps the kernel would have to completely ignore the serial port so it could be used as the 'usb host' only?

Just some random thoughts... ;-)


Si

[omega]

hold on, hold on! serial port is just too slow don't you think? I was just joking.....

[lardman]

hold on, hold on! serial port is just too slow don't you think?

It may not be very useable, but surely it's about what's possible?

In any case does it matter how fast the port appears to be? Will the USB client device refuse to communicate if the 'host' is running too slowly? If so, then I agree that it's a waste of time, otherwise it's still an interesting thought.


Si

[Foxdie]

How about a "middle man" box? A combined USB Host / Client to allow 2 USB clients to talk? I think if this existed it would require a driver installed on the Zaurus but it could work.

[iamasmith]

How about a "middle man" box? A combined USB Host / Client to allow 2 USB clients to talk? I think if this existed it would require a driver installed on the Zaurus but it could work.

Would this be cheaper than the USB Master CF cards ??, The CF Card gives power too (I think).

Anyone had experience of these ?

[lardman]

How about a "middle man" box? A combined USB Host / Client to allow 2 USB clients to talk? I think if this existed it would require a driver installed on the Zaurus but it could work.

Yes this is also a good idea, but it's starting to look expensive (I'd guess) and time consuming, both in terms of physical manufacture and driver writing. Might just be easier to reach into pocket and buy one of those ratoc cards (less fun though ;-).

This is going slightly off topic now, but where would one buy one of these (the cheapest place?), and are there any other similar cards out there (there was an interpocket card which has now been discontinued and another TwinParadox SolarExpress card which has been awaiting release for a long, long time).


Si