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