Differences in error handling for PiicoDev Laser and OLED

Support
1

Newbie to electronics as well as Python so just bear that in mind…

I wanted to trap hardware issues programmatically and find the following try/except approach works with the PiicoDev Laser but not with the PiicoDev OLED

While I don’t have an actually dead device to test code with the best I can do is unplug and see how it is handled.

I’ve done a print(help(xxx)) for each device and can’t find anything I can do a test call with so my method is making the connection and test as follows in this fragment of code…

print("Connect OLED")
try:
    display = create_PiicoDev_SSD1306()
except:
    display_ok = False
    print("OLED fail")

print("Connect LASER")
try:
    laser = PiicoDev_VL53L1X()
except:
    laser_ok = False
    print("LASER fail")

This works fine with the laser unplugged but in the OLED’s case it generates a long repeated string of errors to the console but the return is also returning as true and so the error handling code doesn’t get triggered…

PiicoDev could not communicate with module at address 0x3C, check wiring
PiicoDev could not communicate with module at address 0x3C, check wiring
PiicoDev could not communicate with module at address 0x3C, check wiring
Connect LASER
Connect LED
<class 'PiicoDev_SSD1306.PiicoDev_SSD1306_Linux'>
<class 'PiicoDev_VL53L1X.PiicoDev_VL53L1X'>
<class 'glowbit.stick'>

Is there a better approach to detect fatal hardware issues?

Ultimately my end use will be auto-start, unattended, no console etc… so want to handle all conditions programmatically in a graceful way

thanks!

2 Likes
2

I’d like to know this as well.
The constructor has it’s own try block and, as I read it, you’re going to get a PiicoDev_SSD1306 object, (or something inheriting it), no matter what. It’s in the spirit of piicodev to abstract away the complexity, but maybe there is a clever way to reach into the object and verify you got what you wanted?
Looking forward to someone providing an answer. :slight_smile:

3 Likes
3

Hi All
I don’t profess to know much about this but there is one glaring difference.

and

The difference is the inclusion (or exclusion) of the term “create”

Got to be doing something different
Cheers Bob

2 Likes
4

This has to do with how PiicoDev wraps bus transactions in a try: statement.
If you want to, you can remove or alter the statement in the driver library so you can pass out additional errors.

It sounds like digging into the driver code so that you can manually handle different exceptions will the the go here. Basically, we’ve implemented try and except, but have not filtered for the type of exception. You could remove or alter our try,except statements to include specific exceptions, and always rethrow them with raise to be caught higher-up in user-code.

The difference in initialisation is a quirk of making a device + single library (PiicoDev_Unified.py) that is compatible across different pieces of hardware.

The Micro:Bit v2 has limited flash memory available for drivers + user code, so we had to implement a reduced feature set. create is part of what handles this forking in functionality.

2 Likes
5

Hi Michael, Thanks for the heads up… sounds like a deep dive needed but the answer lies in there by the sounds… I’ll definitely return to this with the info given once I have the other elements I purchased are given their first run to make sure all parts are functioning ok then I can get more sophisticated by degrees… Alex

2 Likes
6

Here’s some reading to get you started

In hindsight, we could have wrapped our bus transactions in a try and filtered only for IO errors with the exception to be a little more precise. It could be a good upgrade in the future.

2 Likes
7

Thank you… I’ll add those to my reading list…

While I have you… in following the Force Sensitive Resistor guide I run into an immediate problem with the very first example code line: “import Rpi.GPIO as GPIO”

Thonny reports “No module named RPi”…

I’ve searched online and found many suggestions along the lines of "apt-install… " etc but when I’ve tried them it’s come back with saying RPi already installed and up to date and no changes made!

What am I missing/not configured to get the “Module not found” error?

thanks for helping me get setup with my environment so I can get down to coding… hopefully not too many stumbles left!

8

Hi Roving-Eye,

There are lots of things that could be throwing this error. Which Pi, and OS are you using?

That’ll help us start to narrow it down.

9

Sorry yes… Pi 4 and latest OS so bog standard… just adding packages as I go for each sensor as needed… but the attempts to separately install RPi is showing it’s already there… but then “not found” when trying to reference it… so a bit confusing! Esp for newcomer to the scene…

1 Like
10

Can get some pictures of the error?

Otherwise in the terminal its always good to give

sudo apt update
sudo apt upgrade
sudo reboot

a go.

1 Like
11

I’m a bit late on this but maybe it will help.
Are you sure that when you used “import Rpi.GPIO as GPIO” that, instead of Thonny reporting “No module named RPi”, it reported “No module named Rpi”? (Note the different case for “p”)

It should be “import RPi.GPIO as GPIO”

By the way, GPIO pins can be defined in Linux using “gpiozero” as well

2 Likes