Skip to content
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

support multiple startup hook functions for Teensy 4.x #734

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

A-Dunstan
Copy link
Contributor

@A-Dunstan A-Dunstan commented Feb 2, 2024

If multiple libraries both override the same startup_*_hook function (or a library overrides it when a sketch wants to use it), they can't be used together since it causes a duplicate symbol error.
This PR makes arrays for each startup hook stage (early/middle/late) so multiple functions can be registered to run. Any function can be registered as a startup hook by using the REGISTER_*_STARTUP() macros to insert them into the appropriate array.

The original hook functions (startup_early_hook/startup_middle_hook/startup_late_hook) are still called for backwards compatibility with existing code.

@PaulStoffregen
Copy link
Owner

Not going to merge this. I want to write a brief explanation rather than simply reject without any explanation, but I also wish to avoid giving the impression this is up for debate. It's not. So with that in mind, here's why.

These hook functions are global function names expected to be in the user's program, much like setup() and loop(). Libraries don't get to install their own setup() or loop() function. For libraries with a begin() function, the user calls the begin() function from setup(). Likewise with startup hooks, if something needs to be done, it needs to be explicit.

The earliest access libraries are expected to use is C++ constructors. Even then, the common design pattern in Arduino libraries is a constructor which only initializes variables and give a begin() function to actually start working. The purpose of these startup hooks is to give access to the user's program early, before libraries have any opportunity run.

@A-Dunstan
Copy link
Contributor Author

Teensyduino ships a library (Snooze) that does exactly what you say libraries shouldn't do, so obviously exceptions apply.

@PaulStoffregen
Copy link
Owner

Yes, long-term Snooze and perhaps the startup code needs to be updated. Snooze should not be using the startup hooks.

@h4yn0nnym0u5e
Copy link
Contributor

Slightly off-topic, but there are also a fair number of constructors in the Audio library which directly call their class's begin(). I suspect it doesn't matter too much for the input and output classes which essentially have exclusive access to their hardware, but it did affect AudioEffectDelayExternal quite badly, which uses SPI.

Solving this for the Audio library is non-trivial, but it's possibly another thing to consider on the long-term list!

@PaulStoffregen
Copy link
Owner

Yes, yet another thing for the long-term list! In fact, on my long-term list (since before Teensy 4.x) for audio is a much better controlled startup when multiple input and output sources are used. A topic for another day...

@h4yn0nnym0u5e
Copy link
Contributor

Happy to contribute to that if I can ... best on some other thread, of course

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants