Just read a remark of Paul in
another thread. Seemed more appropriate to react here.
Pauls remark was that I used a radix-2 implementation.
This is only partly true. The majority of the work is still performed in the CMSIS fft function (256). I only replaced the final radix4 step by two radix-2 steps. Yes it is slighly less efficient then a radix-4, but this allowed me to spread the load evenly over all cycles. This in combination with the double use of a complex fft for two real ffts, gave the improvement.
@Paul when you come around to looking at this, don't hesitate to ask for more explanations/comments. But please don't hurry, your other work is more important. Whenever somebody complains about processing power, a simple link to this thread will suffice. Also, although my code is somewhat more efficient, your code is more readible. I don;t think the occasional user will comprehend my code.
FYI, I am also looking into the fft256. It looks like I can get it almost 45% more efficient, and also a better spread over cycles. This time using a different approach, where I focus somewhat more on integration, but the gain is still almost 40% without integration. Won't publish the code yet, need to do some more testing, maybe next week.
Edit: A correction on better spread. The current fft256 already has an even spread. My new fft256 code use some more pipelining, and thereby the processing in each cycle is different, but still managed to reasonably keep the load equal forall cycles.
The application is calibration of tuning forks used in speed radar by law enforcement, some of the forks are of substandard manufacture and their output decays very quickly resulting in the need to determine frequency using an other than counter based solution. With your tweaks to the code and CMSIS based library I can hit the sweet spot of fast updates and needed accuracy.