-
Notifications
You must be signed in to change notification settings - Fork 187
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
Fail gracefully if begin() not called #66
Conversation
initialize _sensorID to zero set _sensorID to the chipID found in begin() return _sensorID from sensorID() add more diagnostics to BMP280test and wait for Serial to start Essentially copied from the BME280 library
Same mods as bmp280test
begin will set _sensorID if successful
Is this not solvable by having them correct their code? How are they missing this even after referencing the library example? The general issue with this approach is the library functions are setup to return the values of interest. For example, |
Why does tech support always start with "Is it plugged in..."? Returning 0.0 is better than simply never returning from the function, which is current behaviour if begin() is not called. My experience shows that even the densest students are worried when the result is zero and never changes at all. P=0.0 Pa is physically near impossible. I don't think T=-273.13 C would give as much of a warning as a persistent 0.0. |
Where is that happening? Is this a hardware issue or a software issue? |
the functions could return NaN instead, to indicate invalidity |
Good idea |
It's a software issue -- functions that can be called in the wrong order sometimes will be called in the wrong order, and shouldn't crash when it happens. The inspiration in some cases has apparently been the sensortest example that initializes globals with bmp.getTemperatureSensor() and bmp.getPressureSensor() before calling bmp.begin() in the setup(). Novice students don't get why they can't also say: double pAmb = bmp.readPressure(); to initialize a global at the start of the program. |
OK, NAN returns do help with avoiding returning potentially valid values. Let's merge this and see if it helps. Or if the new issue just becomes "what's a NAN?". |
Instant gratification! Yesterday I asked some struggling students to try again with the new library and examples and they were able to solve their problems on their own. |
Tests _sensorID to make sure begin() was run before other I2C calls are attempted.
Returns 0.0 instead of T, P if not initialized. Prevents non-return crashes.
Requires previous pull request #65 that properly sets _sensorID, so it may fail if somebody was home brewing their own begin code. Partially addresses issue #64
I didn't know this was even a potential problem until multiple students tried to
readPressure() before begin() this term...