bfin profiling

[electropourlaction]

faster sample I/O to enable more delays and reverb like timbres. I don't have any answers at this moment but willing to help.

[catfact]

is this different from issue #62? if not, can we just keep the discussion there?

[electropourlaction]

This issue would be about SDRAM access when audio processing is enabled, and related stuff.

[catfact]

i still don't quite know what you mean. you want SDRAM access in general to be faster somehow?

[electropourlaction]

yes, if that makes any sense.

[electropourlaction]

I did some rethinking, this should really be renamed to be about setting up a profiling tool for the bfin, maybe oprofile, or other (some ideas where mentioned here already http://llllllll.co/t/aleph-how-to-gauge-if-dsp-is-powerful-enough-for-x/718 ) that makes it possible to see calculation time per function.

[electropourlaction]

renamed topic, will have a look at this later (autumn probably), http://blackfin.uclinux.org/doku.php?id=linux-kernel:oprofile

[catfact]

... but we're not running a uclinux kernel... looked into it early on, but the overhead is a little much

[catfact]

if you just want to get time spent in a specific program, i would check out the Cycle Counter system registers (in section 21 of the blackfin programmers reference manual) or the real-time-clock. they are already set up to record execution cycles in CRT startup. it should not be hard to read the cycles at begin and end of function you're profiling, and report that value in a parameter read.

this link talks about it: unfortunately the source code links are dead(!) but you get the idea:
http://blackfin.uclinux.org/doku.php?id=making_the_blackfin_perform

alternatively, you could set up the RTC (hardware clock) at startup and use that.

as far as in-depth call stack analysis, i don't really think that's likely to happen in any sort of automatic way for baremetal GNU/GCC programs. of course if we were using VDSP we'd have access to their profiling tools.

[electropourlaction]

thanks for the advice! I will need to take some time to educate myself on it, but interesting stuff nonetheless!

[electropourlaction]

crazy crazy price tag but I'm just curious, would it be possible to use VisualDSP++ 5.1 for bfin executables on the aleph? or is this a kernel issue again? sorry for still being so very ignorant on these matters, anyway it sure looks interesting to have built in profiling, optimizations(!), WAV PCM libraries, etc.

[catfact]

for sure, it would work.

but seriously, you can probably get whatever data you want by polling the execution counter. doubt that VDSP profiler stack is doing much else than that.

and bfin-elf-gcc knows a lot of good tricks too! but one needs to give it half a chance, which i never did.

i need to do a tiny bit more testing and then share the block-processing framework at least with people who want to write new modules. no sense writing per-sample code and then rewriting it later.

[ngwese]

i'd certainly be interested in the block processing code...

[catfact]

@ngwese i just pushed my test branch and made a longer comment on the relevant issue thread (#69)