On 10.12.2015 11:29, Fredrik Thulin wrote:
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.
I agree with the list of factors above, but the problem is that
different factors can have different impact. In my opinion, the two
worst factors are:
1) There're already three programmable devices on board, and we're going
to add another one.
2) UART (which is the obvious bottleneck) is not eliminated.
In my opinion, these two factors outweigh pros, so I vote for leaving
FTDIs in place.
--
With best regards,
Pavel Shatov
_______________________________________________
Tech mailing list
Tech@cryptech.is
https://lists.cryptech.is/listinfo/tech
