[Cryptech Tech] dev-bridge board

[★ STMAN ★]

Hello.

For your information, I am working on the developement of a full USB Host and device controler with ULPI wrapper + dedicated ‘higher level’ profiles (Mass storage, and a few others) in full cabled logic state machines, therefore requiring no « software stack driver » as specified in the USB Standard, ready to be connected to any USB PHY respecting the ULPI 1.1 standard, and to be implemented in any FPGA, preferably Spartan 6.

I also want to remind you that a few similar development are available on OpenCores, but unfortunately, they are not sufficiently documented to be integrated / improved easily in new designs.

I will let you know when this work is ready.

Kind regards,

Stman.

Le 10 déc. 2015 à 14:33, Peter Stuge <peter at stuge.se> a écrit :

> 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
> _______________________________________________
> Tech mailing list
> Tech at cryptech.is
> https://lists.cryptech.is/listinfo/tech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.cryptech.is/archives/tech/attachments/20151216/7cf2510f/attachment.sig>