Ensure readPressure function is executed only if begin returns 1

[pennam]

With some example sketches like https://opla.arduino.cc/opla/module/iot-starter-kit-maker/lesson/02-personal-weather-station the program execution goes on even if carrier.begin() returns an error. If the pressure sensor (or any other sensor of the board) fails to initialize the following reading calls get stuck here

Arduino_LPS22HB/src/BARO.cpp

Line 61 in 1f0a793

while ((i2cRead(LPS22HB_CTRL2_REG) & 0x01) != 0) {

because the sensor is not responding. On the MKR_WIFI_1010 this will lead to a watchdog infinite reset loop (watchdog is enabled by the IOT library).
Even if the board resets itself the sensor is never initialized correctly, the only thing i found working is to completely power off the board unplugging the usb connector, therefore, in this specific case, the watchdog resets are completely usless.
What i propose is to store the initialization return value and check it into the readPressure funcion avoiding any action if something went wrong during initialization phase and let the user decide when to reset/unplug the board.
If the changes are good i think we could extend them also to:

• https://github.com/arduino-libraries/Arduino_HTS221
• https://github.com/arduino-libraries/Arduino_LSM6DS3

and maybe some other library...

[github-actions]

Memory usage change @ 45a8900

Board	flash	%	RAM for global variables	%
arduino:mbed_nano:nano33ble	🔺 +64 - +64	+0.01 - +0.01	🔺 +8 - +8	0.0 - 0.0

Click for full report table

Board	examples/ReadPressure flash	%	examples/ReadPressure RAM for global variables	%	examples/ReadPressureImperial flash	%	examples/ReadPressureImperial RAM for global variables	%
arduino:mbed_nano:nano33ble	64	0.01	8	0.0	64	0.01	8	0.0

Click for full report CSV

Board,examples/ReadPressure<br>flash,%,examples/ReadPressure<br>RAM for global variables,%,examples/ReadPressureImperial<br>flash,%,examples/ReadPressureImperial<br>RAM for global variables,%
arduino:mbed_nano:nano33ble,64,0.01,8,0.0,64,0.01,8,0.0

[aentinger]

Sounds like a feasible solution, however it would be much better if this would be solved within the Opla demo sketches instead of ignoring the return values.

[pennam]

i completely agree, i will try to understand where the demo sketches are hosted to propose a change, however i think we could also merge this to strengthen the library. Thanks.