Thanks Peter - that is all very interesting.
Makes me think it is possible for us to come up with a "Codec 2" board
that has a processor like yours, and two mic/spkr ports to enable
simultaneous connection to a headset and transceiver. Get people into
digital voice for < $50.
Re malloc() another approach might be to write a simple malloc() for yr
platform that uses static memory. As it's a one-program operating
system it doesn't have to be too fancy, free() could just be a
so-nothing stub.
Yeah I need to lose that fprintf.....
Cheers,
David
On Wed, 2011-11-02 at 16:50 -0400, Peter Lawrence wrote:
> The development board (STM32F4DISCOVERY) has a DAC with integrated
> headphone amplifier, and I'm successfully sending the decompressed
> bitstream. (I've heard "The Navy attacked the big task force" many,
> many times now.)
>
> The board also has a digital microphone, and my hope was that I could
> use that as a source for the encoder. That would make a compelling
> demo: talk into the microphone and hear the Codec2 encoded and decoded
> result via headphones.
>
> Alas, I haven't had any luck getting it to work. Either my board is
> faulty or there are certain undocumented design assumptions that I am
> not aware of.
>
> The digital microphone outputs a PDM (pulse density modulation)
> bitstream. The development board distributes the digital microphone
> output two ways: its digital output goes to the CPU and a slightly
> filtered version of this digital signal gets routed into an analog
> input on the headphone amplifier.
>
> I've captured the digital bitstream data, but it seems to just be a
> largely uniform random bitstream of 50/50 ones and zeros, no matter
> what I say or yell into the microphone.
>
> I've also tried enabling the analog input into the headphone amp.
> When I blow into the microphone, I can hear noise, but nothing
> meaningfully audible comes out with speech, etc.
>
> Also, that none of STMicro's example code (at least that I found)
> demonstrates the microphone doesn't give me a warm, fuzzy feeling.
>
> As for malloc, its availability depends on the embedded environment.
> malloc() availability implies free(), and that in turn implies some
> sort of memory management. That is a given with a higher-level OS,
> but isn't always a given in a hard embedded scenario.
>
> That I was able to run it largely as-is speaks to how great and usable
> the Codec2 code is. You did a great job. Thank you!
>
> The only real functional change I had to make was an alternate fft.c,
> and that (for posterity) is the following:
>
> static arm_cfft_radix4_instance_f32 cfft_forward;
> static arm_cfft_radix4_instance_f32 cfft_reverse;
> static int intialised = 0;
>
> void
> initialize_fft (int n)
> {
> arm_status outcome;
> outcome = arm_cfft_radix4_init_f32(&cfft_forward, n, 1, 1);
> outcome = arm_cfft_radix4_init_f32(&cfft_reverse, n, 0, 1);
> intialised = 1;
> }
>
> void
> fft (float x[], int n, int isign)
> {
> int c;
>
> if (!intialised)
> {
> initialize_fft (n);
> }
>
> arm_cfft_radix4_f32((isign == -1) ? &cfft_reverse : &cfft_forward, x);
> }
>
> I did forget another modification:
>
> 4) comment out fprintf in quantise.c (also not a given in an embedded
> environment)
>
> If I was going to suggest possible modifications to enable multiple
> environments, it might go something like this:
>
> a) The existing initialization code inside codec2_create() could be a
> distinct function called codec2_init() that accepts a pointer to
> previously allocated memory. codec2_create() would then be a wrapper
> to codec2_init() that added a malloc() call prior to invoking
> codec2_init(). That way, there is backward compatibility with
> existing code using codec2_create(), but malloc deprived environments
> can call codec2_init() directly.
> b) It might be nice to put parameters like FFT lengths in a
> centralized .h file.
>
> Currently, I'm using a commercial product called Rowley CrossWorks for
> ARM. It is a rich IDE based on top of gcc, so I need to work on what
> the underlying cross-compiler calls would be for a Makefile.
>
> Thanks again.
>
> On Wed, Nov 2, 2011 at 3:53 PM, David Rowe <[email protected]> wrote:
> > Hi Peter,
> >
> > That's great work. Does the development board have audio I/O for
> > mic/spkr and possibly connection to a HF radio?
> >
> > Perhaps we could look into a Makefile target for that platform to
> > automatically configure the build system and #ifdef or patch in the
> > changes.
> >
> > Just curious - why couldn't you use malloc?
> >
> > Thanks,
> >
> > David
> >
> > On Wed, 2011-11-02 at 13:37 -0400, Peter Lawrence wrote:
> >> STMicro recently started selling a $20 (US) development board using
> >> their 168MHz STM32F407 microcontroller (an ARM Cortex-M4F).
> >>
> >> I have one, so I ported the Codec2 code to it.
> >>
> >> The Cortex-M4 already has some DSP instructions, but the "F" in M4F
> >> indicates a floating-point unit, and that makes all the difference in
> >> comfortably running Codec2.
> >>
> >> As a result, the changes made to the Codec2 code (2500bps version)
> >> were pretty minimal:
> >>
> >> 1) replace the malloc calls with static variables
> >> 2) replace the KISS FFT routines with ARM's optimized CMSIS DSPLIB
> >> 3) change the FFT sizes from 512 to 256
> >>
> >> Also, whilst not a change to the Codec2 per se, I had to allocate
> >> really large (by embedded standards) stack and heap sizes. (Fail to
> >> do this, and one will waste lots of time chasing one's tail trying to
> >> debug memory corruption issues.) However, the CPU has 128kBytes of
> >> SRAM, so this isn't an issue.
> >>
> >> The FFT implementation in CMSIS DSPLIB:
> >>
> >> http://www.onarm.com/cmsis/download/
> >>
> >> only supports complex FFT lengths of 16, 64, 256, and 1024.
> >>
> >> I initially tried using 1024, but ran into some headroom issues.
> >> Using 256, the entire encode and decode process seems to take about
> >> 7-10 mS for each 20mS audio block.
> >>
> >> STMicro certainly isn't the only Cortex-M4F licensee. TI, Freescale,
> >> Atmel, and quite possible others have (or will have) products on
> >> offer, so that provides some price competition.
> >>
> >> What I like about this is that it means that one could offer a single
> >> chip Codec2 solution, ala DVSI's AMBE-2020. Plus, since Codec2 is
> >> open-source, it should be practical to run additional simple custom
> >> software onboard, rather than pay for and design in yet another micro
> >> as one would with the AMBE-2020.
> >>
> >> ------------------------------------------------------------------------------
> >> RSA® Conference 2012
> >> Save $700 by Nov 18
> >> Register now!
> >> http://p.sf.net/sfu/rsa-sfdev2dev1
> >> _______________________________________________
> >> Freetel-codec2 mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> >
> >
> >
> > ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> > Save $700 by Nov 18
> > Register now
> > http://p.sf.net/sfu/rsa-sfdev2dev1
> > _______________________________________________
> > Freetel-codec2 mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/freetel-codec2
> >
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
