XBeeAddress64 improvements #6
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds:
- A constructor that takes a single uint64_t variable. This allows
implicitly converting integers to XBeeAddress64 values, so these will
work:
XBeeAddress64 dest = 0x0;
request.setAddress64(0x0013A21234567890);
(note that the latter also requires some const-correctness fixes in
methods taking XBeeAddress64 arguments).
- A get() and set() method for getting and setting the address as a
uint64_t.
- A operator uint64_t() which allows the XBeeAddress64 to be
implicitely converted to a uint64_t. E.g.:
uint64_t address = resp.getRemoteAddress64();
But also comparison:
resp.getRemoteAddress64() == XBeeAddress64(0, 0)
resp.getRemoteAddress64() == 0x0013A21234567890);
Note that both comparisons above work by converting to uint64_t and
comparing those.
Because this removes the need for separate comparison operators, the
ones that were there (but still commented out) were removed.
Note that avr-gcc doesn't currently optimize uint64_t values very well,
so the storage is still left as two separate uint32_t values. If you use
the msb/lsb accessors, code should be unchanged compared to before, but
if you use the uint64_t accessors or compare addresses, code will be
less efficient. This will hopefully be fixed in a future compiler
version, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66511.
Since this is a utility class that should really be a very thin wrapper around the actual data, the compiler should be able to inline all operations, instead of having to do a full function call just to load or store a few bytes. This removes the explicit super-constructor calls and rewrites the constructors to use initializer lists instead of assigning values in the body (which is more consise, and allows for constexpr next) This saves up to a 30 bytes of program spaces on the supplied examples, probably more for more complex programs.
This allows the compiler to better optimize (global) XBeeAdress64 instances. With the examples sketches, this saves between 44 and 114 bytes of program space, compiling for the Uno. Even sketches that do not directly use any addresses shrink, because the initialization of RemoteAtCommandRequest::broadcastAddress64 can be simplified. This feature requires C++11 to be enabled. This isn't currently the case (with Arduino 1.6.4), but is expected to be enabled in a future release. A preprocessor check is used to ensure that the code compiles with and without C++11.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements the suggestions from #3, and a bit more. The commit logs have more info, but roughly:
All existing API is still supported, working, and should not any slower or bigger. These changes have been compile-tested against all examples, as well as runtime-tested with my own programs.
The new APIs using uint64_t are significantly bigger and slower than the existing APIs, because the compiler doesn't properly optimize uint64_t operations, so none of the other code and examples have been updated to use the new APIs yet.
I have a few more improvements planned (#5). If this PR is merged already, I'll open a new one, otherwise I'll append those here.
Closes #3.