HardwareSerial/UartClass hierarchy

[MX682X]

I was looking a bit through the Print virtual function dependencies and I noticed that UartClass is inheriting from HardwareSerial, which is inheriting Stream. This requires all major functions to be virtual and thus always compiled. I think it would make more sense to make the UartClass to inherit from Stream, while HardwareSerial is inheriting from UartClass. Or am I missing something?

Furthermore, it should be possible to make all functions except peek, read and write non virtual, since they are never actually used in Stream nor Print. And virtual functions are only useful if they have to call something in the inheriting class, as far as I know.

Also, does anyone have an idea why uint32_t _startMillis in the Stream Class is a global variable while it is used only locally?
(P.S. should this variable be removed, it is likely that the UART ISR assembly has to be adjusted, because afair, the variables, that are inherited, are put above the own class variables)

[SpenceKonde]

Thanks for that PR - There is one little problem. Guess what I've just been doing? Modifying UART.cpp, UART.h, UART_constants.h and UART_swap.h x_x

So we're going to have a merge conflict here.

I love the sounds of this - I hate the useless virtual functions with a burning passion. but I don't understand C++ so I had no idea how to get rid of them (I can make inline assembler walk on it's side, but one could argue that anything C++ I write should be "Copyright stack overflow" - or Hans (mcudude)) .

Also - wait, what?! You don't have any tinyAVRs handy? I'm so sorry!

Email me you mailing address and preference, I'll send you your choice of any tinyAVR board (or bare chip if you prefer that). And a DIY AVR64DD28 breakout w/chip (but no other components, I'm away from home and don't have any through-hole caps with me - I only brought my frequently used SMT parts; I'd send you an Azduino Nano DB with a DD in place of the DB, except I don't have any of those PCBs with me, and won't until end of week). You've contributed a lot to these cores, all in areas that I consider to be deep magic.

[SpenceKonde]

The modifications were to:

• Support the new ATPACK headers (they renamed almost 1000 rarely used constants, the fuckers. DxCore required almost 4000 lines of backwards compatibility code added to core_devices to work with older toolchains and give deprecated warnings if the old names are used on the current version, which will be azduino5.)
• Support generic autobaud.
• Fix a bug in the inline assembly that as far as I can tell would render RX nonfunctional except under ideal circumstances)
• Add the missing SERIAL_EVENT_RX constant.

Buy yeah I'd very much like to get an improvement that got rid of those unneeded virtual functions into 1.5.0. which will be coming out very soon. There's not much left to do for it!

[MX682X]

Also - wait, what?! You don't have any tinyAVRs handy? I'm so sorry!

Don't worry, I have some 1614s and a couple of breakout boards, but I hate wiring them up to a debugger and UART bridge. It is just so much easier to use a Curiosity Nano with an 128DA48

[MX682X]

The conflict ain't big though. Just check the differences. Basically just two lines on the UART.h file. a few more on the Stream.cpp.

I don't underatand like 70℅ of c++ either, but we are using only like 50% of it's feature set, so I guess it's alright. But to give you a better understanding of the relevant part of C++:

classes are like fancy, organized structs that contain a bunch of variables and function pointers.

Then there is the inheritance that has multiple names for the classes: parent/child or base/derived. With class UartClass : public HardwareSerial UartClass is the child and HardwareSerial is the parent. Simplified, it means that all functions and variables of the parent are available to the child. Also from the grand-parents (Stream in this case) and grand-grand Parents (Print in this case). This feature is useful when you want to create a common functionality like with Stream and Print that is also used for Wire.
The variables are inserted in front of the child's variables.

Sometimes it is neccessary to call a function in the lowest derived class (see write()). This is achieved with the virtual keyword. By declaring a virtual function, the compiler will try to link it to the lowest derived class, if it exists. If there is no overwrite, it uses the original implementation of the parent class.
The programmer can tell the compiler that there is a virtual function that has to be overwritten by adding = 0; at the end.
Apparently, that also forbids the compiler to optimze it away.

That's all I did in this PR basically (besides improving Stream). Just skipped the HarwareSerial class that forced all the API functions.

[MX682X]

While you are working on improvements, I do have a feature request; How about a swReset() function? I hate to look through the datasheet all the time to figure out which two registers to set to use the software Reset.

[MX682X]

Also, I've fnished testing my changes. I've only found one Arduino library so far that includes HardwareSerial, but it seems to be working so far. You should give it a try. I did not find another library to test with in a reasonable time.

P.S: I've stumbled accross your comment in the USART.h file:
// tinyAVR 0/1-series has 2 bits devoted to RS485, supporting normal (00), RS485 with XDIR driven to control
// an external line driver (01), and some other mysterious mode (10) the function of which is unclear. There is
// evidence that this poorly documented feature is also present in other hardware, and was only removed on paper.
I've checked the Microchip studio I/O debugging menu - there the 10 is referred as RS485 internal drive (and it is even seems to be working) opposed to 01 - external drive