-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve LREAL support (WIP) #10
base: main
Are you sure you want to change the base?
Conversation
Within the LoupeUX stack there are comms bandwidth considerations here as well. |
Conceptually this change seems like an improvement, in that the previous behavior seems to prevent users from getting LREALs into traces, or other parts of the HMI. The bandwidth considerations are also important, and how this might impact existing applications if they were to update, especially if they are using many LREALs that are currently being demoted. Could we test performance with an existing application that uses many LREALs for comparison? Lastly, I noticed that this PR has the TLSF updates as well, was that intentional or meant to be in a separate PR? |
Actual last thought: would it be worth offering some kind of flag to opt-in to LREAL support? |
StringExt v0.15.0 uses TLSF and builds with it as a static library. StringExt binaries were brought into the example project including a tlsf header file. This shouldn't impact VarTools. |
LGTM but given my minimal experience with this repo, I'll pass approval to someone with more internal knowledge. Thanks for doing this! |
What
Don't demote doubles to floats in varGetValue
Why
Greater precision is better, maybe?
Sometimes we want to display double precision numbers on our HMIs
If y'all need double precision this might be the right starting place, however there may be additional changes required that I haven't considered yet.
I have not tested in the LoupeUX stack.