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 <pe...@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@cryptech.is > https://lists.cryptech.is/listinfo/tech
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
