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
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. 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!
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.