cores
cores copied to clipboard
PaulStoffregen
support multiple startup hook functions for Teensy 4.x
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.
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.
Teensyduino ships a library (Snooze) that does exactly what you say libraries shouldn't do, so obviously exceptions apply.
Yes, long-term Snooze and perhaps the startup code needs to be updated. Snooze should not be using the startup hooks.
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!
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...
Happy to contribute to that if I can ... best on some other thread, of course