Starting with DSP - CHIBIOS

[giancarlo]

Posted on November 12, 2013 at 16:38

Hi all,

i would like to start programming some DSP application with my board (STM32FDISCOVERY) ,my software framework is Eclipse with GNU Tools Arm Embedded compilers with CHIBIOS / OPENOCD for debugging and programming the micro....where to start? CMSIS DSP is good for my purposes?

thanks for any suggestion

giancarlo

#stm32fdiscovery---chibios---dsp #cmsis-dsp-stm32fdiscovery

[florianaugustin9]

Posted on November 13, 2013 at 16:33

Hello!

the question is if it's useful to take an RTOS for DSP applications. Next thing is that as far as I know ChibiOs doesn't use the STM firmware. The Makefiles of the demo projects I've seen contains this part:

# Enable this if you really want to use the STM FWLib.

ifeq ($(USE_FWLIB),)

  USE_FWLIB = no

endif

I think they wrote their own low level driver. But I just startet with ChibiOS a few weeks ago and I'm a beginner. Therefore I'm not quite sure if all I've written is correct.

What do you want to realise?

Best regards,

Florian

[giancarlo]

Posted on November 13, 2013 at 17:03

Hi Florian,

i have just tested my stm32fdiscovery board with eclipse/chibios programming framework with a simple code (gyroscope data acquisition and visualization of the data on the serial port)...but  i don't know if is possible to use the CMSIS DSP software library in my programming environment... my purpose is to implement some  dsp algorithms to do a lot of more complex things.....

thanks for your suggestion

giancarlo

p.s.

i'm a ''firmware'' beginner too ..... :)

[frankmeyer9]

Posted on November 13, 2013 at 20:57

...but  i don't know if is possible to use the CMSIS DSP software library in my programming environment...

 

Of course it is.

There are many samples, that of the DSP lib are provided by ARM. In case of the ready-made projects of the package, I would stick to the Atollic one's, as this is also an Eclipse-based IDE.

Where my projects needed DSP functionality, I ripped it off ARM's example code.

However, I would keep in mind that the Cortex M is not really aDSP, and only the M3/M4 have some DSP-like extensions. Real DSPs are SIMD cores, executing several instructions in parallel. The TMS320C6xx, for instance, achieves >1500DMIPS@200MHz core clock.

The downside of such real DSP is the toolchain support ...

[dthedens23]

Posted on November 14, 2013 at 16:55

This is a good point the deserves a little more attention.

The Cortex M4 has more registers to push and pop when doing a thread context switch.

Even more so when using the floating point unit.

This will effect the context switch time, possibly interrupt context (for ISR that use kernel services) and threads might need larger stacks.

But there is no reason a thread cannot do DSP work of a certain type.  Perhaps not flat out 100% cpu utilization.  On a M3 or M4 I always use an RTOS, just because I can create reusable threads and most important, unit tests.  Unit tests are hard to do in a supper loop because they effect the loop timing and are hard to couple and de-couple.