Skip to content
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

Update Zanshin_BME680.cpp #32

Closed

Conversation

Alain2019
Copy link

readout sensor registers : use bit shift instead of * /
temp sensor compensation changed shift's so that 32-bit variables can be used --> less use off 64-bit

results are the same

readout sensor registers : use bit shift instead of *  /
temp sensor compensation changed shift's so that 32-bit variables can be used --> less use off 64-bit
@SV-Zanshin SV-Zanshin self-assigned this Oct 11, 2020
@SV-Zanshin
Copy link
Collaborator

The c++ compiler automatically optimized these integer divisions to shift operations, so changing "x / 16" to "x >> 4" produces the same runtime code. I haven't checked to see if all values remain in range for the variables you changed from 64 to 32 bit; but they are temporary variables inside of functions so the space lost/gained is only temporary during the execution of the routines so I am not certain that the gains are worth it.

@Alain2019
Copy link
Author

The c++ compiler automatically optimized these integer divisions to shift operations, so changing "x / 16" to "x >> 4" produces >the same runtime code.

Those changes where for clarity, when bitshifting it's clearer to use the bit shift operators.

I haven't checked to see if all values remain in range for the variables you changed from 64 to 32 bit; but they are temporary >variables inside of functions so the space lost/gained is only temporary during the execution of the routines so I am not certain >that the gains are worth it.

There won't be a space advantage, but 64-bit operations are normaly a lot more time consuming that 32-bit operations.

@SV-Zanshin
Copy link
Collaborator

I see your point about bit-shifting rather than multiplying and dividing. I'll change the corresponding locations directly in version 10 under development. But I still see some multiplying that might exceed the 32-bit values, so I'll take a look at that separately.

@Alain2019
Copy link
Author

But I still see some multiplying that might exceed the 32-bit values, so I'll take a look at that separately.

I've checked with either the Bosch library, that only uses 64-bit for some measurements and 32-bit for others.

The changes are to the temp calculation, that could have needed 64-bit at the start with 1 or 2 bits. I moved a >>4 to the first calculation, which would be enough.

SV-Zanshin pushed a commit that referenced this pull request Oct 19, 2020
Changed multiplication and division by powers of 2 to bit-shift operations for clarity
@SV-Zanshin
Copy link
Collaborator

I've added issue #34 with 2 additions that cover what changes you made, plus integrated the changes in computation to the source code; there would have been too many many changes to this pull request

@SV-Zanshin SV-Zanshin closed this Dec 3, 2020
@SV-Zanshin SV-Zanshin mentioned this pull request Dec 3, 2020
15 tasks
SV-Zanshin pushed a commit that referenced this pull request Dec 3, 2020
* Updated to new version

* Updated to new version

* Issue #31 addressed for incorrect humidity computation

* Issue #32

Changed multiplication and division by powers of 2 to bit-shift operations for clarity

* Issue #33

Also corrected travis-ci links

* Issue #33

Corrected "const" definition

* Issues #33 and #34

* Issue #34

Corrections to formatting

* Issue #34 changes

Co-authored-by: Arnd <Arnd_Github@SV-Zanshin.Com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants