Additional info for building

[qiemem]

Thank you for open sourcing the Ensemble Oscillator! It's been great to be able to dive into the code and start tweaking. To get the code the compiling, I had to deviate slightly from the README, so wanted to post this in case it's helpful to others or is useful feedback.

• I had to use arm-none-eabi-gcc v12; v13 did not work (I believe due to https://gcc.gnu.org/bugzilla//show_bug.cgi?id=109814)
• I had to have arm-none-eabi-newlib as well
• I believe the correct command to build the wave is make fsk-wav rather than make wav (alternatively, the target could be renamed in makefile)
• Finally, I had to remove the && on line 200 of makefile to get it to see the python modules (as, apparently, PYTHONPATH has to be set as an environment variable rather than a shell variable)

[danngreen]

Thanks for the detailed report!

I had to use arm-none-eabi-gcc v12; v13 did not work (I believe due to https://gcc.gnu.org/bugzilla//show_bug.cgi?id=109814)

Yes, I think that's the exact issue here (<cmath> requiring a hosted environment). It'll compile with gcc 13 if I remove the -ffreestanding build flag and changing the return type of main() to int. But, an even more simple solution would be to change the #include <cmath> in numtypes.hh to #include <limits>, since that system header is only needed for std::numeric_limits

I had to have arm-none-eabi-newlib as well

Can you elaborate on how you installed the arm-none-eabi-gcc toolchain? I probably should give more detailed instructions about the installation process. I believe that when downloading on arm's website, newlib is installed along with gcc, but perhaps some package managers don't include newlib.

I believe the correct command to build the wave is make fsk-wav rather than make wav (alternatively, the target could be renamed in makefile)

Good catch! I'll fix that

Finally, I had to remove the && on line 200 of makefile to get it to see the python modules (as, apparently, PYTHONPATH has to be set as an environment variable rather than a shell variable)

Hmm, interesting. Both ways work on my system but I think we can side-step it completely by running the script from the bootloader dir and not having to set any vars.

I created a branch with my proposed fixes: 1-additional-info-for-building. If you have time to try it on your system, and let me know if it fixes all the issues, I'll merge it in (I know my response is a few weeks late, so if you've moved on to other things, no worries!).

[qiemem]

Sure thing!

Can you elaborate on how you installed the arm-none-eabi-gcc toolchain?

I installed via dnf on Fedora 38, so seems likely to be just a package manager-specific thing.

If you have time to try it on your system, and let me know if it fixes all the issues, I'll merge it in (I know my response is a few weeks late, so if you've moved on to other things, no worries!).

The changes to numtypes seem to have fixed the cmath issue with arm-none-eabi-gcc v13, but then I get:

arm-none-eabi-g++ -MMD -MP -MF data.cc.d -O2 -mcpu=cortex-m7 -mthumb -mfloat-abi=hard -mfpu=fpv5-d16 -mthumb-interwork -mfp16-format=ieee -DARM_MATH_CM7 -DSTM32F730xx  -g -ffast-math -fdata-sections -ffunction-sections -ffreestanding --param l1-cache-size=8 --param l1-cache-line-size=32 -DUSE_HAL_DRIVER --specs=nano.specs -std=c++17 -fno-rtti -fno-exceptions -Werror=return-type -Wdouble-promotion -Wno-register  -I . -I src/ -I src/drivers -I lib/easiglib/ -I lib/CMSIS/ -I lib/HAL/  -c data.cc -o data.o
In file included from lib/easiglib/numtypes.hh:7,
                 from data.hh:1,
                 from data.cc:1:
lib/easiglib/util.hh:51:24: error: expected ')' before '<' token
   51 |   Subject(std::function<void(DATA ...)> observer) : observer_(observer) {}
      |          ~             ^
      |                        )
lib/easiglib/util.hh:53:8: error: 'function' in namespace 'std' does not name a template type
   53 |   std::function<void(DATA ...)> observer_;
      |        ^~~~~~~~
lib/easiglib/util.hh:7:1: note: 'std::function' is defined in header '<functional>'; did you forget to '#include <functional>'?
    6 | #include <functional>
  +++ |+#include <functional>
    7 | 
make: *** [makefile:174: data.o] Error 1

gotta love the recommendation to add include functional right after include functional... Anyway, this happens regardless if I install v13 from package manager or from the website, but everything works fine with v12.

[danngreen]

I installed via dnf on Fedora 38, so seems likely to be just a package manager-specific thing.

Thanks! I'll update the readme

The changes to numtypes seem to have fixed the cmath issue with arm-none-eabi-gcc v13, but then I get:

I saw that error once, but I must have not done a clean build because I get it again now.

Looking at the release notes for gcc 13:

Additionally, libstdc++ now respects the -ffreestanding compiler option and so it is not necessary to build a separate freestanding installation of libstdc++. Compiling with -ffreestanding will restrict the available features to the freestanding subset, even if libstdc++ was built as a full, hosted implementation.

This makes it sound like in gcc-12 and earlier we were using a libstdc++ that was compiled for a hosted environment, thus contained <cmath>, <functional>, etc. But in gcc-13 libstc++ is restricted to the "truly" freestanding features (as opposed to features which work in a freestanding environment).

Also, this page lists <functional> and <cmath> as having "partial" support in freestanding.

Digging a bit deeper, I see this in gcc-13 include/std/functional

#if _GLIBCXX_HOSTED
# include <bits/std_function.h> // std::function
#endif

...but the #if block is missing from the same file in gcc-12. So, apparently, the "partial" freestanding support in <functional> does not include std::function. (which also explains that ironic error message)

I guess the best solution is to drop the freestanding flag.
I tried it, it seems identical to the non-freestanding firmware (tested on actual hardware). I'm pushing that plus the README updates.