You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think you might have noticed by now that I really like your library.
And at this point I'd like to give something back to you.
Now I have some decent experience designing libraries and software in general and I have a few suggestions (that I'm all willing to implement myself):
Use inheritance for the specializations:
This is a fun one! Now I like that you separated the package code into its own class. That's good design. However there is one (fairly) big flaw with how you're doing it right now: The classes don't have anything to do with eachother.
So my suggestion is to make use of inheritance. You have the abstract Packet class (maybe it should be renamed?) that has the pure virtual functions readAvailable (how many bytes are available to read or maybe a plain boolean function is enough), readByte (reads the next available byte), writeBytes (writes the bytes) and printDebug (which prints the debug message (may be just virtual with a default implementation that does nothing)).
This allows the library to be extended easily to any other hardware platform and the base class can be made without any external dependencies so it can be used for the Linux/Windows variant of the library.
Make the CRC library compile time constant.
That means making sure that the library doesn't need any RAM and that everything is written in the ROM (constexpr magic at play here ;) ). Now with a preprocessor flag I could toggle between a ROM lookup, RAM lookup or live calculation.
And lastly let's abandon using class instances for this. My suggestion would be to use only static members in a class. If you really want the size and polynomial to be configurable that can be achieved with templates.
Now if you aprove of these suggestions I'll get on to implementing them.
The text was updated successfully, but these errors were encountered:
I remember thinking about doing inheritance before the big update and decided against it, probably because I completely forgot about virtual functions. I think, however, I can implement inheritance for at least the UART portion of the lib - I'll have to do more looking into SPI/I2C to see if it'll work there too (I assume it'll work, but I want to make sure).
As for the constexpr tip, unfortunately the IDE uses C++11. Because of this, the compiler won't allow you to use for-loops with constexpr functions, which is needed to create arrays (see here). If I could, I would reimplement the CRC lib to evaluate at compile time, but with this complication, I'd rather stick to how I have it now (unless you have another idea).
I think you might have noticed by now that I really like your library.
And at this point I'd like to give something back to you.
Now I have some decent experience designing libraries and software in general and I have a few suggestions (that I'm all willing to implement myself):
This is a fun one! Now I like that you separated the package code into its own class. That's good design. However there is one (fairly) big flaw with how you're doing it right now: The classes don't have anything to do with eachother.
So my suggestion is to make use of inheritance. You have the abstract
Packet
class (maybe it should be renamed?) that has the pure virtual functionsreadAvailable
(how many bytes are available to read or maybe a plain boolean function is enough),readByte
(reads the next available byte),writeBytes
(writes the bytes) andprintDebug
(which prints the debug message (may be just virtual with a default implementation that does nothing)).This allows the library to be extended easily to any other hardware platform and the base class can be made without any external dependencies so it can be used for the Linux/Windows variant of the library.
That means making sure that the library doesn't need any RAM and that everything is written in the ROM (
constexpr
magic at play here ;) ). Now with a preprocessor flag I could toggle between a ROM lookup, RAM lookup or live calculation.And lastly let's abandon using class instances for this. My suggestion would be to use only static members in a class. If you really want the size and polynomial to be configurable that can be achieved with templates.
Now if you aprove of these suggestions I'll get on to implementing them.
The text was updated successfully, but these errors were encountered: