Found a way that appears to work to detect if a sketch has our default serialEvantX functions, and that the users code has not implemented their own. Before on SerialX.begin() I would add that serial ports code to table of function calls to do the if SerialX.available() call serialEvernt..
But I now have a hacked up version where each of the event functions are in their own source file, along with a variable that is defined. Elsewhere I have those same variables defined with an attribute of ((weak)), so if our default implemention is pulled in it is defined with a value of 1, if the weak version is used because the user has their own implemention, then it is defined as a 0... So I can detect this at the begin method and only add the code to do the checks in yield if the user implemented it.
WARNING this also brought in changes for using XBar pins for CTS and RX pins... As I did not wish to split back out and have you maybe have to manually merge.
A couple of minimalist changes.
systick_isr - By default it does nothing with the event responder.
Only if the user calls the attachInterrupt member of EventResponder will it install the version of the ISR that checks the list for any active ISR event Responders.
T4 Yield - try to keep bitfields for things yield should test
Make it such that yield hopefully can test to see there is nothing to do and returns quickly.
There are some interesting limitations, that is that the serialEvent
handling code. Both for USB and hardware Serial can only remove it self
if the default eventHandler is called once, as I don't know anyway to
detect if the default code (weak linkage) is included or if it is a user
version. So waits until called to remove it self from active list.
Sketches can force this by simply calling the event method right after
calling begin on the serial port.
When you do a timer.begin(650) it actually triggered 652 ms from your current time. Did minimal update to see if delay time < 2 set to zero else decrement by 2...
Two issues:
if you called begin or begingRepeating while still in waiting queue, it would create circular state (code did not set state to waiting)
If you called begin on one in active list, it would first remove it from list, but did not update the timings for items left as the timing all rely on items before it
When the run time issue adds an item back in to the list, it adds the item at the appropriate time, however it does not decrease the time of the item after where it was to take in account how much time the new item will take before we that next item starts to process it's _ms time
Kurt Eckhardt
Defragster
PaulStoffregen