no_std will not compile

[nuuskamummu]

Hello, Excited to try out your lib on embedded, but having some trouble compiling. it seems num-traits still uses std, even if default-features is set to false:

`~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/num-traits-0.2.19/src/lib.rs:23:1	23	extern crate std;	^^^^^^^^^^^^^^^^^ can't find crate

= note: the thumbv7m-none-eabi target may not support the standard library`

[SamiPerttu]

Hi! I think the problem is numeric-array, which is bringing in num-traits with the std feature enabled. I opened an issue there.

[nuuskamummu]

Hi, I looked into it a bit more and came to the same conclusion. Thank you for looking into this so quickly!

[nuuskamummu]

Hello again, I've successfully compiled fundsp targeting "thumbv7m-none-eabi" (stm32f103 cortex M3). This is an 32-bit MCU, so I had to make some alterations to not use 64-bit types for targets that doesn't support those. Perhaps not the cleanest solution, and perhaps you do not have the intention of supporting such hardware. But if you do, feel free to take a look at my fork, specifically this commit. I would be happy to change it to align it to your architecture/structure.

[SamiPerttu]

Thanks for your work. I tried to test no_std by building a project but I see now I should have used an embedded target to catch these issues.

I don't understand the need to redefine 64-bit integers and floating point. Aren't those emulated on 32-bit targets..? If they were to be redefined, then we would also need 32-bit versions of funutd and all the hashing algorithms in fundsp.

[nuuskamummu]

You are correct in that u64 and f64 can be emulated. The main issue I encountered was that core::sync::atomicU64 does not exist on embedded. When I changed atomicU64 to atomicU32, the compiler complained about expecting u32,f32,i32 but got u64,f64,i64 etc. this propagated throughout the entire code base. So what I did was basically make sure that if the target does not support 64 bit types, use 32bit instead. I also made sure the 32-bit function was called from other crates where possible. I cut some corner in some places, where the 64-bit types are used (emulated).

my reasoning was that, if you for some reason would like to support 16-bit MCUs or to avoid emulation since it could bring a performance penalty, the only thing that would need to be done is to add another condition in the target-width module.

[SamiPerttu]

Okay, I see. Then as a first step I'm going to make AtomicU64 optional or remove it altogether. Also add the missing wide flag to disable default features. Then only the lack of an official new numeric-array version would prevent it from supporting 32-bit embedded targets, right?

The next steps would be to see how much the use of 64-bit operations can be reduced, and maybe introduce some feature(s) to that end. Supporting 16-bit sounds crazy, though, I just think FunDSP may be too slow and memory hungry to work well there.

[SamiPerttu]

I removed 64-bit atomics and added the missing wide flag.