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

Fail gracefully if begin() not called #66

Merged
merged 13 commits into from
Nov 30, 2021
Merged

Fail gracefully if begin() not called #66

merged 13 commits into from
Nov 30, 2021

Conversation

sellensr
Copy link
Contributor

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...

@caternuson
Copy link
Contributor

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, 0.0 is a valid temperature. How would you know that return is an eror vs. an actual temperature?

@sellensr
Copy link
Contributor Author

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.

@caternuson
Copy link
Contributor

Why does tech support always start with "Is it plugged in..."?

Where is that happening? Is this a hardware issue or a software issue?

@ladyada
Copy link
Member

ladyada commented Nov 30, 2021

the functions could return NaN instead, to indicate invalidity

@sellensr
Copy link
Contributor Author

the functions could return NaN instead, to indicate invalidity

Good idea

@sellensr
Copy link
Contributor Author

Is this a hardware issue or a software issue?

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.

@caternuson
Copy link
Contributor

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?".

@caternuson caternuson merged commit f5edbae into adafruit:master Nov 30, 2021
@sellensr
Copy link
Contributor Author

sellensr commented Dec 2, 2021

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.

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.

3 participants