Prototyping CMSIS code on an ubuntu machine

Based on the thread CMSIS DSP library support (arm_math.h) I’ve been able to get some custom arm_math.h code running on my Daisy Patch ( which is great!)

Would love it though if I could prototype my CMSIS code just on my Ubuntu box ( to avoid the firmware upload for each test ). Though my c++ is ok, I’m not so good on the compiling for embeded side of things…

I have a minimal example of trying to compile a standalone app using some arm_math.h in this repo GitHub - matpalm/arm_math_compile_test but am stuck. Any help would be appreciated.

TL;DR is the following… ( though the github repo has the full info )

$ arm-none-eabi-g++ \
 --specs=nosys.specs test.cpp \
 -I./libDaisy/Drivers/CMSIS/Include/ \
 -I./libDaisy/Drivers/CMSIS/DSP/Include \
 -DARM_MATH_CM7
 
In file included from test.cpp:2:
./libDaisy/Drivers/CMSIS/DSP/Include/arm_math.h: In function 'q15_t arm_pid_q15(arm_pid_instance_q15*, q15_t)':
./libDaisy/Drivers/CMSIS/DSP/Include/arm_math.h:4954:19: error: '__SMUAD' was not declared in this scope
 4954 |     acc = (q31_t) __SMUAD((uint32_t)S->A0, (uint32_t)in);
...

I realise this is not directly a Daisy specific question; but it is in service of some Daisy firmware :slight_smile:

Cheers,
Mat

This looks like you’re trying to compile ARM-specific code to run on a non-ARM CPU.

Ahha, thanks @tele_player, this is true; iIm running on a AMD Ryzen desktop. I had some vague idea that I could compile this for my desktop, but not sure where that came from… Have been using the CMSIS python package for prototyping, which is useful, but my goal is to be able to have a quick turn around time on developing a lib that I can later drop into a Daisy firmware.

Maybe I need to investigate emulation (?)

My feeling is that this is a waste of time. For faster upload, use STLINK.

I’m also skeptical on the usefulness of CMSIS, except possibly for producing code for a variety of Cortex processors.

1 Like

Good point re: STLINK, was using it for awhile years ago but then lost my device during a move.

I have some vague motivation for CMSIS for some other work I’m starting, but can see how it’s overkill for just work with the Daisy…

Maybe. Another possibility would be running your ‘development machine’ on an ARM processor like a Raspberry Pi 4 8GB or any of the ‘PC like’ ARM machines that have begun to appear. And you could use an ‘abstraction layer’ to deal with differences in Codec interface and other differences between RPi-Linux and the Daisy’s more ‘bare metal’ approach.

I think that “vague idea” is probably correct, C++ ‘generally’ is portable between ARM and x86 with a recompile, but that “generally” could be one big can of worms!

From a practical standpoint this may very well be the ‘best’-easiest solution - it depends on what you view as the ‘problem’ and what the goal is.

I can’t wait for RISC-V to make all these cross-compile issues history! :sunglasses:

1 Like

oh yeah, also… I think somebody has ported DaisySP to the x86-PC-desktop - if that helps I (or you) could probably find it on this forum…

1 Like

C++ is very portable, but wrappers for hardware ARM-specific DSP op codes aren’t portable.

You’re kidding about RISC-V, right?

Well, right, but ‘ha ha, only serious’ - I do think it’s plausible that in a decade or three RISC-V will have taken over as the dominant Instruction Set for a wide range of computers from Toothbrushes to Supercomputers and everything in between. That’s what RISC-V was designed for, per the “RISC-V Reader”. And it could be faster for an individual that wants to go there, like me.

Note that I said plausible. It’s certainly not assured - it’s ARM’s market to lose.