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 Host PC (semi-hosting) > > You can then move a few jumpers and attach it to the SM1000 as a ST-LINK > debugger/flasher, see SM1000 page "Testing and Debugging" section for links.
Yes, this is an option too. Neither is a particularly expensive option. > However TBH I avoid any actual "debugging" with gdb on the STM32F4. I > get the modules working on a PC first then run unit tests on the STM32F4 > using semi-hosting to track down any differences. Yeah, in the case of tracking down FreeDV 700B though, it might be useful to single-step it until things go pear shaped, although after stumbling on some #ifdef's, I have an idea what might be going on. In the meantime, I'm starting to get together some speech playback goodness. The first step is figuring out how to represent the phrases, so that our voice-over person doesn't have to record separate recordings for every permutation of setting and value. This is being done in a branch for now. http://git.longlandclan.id.au/?p=for-upstream/freedv/codec2.git;a=commit;h=61287ddb5a5e421e3a9b2da49aba7cfba102d2e5 The thought is, the phrases will be simple structs that either encode a length of silence, a run of digits/letters, or point to a Codec2 recording. When I've deduced a recording, I track the frame number, feeding the decoder with frames and upsampling the samples at the other end. Hopefully it won't hurt the CPU too much. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere. ------------------------------------------------------------------------------ _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
