New XMOS L2 board with USB ?

[paul]

Bitbanging at 12Mhz isn't an issue, although I am not sure if the XS1 will be able to handle both edges, might need a buffer/inverter. Anyone at Xmos care to comment? or anyone else for that matter?

regards
Al

You need a USB Transceiver to provide the correct physical interface http://www.fairchildsemi.com/cqpf/US/USB1T11AMTC.html

The current implementation therefore requires - 4x1bit ports and a 4bit port (the 4 bit port is for Vp/Vm lines for detecting the device and for detecting SE0, the other 2 bits cannot be used).

The main challenge for the FS implementation of the host/device are the turn around requirements (7 bit times) - especially for ACKs as you have to ensure the CRC is correct before sending one (remember you need to un-bitstuff and de-NRZI everything!).

[Folknology]

This is really very interesting and potentially most useful, I have a couple of questions:

The current implementation therefore requires - 4x1bit ports and a 4bit port (the 4 bit port is for Vp/Vm lines for detecting the device and for detecting SE0, the other 2 bits cannot be used).

Although its not perfect (That would be 2/3 pins) This is still better than throwing all of the pins away with ULPI if you don't need the high speed.

The main challenge for the FS implementation of the host/device are the turn around requirements (7 bit times) - especially for ACKs as you have to ensure the CRC is correct before sending one (remember you need to un-bitstuff and de-NRZI everything!).

Clearly the timings are tight can it be done in C or do you have to drop down into ASM. Also does it mean you have to confine yourself to 4 threads in order to guarantee the turn around? How many threads and what sort of memory is required for the current host implementation. Sorry about so many questions I'm just trying to get a handle on the overheads of an implementation and thus what is left for the app itself.

regards
Al

[paul]

The implementation allows full 8 thread usage on a 500MHz part, but requires two threads. One for the interface of the buffer to the physical thread and the physical thread itself.

The very low level bit banging has had to drop down into ASM to achieve the above. Everything above that is either C or XC.

We currently have only host implementation (as I think was mentioned above). But device could probably be fairly easily derived from it.

I can't dig the memory requirements out off the top of my head for the host - but most of it is buffers. These can obviously be tuned to whatever you are plugging into it and the implementation of your application.

[Folknology]

Thanks for that Paul it helps me get my head around it, having another 6 threads to play with leaves plenty of headroom.

One small clarification..

The implementation allows full 8 thread usage on a 500MHz part, but requires two threads. One for the interface of the buffer to the physical thread and the physical thread itself.

& I notice on the keyboard.xn file 12Mhz Oscillator and the following settings :

Code: Select all

<Node Id="0" Type="XS1-L1A" InPackageId="0" SystemFrequency="480MHz" ReferenceFrequency="96Mhz" Oscillator="12Mhz">

Are these the recommended clocking configs for Soft USB usage?
I presume this also excludes the 400Mhz L1 parts?

regards
Al

[lilltroll]

I have not seen the code, but if you run the core freq. in a multiple of the baudrate, you can use the clockdiv, to run code with very few instructions, e.g. no instructions to wait for event.
No need to program the porttimers to wait for n clocks either.

For an example ju can run the XTAG1s UART at 3 MHz if you clock the G4 @ 384 MHz. The FTDI chip clocks at 6 MHz. (96 MHz and a clockdiv of 2*24). With that bitbanging almost gets efficient.

[vinithmundhra]

Hi all,
There is a new project here: https://www.xcore.com/forum/viewtopic.php?f=15&t=1547
It uses the Full Speed USB Host and implements Android accessory protocol (to work with Google Nexus S phone).