Randy Bush wrote: > for security boundary reasons, Unfortunately, nothing supports that argument.
> the alpha board, and any follow-on, will not have uncastrated usb. I think "uncastrated USB" as you call it (haha) has *fewer* security and reliability implications than a homemade parser for an unreliable byte stream. > we already had this discussion; let's not repeat it. The decision is based on fear and uncertanity, not on facts. I'll keep saying that as long as someone else claims that it helps security. :) But I understand that you will stay with your decision. I've offered to help with the only difficult part; USB protocol design. I estimate that it would take a few hours to think through with Rob and Paul. Maybe we can have a go at that if we meet sometime soon. Now - one actually does not have to exclude the other. What I mean is that a USB protocol does not neccessarily have to be implemented in the STM32 - it could be implemented in another controller which replaces the (expensive and stupid) FTDI UART. 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. //Peter _______________________________________________ Tech mailing list [email protected] https://lists.cryptech.is/listinfo/tech
