Feel free to ignore, I just realized the STM32F4DISCOVERY is only $22 from
newark!
Anthony
--- On Thu, 3/11/11, acutler22 <[email protected]> wrote:
From: acutler22 <[email protected]>
Subject: Re: [Freetel-codec2] working real-time implementation on ARM Cortex-M4F
To: [email protected]
Date: Thursday, 3 November, 2011, 5:22 AM
I'm not sure if the hardware is exactly what you're looking for, and of course
it's different than his dev board. But at $25 with a 700Mhz cpu and the
instruction set of ARM11 it's some cheap horsepower.
Anthony
--- On Thu, 3/11/11, acutler22 <[email protected]> wrote:
From: acutler22 <[email protected]>
Subject: Re: [Freetel-codec2] working real-time implementation on ARM Cortex-M4F
To: [email protected]
Date: Thursday, 3 November, 2011, 5:19 AM
There is a fully-featured, extremely powerful ARM based computer that will
be available soon for $25: http://www.raspberrypi.org/
Its called "Raspberry Pi" and is being developed as an inexpensive learning
platform for students to learn programming, computer hardware, etc.
The specs are impressive for the $25 "model A" version:
http://en.wikipedia.org/wiki/Raspberry_Pi (and their FAQ)
System-On-a-Chip: BCM2835
CPU: ARM1176JZFS
RAM: 128MB
GPU: IBroadcom VideoCore IV
Video output: Composite, HDMI
Audio:3.5mm audio out, HDMI
On-board storage: SD/MMC/SDIO memory card slot
USB 2.0: 1 port
Voltage: ~7vdc - 23vdc
wattage: 500mW to about 2W
max
They're going to be shipping later November/December.
Anthony
--- On Wed, 2/11/11, David Rowe <[email protected]> wrote:
From: David Rowe <[email protected]>
Subject: Re: [Freetel-codec2] working real-time implementation on ARM Cortex-M4F
To: [email protected]
Date: Wednesday, 2 November, 2011, 3:35 PM
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
------------------------------------------------------------------------------
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
