[Cryptech Tech] dev-bridge board

[Peter Stuge]

Randy Bush wrote:
> > 1) I'm currently using the USB as a UART.
> 
> which seems, barring other constraints best,

As fun as network stack development is, implementing a packet
transport on top of an unreliable stream emulated on top of an
already reliable packet transport can never be good, let alone best.


> as on alpha that is all you will get.

It's not too late to review that decision. USB much > UART.


I have seen countless instances of engineers avoiding USB simply
because they do not know how it works and are afraid of learning
something new. Don't be that guy. It is really easy.

The complexity of STM32F4 USB software is not high, it replaces the
complexity of an application-level packet transport implementation
(on host *and* device) and removes several redundant layers, all in
one go.

Maybe you infrastructure guys will be convinced by the performance
argument. The only way to get top performance out of USB is by using
an interface protocol crafted for the application at hand.

Anything involving a UART is *not* that. You can easily bring
performance down by 50% with the emulated UART.

The reason is that USB is high bandwidth but in general also high
latency. So if you use an emulated UART to transfer a command packet,
then want a yes/no response packet, you are going to be waiting for
that response for a very long time in USB bus time, during which time
the bus is idle when it could instead be transfering data.

Instead, that command should be a control request, which includes an
ACK/NAK response on a low level in the protocol, set directly by user
code handling the request. No need to wait for a turnaround, the
response is already part of the low level protocol.


//Peter