Posted on June 19, 2018 at 10:50To explain, for my application I need to set a CS line and then immediately read a 16-bit parallel bus. This is easily achievable on the F7 using GPIO with BSRR and IDR, but I cannot think of a way to abuse a peripheral to let me do the same on the H7.
Try timer-driven DMA to read the parallel bus, with the CS being output by a different channel of the same timer (or a chained one).
Generally, higher apparent processing speeds beyond a certain technological limit are (have to be) achieved by adding contraptions rather than just scaling up the raw clock rate. These contraptions then introduce various forms of latencies; and as there are several of them (superscalar execution, pipelining, multilevel caching, (de)parallelizing of various forms) they interact in an incredibly complex form resulting in gradually less and less predictibility and more and more surprising latencies and jitters. Turns out, it may be hard even for the manufacturer to establish hard numbers without firing up a complex (read: lengthy, thus expensive) simulation. And as too many parameters go into each single path's calculation and there are too many scenarios to deal with all of them, this is inevitably handled by handwaving (i.e. there's no 'how bad it can be' in the DS/RM, and never will be).
Thus, at the end of the day, for resemblance of real-time processing you'll need to stick to the simplest hardware available, or do what you'd call as a step back and go for the simpler mcu or dedicated hardware (maybe as a slave - here external; some designs - not STM32, or not yet in the general-purpose line - build asymmetrical multicore chips for this purpose).
JW
