Hi Paul, Paul Selkirk wrote: > I fixed this (to the extent I've been able to test it) before I went on > vacation, but (as Rob deduced) I forgot to push it until today. :P
Oh cool! > The basic problem is the amount of processing that takes place in the > interrupt handler (whether it's a direct UART receive interrupt or a DMA > half/complete interrupt). Under heavy loads, we tended to miss > characters, mis-order characters, or stutter characters. Ack, after my quick look I figured that might be the problem - you obviously have a much more detailed view. > So I revived the essence of commit 2b6b9f, where I've got a larger DMA > buffer than I think I'll need, and a once-every-ms task that pulls data > off, processes it, and queues RPC requests. It tests out well, and the > UART receive queue doesn't exceed 94 characters, which is consistent > with a transmission rate of 921600 baud, modulo a bit of jitter in the > SysTick interrupt. That's great! > I don't mind working with CMSIS/HAL, because it's a useful API, and I > don't think it's necessarily the gating factor in my design. Rather, I > think it was all the extra work I was trying to do in the interrupt handler. Nod. CMSIS does add some cost, I was suggesting dropping it primarily to lose that, but if it works anyway and you like the API then there's absolutely no reason to change anything. > I have great hope that this will be more stable, and I can go on to > spend my time on more interesting/useful work. Good stuff. I forget, do you have a USB daughterboard? Ie. could you easily stress test with the combination of the new stm32 code and the daughterboard? If not, what has been your stress test so far? Maybe I can replicate it? Thanks //Peter _______________________________________________ Tech mailing list Tech@cryptech.is https://lists.cryptech.is/listinfo/tech
