Proper system condition in mozzi_pgrmspace.h

[pschatzmann]

While defining a new kernel I was stumbling over the following:
There is a condition for #if IS_ESP8266() || IS_ESP32() and in the
and in the #else we have some logic where I am not sure for which processors it applies.
I would really like to have a specific list here and a proper #error in the else case so that when somebody is porting to a new environment he gets a proper error message.

Would we know what this list would be ?

[tfry-git]

For the time being it's really all other platforms. ESP32 and ESP8266 are special, here, because their flash memory (aka program space) is externally connected, and rather slow. On these platforms, we don't want to put wavetables into program space, while for the other MCUs that is possible and helps save RAM.

I believe on RPi there is not even any such distinction, so it probably will not matter either way.

If you have an idea who to express this in a more self-explanatory way...

[pschatzmann]

So your saying the else case is currently valid for
#if (IS_AVR() || IS_TEENSY3() || IS_STM32() || IS_SAMD21())

I noticed that for my ARM Mbed and for the RP2040 implementation this section is compiling w/o errors - but I was clueless for quite some days why all my boards were crashing when started with Mozzi!

I think we really need to be more explicit here...after all there is this
#include <avr/pgmspace.h>
which points that this is only valid for avr specific implementations...

I was double checking your statement: the wavetables are e.g. defined as CONSTTABLE_STORAGE(int8_t) which is giving const on the ESP32 and from what I know this will ends up in Flash Memory!

[tfry-git]

I was double checking your statement: the wavetables are e.g. defined as CONSTTABLE_STORAGE(int8_t) which is giving const on the ESP32 and from what I know this will ends up in Flash Memory!

Hm, indeed. I must have simply assumed that by analogy wit ESP8266...

As for <avr/pgmspace.h>, note that both Arduino and Mozzi originated on AVR. When arduino started supporting more platforms, most cores added (among others) avr/pgmspace.h for compatibility with existing code. By the same token, when Mozzi started adding platforms (teensy, then STM32 were the first, AFAIK), there was no need to touch this part. The arduino ESP8266 core also has avr/pgmspace.h, but it does suffer from slow flash (as I had also assumed for ESP32), which is why the #if came into being (IIRC, there wasn't even a separate mozzi_pgmspace.h, before).

Now, you are probably right that at least some of the platforms in the #else portion could (and should, for clarity) be moved up into the #if section. Their pgmspace macros will simply work on const types. But of course that would need to be sorted out very carefully.

but I was clueless for quite some days why all my boards were crashing when started with Mozzi!

But why did they?

[pschatzmann]

It'seems that I was jumping to a conclusion which did not hold. I am happy to confirm that this is not the source of my crashes. So far I did all my audio projects on ESP32 - and this is the first time I am working on any ARM Mbed based boards. I just assumed that they are in the same ballpark like the ESP and hell was I wrong.

So I started to do some measurements:

Function	Nano 33 Sense	ESP32	Pico MBed	Nano AVR
aSin(SIN2048_DATA)	27'000	780'500	27'000	115'000
Output of 1 Pin	53'000	NA	53'500
Output of 2 Pins	38'000	NA	44'500	153'000

• The values are in samples per second - rounded by 500)

I seriously starting to doubt if this is leading to anything useful - when a old AVR Nano is more then 4 times faster then a Nano 33 BLE Sense...

[gnodipac886]

@pschatzmann I was just wondering how you were able to get mozzi to work with a nano ble sense?

thanks in advance!

[pschatzmann]

Sorry for my late update, but I was working on some other projects.
I got most of the compile issues resolved now and MBED devices (RPI and nano BLE) are producing sound now.
I didn't do any extensive testing yet, and I know that USE_AUDIO_INPUT true is creating compile errors...