[Cryptech Tech] dev-bridge board

[Fredrik Thulin]

On Wednesday, December 09, 2015 11:24:01 PM Peter Stuge wrote:
...
> Replacing the FTDI UART with a small USB-capable processor would
> allow the best of both worlds - a UART is still the interface to
> the STM32F429, but a meaningful USB protocol is the interface to
> the host software.
> 
> I had forgotten that the USB interface only needs to be full speed
> so I had ruled this option out.
> 
> 
> There are tons of candidate processors to choose from. I have many
> years of experience with the NXP LPC1342/43 Cortex-M3; among other
> things I've used it in a workshop on how to create USB devices and
> easily write host software. That material is online at http://cbs.stuge.se/
> 
> The required components given 3.3V are CPU (LQFP48), two ceramic supply
> caps, a crystal, two caps for the crystal, two series resistors for USB
> D+ and D-, one 1.5k 1% pull-up and one digital transistor or FET to
> control USB presence from the device.
> 
> The hardware might even be simpler than for the FT232, the software
> allows a good USB host protocol, and with this approach someone will
> still have the pleasure of writing a serializer/deserializer, but
> with the potential added benefit that they would be running quite
> close together and in very similar environments - maybe allowing even
> more code reuse.

I agree the hardware stated above is as simple or even simpler than the FT232H 
we used on the dev-bridge.


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

* more reliable communication between host and alpha

* vendor specific interface being the recommended way to go by the one I 
consider the USB expert in the group


Cons:
* another MCU for us to program and support

* 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)

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


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.

/Fredrik

[1] DS_FT232H.pdf, 4.1 (page 22) "upto 40 Mbytes/second over a synchronous 245 
parallel FIFO interface"