sensorium / Mozzi

sound synthesis library for Arduino
https://sensorium.github.io/Mozzi/
GNU Lesser General Public License v2.1
1.05k stars 184 forks source link

Allow to disable twi_nonblock #241

Closed tfry-git closed 1 month ago

tfry-git commented 3 months ago

I had a question about a dynamic way to stop loading two_ Most of my sketches with mozzi don't use a display but one I'm working on does (using the adafruit SSD1306 libary). Could one modify twi_nonblock to load with a define?

Originally posted by @poetaster in https://github.com/sensorium/Mozzi/issues/209#issuecomment-2022396263

Makes sense to me. I suppose the cleanest way will be to inline the implementation into twi_nonblock.h. Then it will be compiled if (and only if) twi_nonblock.h is included. For multi-source-file-sketches, we'd add a define to skip the definition.

poetaster commented 3 months ago

I just recognized I'm working with the version 2 branch. Still, the whole display issue (interrupts being the big killer on the arduinos) seems more difficult to solve simply because of interrupt handling? I've been skipping back and forth too much between rp2040s and nanos (or other 328s).

I've found working between the nano and the rp2040s works best. BTW, using both cores on the rp2040s and consigning one to control updates works really well with the 2 branch!

tomcombriat commented 3 months ago

I've found working between the nano and the rp2040s works best.

There is a big performance gap between the two ;). Indeed, the two cores can be very useful to take care of things which can be blocking, external sensors, screens, while letting the other one "clean" for Mozzi!

poetaster commented 3 months ago

Strange thing. While testing and having just returned back to twi_nonblock being in it's normal state, I compiled an example I had build with the adafruit also with an encoder library in use and it just compiles and runs fine (rp2040). i'm a bit confused :) I have some defines for custom hardware (#define AUDIO_CHANNEL_1_PIN 22) but otherwise it's stock. Not sure I understand the issue in light of this? Once again, using Mozzi 2 git. Not sure if it's relevant but I have the following diff:

diff --git a/internal/MozziGuts_impl_RP2040.hpp b/internal/MozziGuts_impl_RP2040.hpp
index 94a9d52e..41920b48 100644
--- a/internal/MozziGuts_impl_RP2040.hpp
+++ b/internal/MozziGuts_impl_RP2040.hpp
@@ -226,7 +226,7 @@ static void startAudio() {
   pwm_config_set_wrap(&c, 1l << MOZZI_AUDIO_BITS);  // 11 bits output resolution means FCPU / 2048 values per second, which is around 60kHz for 133Mhz clock speed.
   pwm_init(pwm_gpio_to_slice_num(MOZZI_AUDIO_PIN_1), &c, true);
   gpio_set_function(MOZZI_AUDIO_PIN_1, GPIO_FUNC_PWM);
-  gpio_set_drive_strength(MOZZI_AUDIO_PIN_2, GPIO_DRIVE_STRENGTH_12MA); // highest we can get
+  gpio_set_drive_strength(MOZZI_AUDIO_PIN_1, GPIO_DRIVE_STRENGTH_12MA); // highest we can get

I think that was a typo? or cut / paste issue?

poetaster commented 3 months ago

I wanted to ask if you guys need some test hardware? I have a bunch test builds of one (RP2040 based) unit which I would be happy give away. It has the ad/disadvantage of having SDA/SCL in use (well, not necessarily) and it has an encoder so it's a couple of test cases you might not have on the bench (although, after all this time, I'd guess you guys have built it all?)

tfry-git commented 1 month ago

Has been addressed in Mozzi 2.0