-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mozzi 2.0 - Start config rework #211
Conversation
This does not actually do anything yet, but I hope the outline is becoming visible. Plan is to finish this outline for AVR, first, then adapt MozziGuts, and get it to compile for AVR, then follow up on the other platforms.
Fix frequency offset for AVR
start adding porting table
Commit known to be broken. The larger part of this is actually moving around / merging lots of (duplicated) information.
Fix some bits in AVR in reaction to that. Seems to work overall, however.
Start porting STM32duino.
(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. |
@@ -0,0 +1,44 @@ | |||
/** This file keeps a list of named configuration values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have to say that, for the time being, I do not really get why this file is useful, I might be a bit slow… Is it anticipating for the single compilation unit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a way, yes: With a single compilation unit, it will be possible (but not necessary) to specify config options directly at the top of a sketch. Since that needs to happen before including MozziGuts.h, we need some place to put the "labels" for the options.
Memory usage change @ eab7b15
Click for full report table
Click for full report CSV
|
Fix of mozziAnalogRead for Renesas
Memory usage change @ 5787dfd
Click for full report table
Click for full report CSV
|
Memory usage change @ e40401a
Click for full report table
Click for full report CSV
|
Memory usage change @ 47e990e
Click for full report table
Click for full report CSV
|
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 @ 730a74a
Click for full report table
Click for full report CSV
|
I think it looks good!
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! |
FIXED #bb26c0a The other core seems to be okay (to be completely confirmed). |
Memory usage change @ bb26c0a
Click for full report table
Click for full report CSV
|
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 ;). |
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) |
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:
Testing matrix - for most boards I intend to test the default mode, only. Later, additional configs will at least be compile-tested outmatically (depends on the single compilation unit work).