Hi Glen, I just verified, the cycle counts for true 16Mhz are within 1% of the 8Mhz operations (but measurements now take half as long :-) )
Danilo Am 18.09.2016 um 07:15 schrieb glen english: > Hi > OK. > well, anyway, decode 1200 (40mS) takes 12.34mS on my kit, and 19.86 > using kiss-fft. > I think you approximated about 14.4mS for a decode 1300 on your kit > > so, I will be interested to see what you come up with using cfft > > My codec 2 codebase is AUGUST 2015 > > cheers > > > > > > On 18/09/2016 2:58 PM, Danilo Beuche wrote: >> 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 >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
