Hi Glen, I would not worry to much: - Maybe gcc 5.4 vs 4.9: difference is ~-20% (depending from which end you are looking). It is a lot but not unexplainable.
- Maybe it is my test data. I don't know how much jitter in the kiss_fft algorithm is, when different data is presented. I am running "artificially" generated audio input (digitally captured codec2 frames from a single 750Hz sine way also generated digitally).- - Maybe it is my strange way of running the mcHF firmware: the mcHF Hardware has a 16Mhz XO, but the discovery board which I have here for testing has a 8Mhz XO. I didn't bother to reconfigure the PLL. So everything takes twice the time. If the flash would asynchronously coupled, which I doubt (otherwise no need for explicit wait state settings), it would have an influence. But here I am quite sure, this is not the case. If the caches are asynchronous: Maybe. Maybe I should remeasure with fixed PLL setup so that the processor runs at true 168Mhz. Will do that later and get back with updated numbers. Danilo On 18.09.2016 06:35, glen english wrote: > Using environment Rowley CrossStudio for ARM 3.6.4 . GCC 4.9 > > using cycle counter (yes) > > interrupt overhead : (irrelevant, most likely in my setup) (asm) irqs > only set off flags... > > for kissfft 5ws F4, I wonder why you have 112500 cycles and I have > 141000. Something for me to look at . > > hmm > > -O2 but I also have a bunch of debug symbol stuff in there dunno I think > it is only symbol data at DB2 which pushes up the image size. > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2