Posted on June 21, 2018 at 00:49Data transactions to buses beyond the TCM are not occurring in a single-cycle, I'd expect something on the AHB to take at least 4 cycles. I'd also expect any decision or arbitration hardware to add additional delays and sequencing. Buses which take more time are by definition slower. Can't find a good diagram of the timing, but you've got a 6 stage pipeline trying to stuff data into a subsystem that needs to sequence through something clocking at least 1/4 the speed/throughput. Observe the behaviour on a multi-lane motorway when everyone has to suddenly funnel into a single lane at half the rated speed limit.
Your code example is also very poor, you want to get this as close to single instructions as possible (repetitive stores), not call subroutines with asserts, comparisons, shifts and loads.
See how something like this works,
{
volatile uint32_t *p = (volatile uint32_t *)&GPIOD->BSRR;
uint32_t a = 1 << 12, b = 1 << (12+16);
while(1)
{
*p = a;
*p = b;
*p = a;
*p = b;
*p = a;
*p = b;
*p = a;
*p = b;
*p = a;
*p = b;
*p = a;
*p = b;
*p = a;
*p = b;
*p = a;
*p = b;
}
}
But also observe that whetstone and dhrystone benchmarks don't do IO.
If you want a pin to bang up and down at 54 MHz use a TIM, and zero CPU cycles.
