Closed tfry-git closed 7 months ago
Memory usage change @ 862853214a1f6c3388ce164410031ecce1577160
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
Ok, there are rough edges left (regarding documentation), and testing is still needed, but the basic shape is complete.
Sorry that it turned out to be such a huge diff.
Some notes:
Alright, will try to have a look at it soon. Will start with having a look to try to understand what has changed and will then complete your testing matrix, also with EXTERNAL_AUDIO
. I see that you managed to save up some RAM in the process!
For instance most ports used to - unnecessarily - set up a timer at audio rate, even in external output with bypassed buffer
Which are these exactly? They are not of platforms which work on an external_buffer if I reckon correctly (RP2040 and ESP?)
Allow a bit of time for the testing ;)
PS: if you have a bit of postpartum depression, the FixMath2 will probably be ready for your comments soon ;)
I see that you managed to save up some RAM in the process!
I believe, that's the analog read code (now more properly disabled on platforms that don't implement it).
Which are these exactly? They are not of platforms which work on an external_buffer if I reckon correctly (RP2040 and ESP?)
Frankly, I didn't keep track. Might have included (some of) those, too, though, which is not all that surprising, since the logic was a bit difficult to parse (external being orthogonal to the output mode, and BYPASS_MOZZI_OUTPUT_BUFFER again independent from that). Some ports remembered to set up an audio rate timer when external output was set (and others forgot), but did not check for bypassed buffer, there. I'm actually rather happy that this logic is flattened out, now.
Memory usage change @ cd05838f105ddb1e971db7e03e1c603da71fc831
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
So far only had time to look briefly, looks quite neat but haven't done any testing yet.
Point of organisation: if I produce some config files for some other configurations, should I had them to this? If yes, how do you prefer to do? Me merging straight into devel/Mozzi2
or requesting a PR from another branch?
So far only had time to look briefly, looks quite neat but haven't done any testing yet.
Take your time, I won't be all that fast, the upcoming days, either. I also intend to check at least some of those boards - and take a more serious look at your fixmath, of course.
Point of organisation: if I produce some config files for some other configurations, should I had them to this? If yes, how do you prefer to do? Me merging straight into devel/Mozzi2 or requesting a PR from another branch?
I don't think we need to overdo it with PRs. Commit right away. However, until this is merged, it's in devel/config_rework. devel/Mozzi2 is just the target branch.
Memory usage change @ 1fc91cde4b615fa4f65860a4be7a96668859d7a7
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
The amount of work there is impressive!
Starting testing on the RP2040 (it was on the breadboard)… Worked straight away in standard config, minor correction to get the I2S to work.
Just a question on documentation: to find the default settings, and find their names, I had to go to internal/config_checks_rp2040.h
which I found quite fast especially as I knew what I was looking for. But I wonder if that's a good place to store these settings: internal
sounds like something standard users will not look into at first glance, and checks
sounds like checks, not config. I wonder if splitting these files into one check
actually checking the config is correct and including a config_default_rp2040.h
(or another name as not all the parameters listed are used as default) which would be more accessible. This file would actually be "the" and a good reference for all the modes and config available for a given platform? Split into section with, for instance the DMA settings said plainly (with a warning on changing them).
Or maybe the plan would be to make a config file for every possible configuration?
"internal" may not be the best name, but as a side-quest, I'd like to separate headers that are meant to be used in Mozzi, internally, from those that would actually be included in a sketch. And even if these are config-related, they are not a config to include in a sketch (contrary to the config examples), so that's how I ended up with "internal".
I also sort of hope that standard users will not have a need to actually read these files, because the defaults are - and hopefully remain - documented (probably we should place links to that documentation quite liberally). Actually, I must admit, they may not be as pleasant to read, as I had hoped, importantly, because I could not find a workable one line (macro) way of saying: "if XY is not defined, then define it as Z".
As for separating the "checks" from the "defaults", I found those somewhat interrelated, such as "if mode is PDM via I2S, set default pinout to xy, and enforce that only mono is supported". It is entirely possible to split that, but I'm not immediately convinced that this would help readability, overall. No objections to simply renaming config_checks_x.h to config_default_x.h, though. It may also be possible to structure these files better.
Or maybe the plan would be to make a config file for every possible configuration?
Yes, I think that's actually the way to go (mid-term). Ok, perhaps at least one config example per platform, and possibly as much as one per audio mode per platform. Part of the idea would be that the config examples should be ones that are actually known to work. Sort of as an intermediate level between "stick with the defaults", and "here's a list of all the things you can customize".
Ok, perhaps at least one config example per platform, and possibly as much as one per audio mode per platform. Part of the idea would be that the config examples should be ones that are actually known to work.
Sounds good. I think it will very depend on how the documentation is done in the end and I will try to take my share in that.
(I was going to ask about porting made easy for other contributors but just saw the template actually…)
Noting here something I just noticed, and which could (or not) be a bug but certainly worth documenting somewhere.
If ones wants SPI
to work one the same core than Mozzi, then SPI.begin();
and SPI.beginTransaction();
should be placed after startMozzi()
. Did not investigate much why…
(On RP2040)
Memory usage change @ 76be1a17e8759959967e8a7853e5cd87947e16e3
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
(Have to say I am quite amazed that you manage to pull such a thing…)
I am leaving comments in the code as I go, hope it is visible. And commits when I see things while testing. I might try to through it all after all the testing I can do is done but I like starting with the experimental approach! I am also updating your initial post on the go when I test a new config.
Memory usage change @ eab7b157c94bb31a117c14e1f7987a63021cf5f9
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
Memory usage change @ 5787dfd015d8eaa7fda12c0170dcd562bf29e712
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
Memory usage change @ e40401a5d6c9fe4e01dbaae69acfdc8436af2751
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
Memory usage change @ 47e990e006befec39dc7d92e300f9f6ba11d3ad2
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
Ok, so I finally tested with STM32 (both cores), ESP8266, and ESP32 boards. No fixes were needed, so I take that as an encouraging sign. I never owned an SAMD-based board, so I guess we'll have to skip testing that on actual hardware.
As things tend to go, these last few bits have taken far too long, and I'm afraid, I may have lost track a little, but I believe all known problems and concerns ought to be fixed/addressed, now? If not, please remind me. Otherwise I'd like to merge this (into the Mozzi2-branch) soon.
Memory usage change @ 730a74a6735ba7fe18f606f4de4eeb7e2a278824
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
I think it looks good!
I finally tested with STM32 (both cores),
Sorry, I planned to do that but got completely dragged into something else in the meantime (and I never know which one of my stm32 are actually working… Sourcing them was quite hard at some point, do not know how it is now). Maybe allow me a couple more days to test the external on STM32 (I think I tried external on AVR, do not know why it is not in the table), and then this is good to go I think!
~Quickly reporting: STM32 using the Maple (Clark) core does not seem to work in external mode (too bad, that's what I am using on some legacy hardware…).~
FIXED #bb26c0a
The other core seems to be okay (to be completely confirmed).
Memory usage change @ bb26c0a9af0cba6b87949da5564343ac38443a8c
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
STMicroelectronics:stm32:GenF1:pnum=BLUEPILL_F103C8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:mbed_giga:giga |
:green_heart: -136 - -64 | -0.01 - -0.0 | :green_heart: -32 - -16 | -0.01 - -0.0 |
arduino:samd:adafruit_circuitplayground_m0 |
:green_heart: -100 - -92 | -0.04 - -0.04 | :green_heart: -20 - -16 | -0.06 - -0.05 |
esp8266:esp8266:huzzah |
N/A | N/A | N/A | N/A |
rp2040:rp2040:rpipico |
:green_heart: -16 - -8 | -0.0 - -0.0 | 0 - 0 | 0.0 - 0.0 |
All good for me!
Wonderful, I'll merge into devel/Mozzi2 then, before you get a chance to change your mind ;-)
I just wanted to test as much as possible with the hardware I have available, sometimes I just need a small push ;).
I just wanted to test as much as possible with the hardware I have available, sometimes I just need a small push ;).
That wasn't meant to criticize, it rather felt like I had been the one to drop the ball, and now I was eager to finally merge this. (I also tend to need a small push, BTW)
That wasn't meant to criticize
I did not take like that at all ;)
Shall we delete that branch? Or maybe wait a bit to see how it does?
It's generally safe to delete branches after merging (full history is still available, anyway). I'm just no good at tidiness...
See #205 .
Status: Basically complete.
Some tasks not to forget: