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
