Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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>
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants