Please hold off the unified HardwareSerial class for now. The need isn't really great, since the inheritance allows any to be used for libraries that want a HardwareSerial class pointer or reference.
I'd like to first focus on replacing the available polling with event responder, and find a way to do the fault handler that doesn't force the linker to pull most of the code for unused ports. Let's do the major refactoring after those are working and stable.
Understood - I mainly did it as to make it simpler to do things like add the API(s) to increase size of send and/or receive buffers. Did not like the idea have having to duplicate the changes in six different places...
Actually make that 7 as Serial6 on T3.5 is the same as 1,2,3,4,5 just uses different UART5, whereas on T3.6, it is completely different subsystem, it uses LPUART0.
The is tucked away in a branch on my fork, so can revisit anytime...
Not sure how you wish to do the SerialEventx functions using Event handler, so will probably watch on that part.
As for Overhead of current stuff, my thoughts earlier were along the line Frank mentioned, again don't know if this makes Sense or goes along the line you are wanting to go. But some of the steps I have thought about trying include:
a) Move all of the default (weak) serialEvent objects out of HardwareSerialX.cpp files and maybe into one simple file that only has these... So hopefully if for example user does not do anything with Serial3, there is no reference to it and as such none of the code is brought in..
So have one file like Serialevents.cpp that has all of these functions:
Code:
void serialEvent1() __attribute__((weak));
void serialEvent1() {}
Edit: Tried this and did not make any code/data size changes... At least in the one program I tried...
b) Have a bitmask that we use in yield to see if any of the Serial objects (that we are interested in) has any input available... Note I would start with hardware serial ports. Probably different for Serial object.
1) Would have a variable in each Serial object which has the appropriate bit to set in the ISR that receives data
2) Update the read method (and clear) to clear this bit when appropriate.
3) Then yield (can simply first test if any bit is set and if not do nothing), else see which bit(s) are set and call the appropriate serialEvent object.
4) Now change the default serialEvent objects to clear that field that the ISR uses to say there is an event, such that our default serialEvent object should only ever be called once...
Again if this sounds interesting, I think there may be a few of us willing to try it out and make a Pull Request.