[Cryptech Tech] dev-bridge board

[Peter Stuge]

Fredrik Thulin wrote:
> > Replacing the FTDI UART with a small USB-capable processor would
> > allow the best of both worlds
..
> > I had forgotten that the USB interface only needs to be full speed
> > so I had ruled this option out.
..
> Pros:
> * better USB interface from the host side
> 
> * avoids having FTDI's design choices imposed on us - e.g. gives us
> ability to set USB VID/PID and other settings without that apparently
> being re-programmable from the host

That's a good point! And FTDI did some sketchy things with their
driver to brick customer hardware if they considered it fake.


> Cons:
> * another MCU for us to program and support

Yes, but if reusing the workshop material it's literally a matter of
minutes (really!) to have a working firmware, and from there it's
straight to the communication details - USB protocol and UART protocol.


> * not sure it would be able to match the 40 Mbyte/s [1] claimed for the 
> FT232H? OTOH, I don't think we need that much (now)

Indeed the small controllers can't do high speed USB, only full speed.
I was looking at the wiki page, where the Alpha board spec says 3 Mbit/s
for both host interface and for admin interface. A small controller like
the LPC134x can easily sustain 12 Mbit/s, but that's the limit. All
microcontrollers that I have seen which can do high speed are
unfortunately significantly larger - like STM32F429 large.


> * some kind of driver (.INF file at least) necessary on Windows
>   (not my main concern)

This isn't the case anymore - if we bend a little to the side in the
device firmware, and follow Microsoft's "WinUSB Device" specification
then no driver is neccessary, the device informs Windows on attach
that the WinUSB.sys kernel driver should be used, Windows loads that
driver automatically, and userspace can immediately access the device.
This works out of the box on Vista and up, XPSP3 needs a hotfix.

The bend to the side involves having a MS data structure in a string
descriptor, and implementing a control request to send another data
structure to Windows. Some links:

http://msdn.microsoft.com/en-us/library/windows/hardware/hh450799.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430.aspx
http://msdn.microsoft.com/en-us/windows/hardware/gg463179
http://blogs.msdn.com/b/usbcoreblog/archive/2009/10/31/how-does-usb-stack-enumerate-a-device.aspx

It's not so cool for MSFT to go off and invent their own standards on
top of the standard, but in this case I don't mind it too much
because it is completely out of the way for everyone else, and it
does provide a considerable usability benefit.


Oh, and another thing: It's easy to get a VID+PID for the firmware,
because this is an open project. OpenMoko are happy to assign a PID
to any open design without charge. The project could get its own VID
later on, but that's not really neccessary.


> Given the pros and cons I see at this time with the two different proposals, 
> and on the premises that you supply code and schematics (not all of it 
> necessarily, but I'm counting on a well matured boilerplate) and
> USB/protocol design advice, I've decided to put my vote in favor of
> your proposal.

One boilerplate device implementation is already at http://cbs.stuge.se/
in the workshop_project/ subdirectory, but I'm happy to help with
actual implementation and also supply schematic and a compact layout
as needed. (Someone else might have to make the part for the EDA design
tool though, I only have a gEDA library.)


Thanks

//Peter