Rob Austein wrote: > But the question is whether we have time to do this, starting from > where we are now.
Right. To be clear: I am not at zero with a SAMD11 firmware now My current SAMD11 firmware sends a correct GET_VERSION request, but only manages to receive a few of the bytes coming back. I see on the scope that both request and response are correct on the wire. The firmware misses some bytes because the FIFO is only 1 byte and because it isn't using DMA, so it only has time for some 50 instructions before the next byte arrives, and that's apparently not enough. In a different project (architectural lighting) I've written a SAMD11 firmware that reliably receives UART communication without DMA, just interrupts, but that runs at 250kbps, about 1/4 of 921kbps on the Alpha. So, if we reduce the STM32 UART baudrate to 115k or 230k then I could already demonstrate a working firmware. Also, if CTS+RTS were connected then it would also already work, even if not (yet) at maximum throughput. While the solution in SAMD11 is definitely to use DMA, adding CTS+RTS to the STM32 UART interface is actually a very important change anyway. It is required to allow feedback from STM32 UART processing to bubble all the way back to the PC. These two signals are currently all that's missing. I wish I would have thought about that in rev3. I suggest: 1. Move forward with SAMD11 replacing FTDI 2. Add CTS+RTS to the UART interface 3. If time and space on the board allows it, also connect SPI Who does the hardware design changes? To support that effort I can contribute the required connections on the SAMD11 side. So far I've used the SAMD11 in the SO-14 package for this, but I can provide the pinout also for the QFN24 if that is preferd? //Peter _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
