Repurposing CMSIS DSPLIB - Page 1
Forum section: electronics / general

author: dannyf
author_rank: Super Contributor
timestamp: February 22, 2014, 04:05:41 pm
content: Has anyone tried to repurpose the CMSIS DSPLib for other (non CM) chips?I took a quick look at it and t he difficulties seem to be 1) 64-bit types and 2) some host-specific macros.It would be interesting to see if something like that can be ported to a different chip, like PIC24.

author: nctnico
author_rank: Super Contributor
timestamp: February 22, 2014, 10:12:27 pm
content: I'd guess the DSP lib also uses assembly to use ARM's DSP extensions. That would be hard to port. If it where easy to port you just can program your algorithm in C because it won't be any faster by using a library.

author: westfw
author_rank: Super Contributor
timestamp: February 23, 2014, 12:47:43 am
content: QuoteIt would be Wrong, though. Probably in violation of the terms under which the DSPLib is licensed.(although I'd expect the DSPLib to be mostly standard "good" algorithms specifically adapted to run well using the instructions available on the ARM. Possibly using assembly, since I doubt whether C can be coerced into doing, say, saturated adds, without getting awfully close to assembly. You would probably be better off starting with a high-level description of the "good" algorithms and porting them directly to your desired cpu.)

author: andersm
author_rank: Super Contributor
timestamp: February 23, 2014, 09:58:28 am
content: Quote from: westfw on February 23, 2014, 12:47:43 amThe copy of CMSIS I have contains the following license, which is a standard BSD-style license. The top-level "CMSIS End-User Agreement" doesn't contain any clauses preventing use on other architectures either, as far as I can tell.QuoteQuoteThe actual DSP library is pure C, but it depends on a number of functions corresponding to ARM CPU instructions that you would have to port. However, there are already pure C implementations for most if not all of them for the smallest devices (CM0/CM3). The biggest job looks like creating a test suite to validate that your port produces the same results as the original version.

author: westfw
author_rank: Super Contributor
timestamp: February 24, 2014, 10:26:37 am
content: Well, cool!

author: tszaboo
author_rank: Super Contributor
timestamp: February 25, 2014, 09:26:28 pm
content: I think it will use the FPU in the CM4F. Or it has SIMD instructions.Anyway, is there anything wrong with the math.h and float.h?

author: dannyf
author_rank: Super Contributor
timestamp: March 16, 2014, 04:17:44 pm
content: Some update:1) I can confirm that the code can be ported to a non-ARM chip - I have a copy running on windows;2) I have tested about 10 examples as provided by ARM, and they all passed.3) I don't yet have a clean way of porting it - what I have is fairly messy.I benchmarked it against some IEEE 1057 routines that I have and the ARM's q31 routines are about 3 - 5x faster than code natively generated by the compiler so the temptation is definitely there.

author: westfw
author_rank: Super Contributor
timestamp: March 17, 2014, 03:18:29 am
content: Which PC compiler are you using? I thought most PC C compilers these days were pretty aggressive about using all the fancy execution modules...

author: dannyf
author_rank: Super Contributor
timestamp: March 17, 2014, 11:15:07 am
content: If you want to port it to a non arm platform, some considerations should be given to the following:- clz: the code from arm uses clz extensively and you will have to find an implementation of it on your target platform. Luckily some compilers have built in implementation for clz. A generic clz will vary greatly in inefficiency.- addressing or paging: the code has tons of tables and compiles to over 100kb on most platforms. On platforms that uses paging, you have to manually address that. This means extensive but simple changes to the code.- numeric constants: arms has 32.- bit int vs 16 on most 8-bitters. So all the constants will need to be written as ul. Simple but extensive, as there are thousands of those items.- flash space: all in, you are looking at over 100kb of flash space for the dsp lib. If your compiler does optimize away unused code, you have to use a large mcu.I think in the end, you will find that porting it to a 32 bit or over chip, arm or otherwise, is a lot easier and practical.