On 08/25/2014 11:23 PM, Steve wrote: > Maybe replace all the FFT's with FHT's... > > http://www.embedded.com/design/connectivity/4403178/Doing-Hartley-Smartly > > I was also thinking, since you mentioned that the kiss code ran faster > than the ARM library, that maybe speed isn't the defining goal. That > is, if the ARM code is fast enough, and can do inline, then you save a > ton of memory. But then maybe the FHT can get that speed back. FHT > being real only. > > Thinking out loud... > The abbreviation FHT is probably not a wise one to use. The Fast Hadamard Transform abbreviates to the same thing, and is a lot more common. I thought the software was running short on time. Is it also running short of memory?
FHT needs less memory (I think. I don't know a way to get a real FFT's memory down to the memory footprint of an Hartley transform), but the FHT takes more operations than a real FFT done right. That's probably why Googling for the Hartley transform doesn't trawl up a bunch speed demon implementations, while Googling for FFT does. Usually when you find an implementation of Hartley they emphasis their small footprint for use in a small MCU. Regards, Steve ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
