I recall reading about an option to run from RAM, however we only have 128k+96k or RAM and the code already 500k. Flashing takes a few seconds so I've never really noticed it.
I use software engineering practices (as per my email on 24 Sep) that mean 99% of my debugging is done before the code gets near the SMT32F4 target. You don't want to be sorting out DSP bugs on a bare metal platform. Haven't found a use for the CMSDSP libs to date. If we did use them we'd also need them on the PC side to ensure identical behavior. Some high level optimisation of the C code has been enough so far. Been many years since I did any DSP assembler. Getting away from that is the whole idea of using a modern, powerful uC. Same code runs on your PC as your uC. - David On 25/10/15 19:13, glen english wrote: > On the large micros like STMF4, for fast development/ compile run cycles > I run my entire executable out of RAM.... only transitioning to flash > when I have to disconnect the debugger. > > Optimized DSP code from the CMSDSP libraries (which I re compile) > certainly takes a performance hit, but not too badly. > > If you are not already using the optimized , ST hand coded in assembler > DSP libraries, I'd be surprised if anyone could do better. > > g > > On 25/10/2015 7:38 PM, Stuart Longland wrote: >> Hi David, >> On 25/10/15 11:39, David Rowe wrote: >>> Re debugger suggest a $20 STM32F4 Discovery. It has a debugger uC and a >>> STM32F4 on board. Standalone (without the SM1000) it can run STM32F4 >>> unit tests, using stdio.h functions to/from a Ho > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
